Of .exe's and .app's

[Jasonbot]

I was having an iteleectual AIM session with killyp here from macrumors (He's studying for GSCE's) and we were discussing Mac's and PC's. It came to something very awkward involving PPC's x86's and windows+mac OS X. So here is goes, from the start...

Old mac's had PPC chips and run OS X
New Mac's have Intel chips and run OS X
PC's have x86 chips and run windows
The above is all generalised.

So, Mac's can all run universal binary .app's but cannot run .exe's. This is because .exe's are based on the windows API, right? but now that macs have intel processors they can have windows installed on them (some of my PC friends -acquaintances- don't understand this yet) and therefore macs can run .exe's.

But mac's run PPC code via rosetta emulation and old PPC macs could run windows via emulation (Virtual PC) so everyone can run every code except PC's which can't run PPC code. Again, this is a generalisation.

So then Alex says that teher is some port of windows to PPC adn I told him that even if it was true (NT was ported to PPC for a short while) It wouldn't be able to run .exe apps as the chip is not compatible to which he replied taht the proramme doesn't communicate with the processor at a machine code level and taht teh OS did all of that. To which I formulated my view on Rosetta emulation that even though an inteal mac runs OS X it does not natively support PPC code.

What I am wondering is: why cant (EDITed3)PPC coded apps and x86 coded .exe's work on teh same processor natively? I think this is my question, I'm sure there must be various other views or thought about the compatibility.

EDIT1: The react OS states that they can achieve compatibility of windows apps on a PPC system. Is this all lies or is some truth involved?

EDIT2: I know that x11 code (unix code) is compatible on mac OS X as it is in Linux and Windows. Is this similar to how how java uses a virtual machine to work on many OSes?

 

[dpaanlka]

What I am wondering is: why can PPC coded apps and x86 coded .exe's work on teh same processor natively? I think this is my question, I'm sure there must be various other views or thought about the compatibility.

They don't. That's why Macs themselves have big fat Universal Binaries now, and Rosetta is there to take care of the PPC stuff.

EDIT1: The react OS states that they can achieve compatibility of windows apps on a PPC system. Is this all lies or is some truth involved?

All I can find on their web site is "a PowerPC port is in the planning stage." I'd assume they'd have some sort of emulation going on for software that is not compiled for PPC.

EDIT2: I know that x11 code (unix code) is compatible on mac OS X as it is in Linux and Windows. Is this similar to how how java uses a virtual machine to work on many OSes?

You still have to compile X11 programs for PowerPC.

 

[Jasonbot]

They don't. That's why Macs themselves have big fat Universal Binaries now, and Rosetta is there to take care of the PPC stuff.

Whoops, I meant can't. I want technical stuff, I undersatnd processors and that technical stuff but now I want to undersatnd why the different things dont work together.

 

[dpaanlka]

Whoops, I meant can't. I want technical stuff, I undersatnd processors and that technical stuff but now I want to undersatnd why the different things dont work together.

If I spoke Afrikaans would you understand what I'm saying?

 

[pianoman181]

You need to get your mind wrapped around all of this differently. You are, in fact, talking about different things. Windows will not open a .app because the .app is dependent on various OSX API's, and similarly, OSX will not open .exe's because they are dependent on various functions of the Windows API.

Beyond this, there are structural differences between x86-type processors and PPC processors. Most significantly is the fact that x86 processors are CISC (complex instruction set) and PPC processors are RISC (reduced instruction set). Fundamentally, PPC processors support fewer functions than their x86 counterparts. While this seems like a strong disadvantage, the advantage is that the functions they do support they are quite efficient at. The ideology here is that functions that are not supported at the hardware level can be created using low-level software and the functions that are supported.

That is why, at a fundamental level, you cannot pop in a XP cd in a PowerMac G5 and have it install. The way Virtual PC functioned was by acting as a buffer between the x86 OS and the PPC processor, creating the various functions that the PPC processor didn't support. Similarly, there was a "PearPC" project that simulated a PPC processor on x86 hardware which allowed people to install non-universal binary versions of OSX into a virtual machine on standard hardware (albeit very slowly).

So, I hope this clears things up? You're talking about two very different things... incompatabilities due to API's and incompatabilities due to processor structure.

 

[Eric5h5]

Most significantly is the fact that x86 processors are CISC (complex instruction set) and PPC processors are RISC (reduced instruction set).

That's not really true, though, at least not anymore and not for years.

The main thing to keep in mind is that x86 and PPC are different and incompatible. When you get down to it, program code is actually just a bunch of numbers, and the numbers do different things on x86 vs. PPC. Furthermore, Windows and OS X are also different and incompatible, and use different routines to accomplish different tasks in different ways. A CPU emulator like Rosetta takes the numbers meant for one architecture (PPC) and translates them so they make sense to the other architecture (x86).

And no, X11 is not like Java. Also, "X11 code" is not "unix code". X11 is a windowing system, which can be implemented on different operating systems (including Unix), as a way of putting stuff on the screen. That's all it does...it's not a programming language or an operating system.

--Eric

 

[dpaanlka]

The main thing to keep in mind is that x86 and PPC are different and incompatible.

In the sense that, one was developed by Motorola/IBM, and the other was developed by Intel, and they both were developed completely independently of each other by completely unrelated companies and function completely differently to achieve similar results and compete with each other.

 

[Jasonbot]

If I spoke Afrikaans would you understand what I'm saying?

That would depend? Can you speak afrikaans?

Now back on topic, The PPC and x86 architectures are different. Much like Windows and Mac OS X are different and that you can't run mac OS X intel code on a windows machine.

It terms of machine code do the RISC and CISC instruction sets differ? Are there other types of processor architectures out there that work similarly to this (Arm maybe?) to add to this, this page: http://en.wikipedia.org/wiki/Instruction_set details various types of processor instruction sets. Is this the main reason for incompatibility between instruction sets? Are computer architectures backwards compatible? surely an intel 4004 instruction is/not compatible with a new fangled Core 2 chip?

Is this a principal of universal binaries and what makes them run on 2x platforms?

Just chill... more questions to come later.

EDIT: why do amd and intel processors coexist peacefully albeit different motherboards are required.

 

[Jasonbot]

Is the only person taht can help me an electrical engineer from intel?

 

[dpaanlka]

It terms of machine code do the RISC and CISC instruction sets differ?

There is not a universal RISC or CISC instruction set. When you deal with instruction sets, you are dealing with specific processor family instructions.

Are there other types of processor architectures out there that work similarly to this (Arm maybe?)

Every processor in the world has an instruction set, yes.

to add to this, this page: http://en.wikipedia.org/wiki/Instruction_set details various types of processor instruction sets. Is this the main reason for incompatibility between instruction sets?

Yes, the main reason the two processors are not compatible with each other is because they're different. Yes, that is the reason.

Are computer architectures backwards compatible? surely an intel 4004 instruction is/not compatible with a new fangled Core 2 chip?

Usually not entirely, but the x86 family did not start with 4004. It started with 80086. Yes, some of the first PC software ever written ("PC" as in IBM-PC or clone) will run on modern Core 2 Duo computers. They are backwards compatible (although Windows XP and Vista themselves have lots of problems being as backwards compatible).

Don't confuse this with forwards compatible. Software written to take advantage of specific Core 2 Duo features will not run on an 80286 or 80486-equipped computer.

Is this a principal of universal binaries and what makes them run on 2x platforms?

Universal binaries contain all the code for PowerPC, and all the code for x86. Essentially two separate programs, bundled into one.

Is the only person taht can help me an electrical engineer from intel?

If you call an Intel engineer and ask him, his response is going to be "because they're completely different." There is no one reason, one resistor, one small difference. They are completely 100% different processors made by two completely different companies.

What more explanation than that do you want?

 

[SpookTheHamster]

You're trying to delve into things that are beyond your knowledge, and would take a while for you to grasp.

Why can't I survive on fish food? We're all animals, after all.

 

[Cromulent]

The Afrikaans analogy was spot on. The processors speak two completely different languages and machine code for an Intel processor is completely different to PPC machine code.

Remember it does not matter what programming language you use to write an application. When it is compiled / interpreted it is turned into machine language for that specific CPU or CPU family.

CISC and RISC are not standards. They are philosophies by which to design a CPU. One uses the idea that executing fewer larger instructions at a slower speed is better the other uses the idea that executing lots of very small instructions very fast is better.

 

[Jasonbot]

The Afrikaans analogy was spot on. The processors speak two completely different languages and machine code for an Intel processor is completely different to PPC machine code.

I thought the afrikaans analogy was taking a dig @ me 'coz I'm from South Africa (I understand Afrikaans) and not referring to processors.

I think I grasp the basics but but what about intel and AMD being competitors but using the same instruction set, is this just b/c they develop for teh same platforms?

And can I therfore assume that programmes coded for windows using say C++ can only address RISC processors and programmes coded for OSX (IDK an OSX only language) can only address CISC processors.

I apologies if anyone is getting ticked off, my engineering like mind is craving knowledge.

 

[Cromulent]

I thought the afrikaans analogy was taking a dig @ me 'coz I'm from South Africa (I understand Afrikaans) and not referring to processors.

Didn't realise that, but no the analogy was about the processors (at least I read it that way).

I think I grasp the basics but but what about intel and AMD being competitors but using the same instruction set, is this just b/c they develop for teh same platforms?

Yes, AMD made their processors to be compatible with Intel processors so they could run the same software on them.

And can I therfore assume that programmes coded for windows using say C++ can only address RISC processors and programmes coded for OSX (IDK an OSX only language) can only address CISC processors.

No. You can cross compile. Which means writing a program on a Windows based Intel machine and say compiling the code for a Windows based DEC Alpha machine. Plus Intel / AMD processors have traditionally been CISC processors where as Motorola / IBM processors (PPC) have traditionally been RISC processors.

Programming languages are not platform dependent. You can write programs in C++ for Windows / DOS / Linux / Unix / Mac OS X / Mac OS Classic / OS/2 and any number of other operating systems. All you need is to write a compiler for that language for a certain CPU / OS.

 

[Jasonbot]

Programming languages are not platform dependent. You can write programs in C++ for Windows / DOS / Linux / Unix / Mac OS X / Mac OS Classic / OS/2 and any number of other operating systems. All you need is to write a compiler for that language for a certain CPU / OS.

Ah, But if something addresses an OSes specific API, then it's incompatible.

I think this sheds some light, especially the bit that says how old computers could not run newer programmes as back the programmes had to be coded to match the CPU:
http://en.wikipedia.org/wiki/History_of_general_purpose_CPUs

 

[Cromulent]

Ah, But if something addresses an OSes specific API, then it's incompatible.

That is like the difference between speaking the Queens English and Cockney rhyming slang. They are both English but one is only understood in a certain area.

The API is not a part of a language. APIs use the language to construct easy to use functions for developers to use so they do not need to reinvent the wheel every time they write an application.

 

[dpaanlka]

I thought the afrikaans analogy was taking a dig @ me 'coz I'm from South Africa (I understand Afrikaans) and not referring to processors.

Wow. I actually didn't read where you were from and had no idea. I picked Afrikaans because most people don't speak that, or even know what it is, so I wanted something really exotic and foreign to make my point, which is now mute since you do speak Afrikaans.

What are the chances of that.

 

[Jasonbot]

Wow. I actually didn't read where you were from and had no idea. I picked Afrikaans because most people don't speak that, or even know what it is, so I wanted something really exotic and foreign to make my point, which is now mute since you do speak Afrikaans.

What are the chances of that.

Well I get it now. Good analogy!

Just had another chat with teh aforementioned member and he said that API's are like teh underlying system processes (adjust backlight, resize window length calculation, open GL) and all these allow a normal programme to function as it should within teh OS.

EDIT: this is why Some apps are Tiger only and cannot work on the Panther API.

 

[Cromulent]

Well I get it now. Good analogy!

Just had another chat with teh aforementioned member and he said that API's are like teh underlying system processes (adjust backlight, resize window length calculation, open GL) and all these allow a normal programme to function as it should within teh OS.

EDIT: this is why Some apps are Tiger only and cannot work on the Panther API.

Correct, but it is important to make the distinction between an API and a programming language which you seem to be confused about. A programming language is 100% cross platform compatible. An API is written in a programming language and is used to give the developer easy access to the operating system and the functions that it carries out.

So an API is mearly a subset of a programming language.

ANSI C is the standard for the C programming language (think the Queens English again). Some compilers are more rigid than others in how they follow that standard. OpenGL is an API which can be used from within C and it is also cross platform compatible.

Not to confuse you further but it is technically possible to compile an Intel Windows application on a PPC Mac OS X machine. All you would need is the correct libraries and headers and a cross compiler for an Intel processor.

 

[darkcurse]

...A programming language is 100% cross platform compatible.

Not entirely true. If that were so, how come programs have to be "ported" over rather than just be recompiled? The main reason stems from the use of C/C++. A "long" in x86 is not the same as a "long" in a PPC proc thus the reason why it has to be debugged and modified.

Go read up on AMD's wiki to get a better understanding of why Intel and AMD chips co-exist.

 

[Cromulent]

Not entirely true. If that were so, how come programs have to be "ported" over rather than just be recompiled? The main reason stems from the use of C/C++. A "long" in x86 is not the same as a "long" in a PPC proc thus the reason why it has to be debugged and modified.

The language itself is the same. It is the implementation of the language which is different.

 

[atszyman]

Let's do the language analogy:

Intel speaks Russian.
PPC speaks Chinese.
Rosetta is a Chinese to Russian translator.

All programs are written in English and can be translated directly to Chinese or Russian, although Rosetta allows the Chinese to be translated to Russian as it is run.

Now a nice generic program can be translated easily between Intel and PPC by simply re-compiling.

When performance is key many times people will go and write assembly code for the target processor to make a process faster. Every processor has it's own assembly code, Intel and AMD share a large portion but will sometimes diverge with specific hardware enhancements targeted to increase performance and differentiate their product. (SSE instructions on Pentiums comes to mind).

This would be analogous to phrases that can more accurately convey emotion and meaning in their native tongue than any translated language. Since you are multi-lingual you surely understand how some phrases/emotions will sometimes lose some of their punch and feel when translated to anther language.

The OS is more of a sentry position that guards access to the hardware. Without the proper instructions the OS does not know how to handle the compiled code in question. An intel compiled .exe for Windows will consist of all the same assembly instructions for the processor but does not know how to tell OSX to draw windows or access memory or other hardware. Since the underlying OS is the same for OSX Intel/PPC rosetta can handle the translation from Intel to PPC assembly language but still cannot help an exe tell the OS how to draw windows or access hardware. The PPC app knows the commands to tell the OS what to do, it just speaks the wrong language.

I hope this makes some sense...

 

[darkcurse]

The language itself is the same. It is the implementation of the language which is different.

Hmm yeah true. And like atszyman said, when you need to optmize code most of the time its done in assembly thus making it un-portable to other processor platforms in that sense.

 

[Cromulent]

Hmm yeah true. And like atszyman said, when you need to optmize code most of the time its done in assembly thus making it un-portable to other processor platforms in that sense.

Very true. It is also worth mentioning though that when ever you write a program in any language as soon as you compile it or interpret it the code is automatically rewritten in machine language. This is what compiling / interpreting the code does.

Writing code by hand in assembly mearly gives you more control of that process and takes out some of the guess work that the compiler for a higher level language has to do to turn it into machine language.