Not that I disagree with the previous post, but I thought I would point out a few things...
Mikuro said:
This in and of itself would be a huge task, but it would also lead to a nightmare for end users. Imagine downloading an OS X program and then realizing "oops, this is for OS X on x86, not PPC". And some apps might only work on one or the other, or at least be heavily optimized for one more than the other. Consistency would go right down the drain.
I can say from experience that this issue (having both PowerPC and x86 versions of applications) isn't that big a deal. I've been dealing with it in Rhapsody for years without it being a
nightmare.
First, many of the apps were designed to run on both PowerPC and x86 without the end user doing anything at all. I have apps that run on my Rhapsody for PowerPC system perfectly and will run just as good on my Rhapsody for x86 (
PixelNhance is one such app that comes to mind).
Further, developers took the time to label their apps with which platform it was design to run on ("p" for PowerPC systems, "i" for x86, and "pi" if it would run on both).
Nightmare seems like a strong word for this situation. And it was even worse with OPENSTEP/NEXTSTEP as there were four hardware platforms that they ran on. And even with four, it was relatively easy to figure out what apps ran on what hardware.
Now one thing that did come up (and lead to the demise of Rhapsody for x86) was developer's not making their applications run on both platforms.
When Rhapsody was first released to developers, OPENSTEP developers were the ones best suited for writing apps for the new operating system. Most people thought that they would put out more x86 apps than PowerPC as most had been running OPENSTEP on x86 hardware for quite a few years. As it turned out, that assumption was wrong.
By the time Apple was getting ready to release a version of Rhapsody to the public, the x86 version was facing a deficit in the amount of applications that would run on it. All of these developers had jumped to PowerPC hardware and stopped taking the time to make all their apps work on the x86 version of Rhapsody. Add to that the fact that Blue Box (sort of an early Classic) only worked on the PowerPC version of Rhapsody and the x86 version was facing a major shortage in applications (compared to the PowerPC version).
Well, with few apps Rhapsody had very little chance of success on x86 (this is a well known effect in the industry called the
applications barrier which had doomed many great operating systems in the past). So Apple pulled the plug on Rhapsody for x86 (the last version released was 5.1, the last PowerPC version was 5.6).
As most big name Mac developers said that they had no intension of rewriting their apps in Yellow Box (which would become Cocoa), even the PowerPC version was facing an up hill battle. This was when Apple put forward the idea of Carbon.
If Apple ever really needed to, they could port OS X to Intel with relatively little trouble. The key word being relatively. It'd be easier that porting Windows to PowerPC, but it still wouldn't be easy.
There is a PowerPC version of Windows which runs on G5 hardware. This was done so developers could write games for Xbox 2. And it wasn't all that hard as there had been previous versions of Windows (NT 4.0 and 3.x) which ran on PowerPC systems.
What should be noted is that Windows on PowerPC ran into the same
applications barrier that Rhapsody on x86 ran into (and that Mac OS X on x86 would also run into).
The most advanced operating system in the world is pointless without applications. With no applications, users will not use that operating system. With no users, developers will not write for that operating system.
With Carbon, Apple was able to give Mac OS X enough momentum to get passed that barrier. There would be no equivalent way to provide that type of momentum on x86... and Apple has plenty of incentive not to hurt it's hardware business (which is where about 90% of it's profits come from).
