Re: jermsmingy
A program is written in a high-level lanugage (like C, C++, etc) and is compiled (exculding, of course, things like Java, but it can't make a very good stand-alone Word processor) to Assembly.
Assembly is a processor-line-specific language. The PPC processor line has it's version of the Assembly language, and the x86 has it's own. They are incompatible.
Once the code is turned into Aseembly, it still needs to be able to call system libraries that are dynamic (ie, they aren't part of the compiled code, such as system calls to make windows and buttons, etc), so they are linked to those libraries. Once everything is linked together by a program called a linker, it is handed to an assembler program that turns the Assembly code into machine language.
Machine language is processor-line-specific, as well. Apps assembled for PPC will not work on 68k or x86. Apps written for x86 will not work on 68k or PPC.
So, it's not to do with talking to the hardware calls. That isn't the issue. The issue is that source code turns into processor specific Assembly (Motorola has different ideas about what should go into Assembly then what Intel and AMD think), is linked to system libraries that are compiled as well, and then turned into machine code.
Yes, you can emulate the other chip architecture (ala VirtualPC, etc), but it will never be as fast as the actual chip itself is at comparable speeds.
Also, the system libraries must be generated for x86 if you want MacOS X apps to work on x86. Right now, those libraries are written and compiled with PPC in mind. Quartz, Cocoa, Classic, etc are written and compiled for the PPC architecture. Darwin, the core of MacOS X, works on x86. But no GUI-level libraries do.