There was a discussion on /. a few moths ago where a person posted a story about OSX and non-ppc hardware. He worked for Apple and knew that Apple has an OSX version for Intel in parallel development with the ppc version we all know. This for the possibility that moto/ibm couldn't keep it up anymore against the intel hardware. He mentioned that when the time was there Apple would i.e. put intel in their mac's and make sure OSX would not run on other pc hardware than Apple. This way Apple still had all the profits from the hardware. But there are many reason's why not. Take M$ for example, they could kill Office on the mac because Apple would be a direct rival with M$. And Altivec and so on.. So, this is my piece, written with very cold hands. heh. C ya.
<strong>Power4 is the fastest chip in the world and could maybe do nice things for 3D and graphics like it does for servers. I wonder if Apple or IBM could create a PPC2 based on Power4? From what I understand the Power4 has all the instructions a PPC has and more (minus Altivec).
</strong><hr></blockquote>
In addition, it has about as many pins alone as all the chips on Apple's current mainboards summed up, and eats more watts than a small cluster of G4s (costs more too!).
Do you have any idea how incredibly expensive a single Power4 processor is, and how utterly and completely misplaced it would be in a Mac?
<strong>There was a discussion on /. a few moths ago where a person posted a story about OSX and non-ppc hardware. He worked for Apple and knew that Apple has an OSX version for Intel in parallel development with the ppc version we all know.</strong><hr></blockquote>
Then again, he never proved his claim of working at Apple in any way, so there's hardly a way to tell if his claims were accurate.
For one, I kinda find it unlikely that Apple has an internal, fully-functional OS X/x86 version, given the horrid state of Darwin/x86 (at least the publicly available version), which in fact manages to have an even shorter hardware compatibility list than BeOS/x86.
<strong>The problem. You're not seeing the problem.</strong><hr></blockquote>
I am seeing the problem. I'm trying to break the problem down from the vague "it's impossible or too hard" to something more concrete.
[quote]<strong>To quote from above, "strictly as a technical exercise, all of MacOS software, including MacOS itself, can be ported to x86. A significant (like, major) undertaking, but doable.
[snip]
The best Apple could hope for would be a small disaster.</strong><hr></blockquote>
Much too vague. It's easy to say it would be a disaster. I want to know why. No hand waving.
Here are the five issues involved in such a transition that I've identified so far:
1. endianness
2. existing PPC assembly
3. existing Altivec code
4. keeping OS X off Wintel PCs
5. portables (x86 is too hot and hungry)
The first three I addressed in my first post on this thread (a few up from here). 4 and 5 don't look that bad. I can't see how to get around 4 right off, but, seeing how small and light some Sony VAIOs are, 5 is probably not a big problem.
Does anybody see any other issues? Is it just a matter of the speed gap getting a teensy bit bigger before Apple does this?
Here's two things Apple has done that I, personally, would have said were "impossible", had they been described to me before being unveiled (as a work in progress) by Apple itself:
<strong>For one, I kinda find it unlikely that Apple has an internal, fully-functional OS X/x86 version, given the horrid state of Darwin/x86 (at least the publicly available version), which in fact manages to have an even shorter hardware compatibility list than BeOS/x86.</strong><hr></blockquote>
Sure, but keep in mind that Apple would retain control of the hardware, even if it were x86-based.
I believe they do have an internal version of OS X for x86 (including a non-public Darwin) which works only on a specific x86 setup, not on any old PC you can pick up at CompUSA.
Thinking about this conversation has really got my mind working.
I would like to remind everyone that Apple did change processor architectures before when it moved from CISC to RISC. I remember buying my first PowerPC Mac and the claim was that the chip was so fast it could run all the old stuff faster under emulation than the old chip.
Folks, depending on what you believe, Intel and AMD chip performance combined with the high rate of change on their MHz and the low rate of change on motorola chips, could soon mean that G4 code could be run faster in emulation on a fast x86 than natively on an actual G4.
Apple uses industry standard parts on every other component of their machines except the CPU. The retardation of the G4 with respect to bus speed support, memory speed support, etc... forces the use of inferior components throughout the rest of the mac line.
If Apple released dual 2.2 Ghz P4 machine with native support of Darwin and the rest of the system emulating a G4, I wouldn't be surprised to see performance vs. today's G4s be roughly equal on an overall basis. Especially since this system would have DDR RAM, 266MHz bus, etc..
It wouldn't cost Apple any more to build than today's G4 based systems.
Why would MicroSoft view Apple as a more direct competitor unless Apple chose to become a software company, just because they used the same CPU that microsoft's software is compiled for. MS would only look at this as another opportunity to go to the wallets of their Mac users with another upgrade, this time compiled for X on x86. In the long run, this can only help them reduce engineering costs where code needs to be optimized for only one chip rather than two.
The notion that hackers could allow any PC user to run MacOS is surely one that Apple could deal with in a number of ways.
In short, I agree that this is possible, and although a large undertaking, perhaps a worthwhile one if indeed the very survival of Apple will depend on it.
This move would finally acknowledge that Apple cannot lead on the engineering of components, and was instead pursuing a niche targeting users who were prepared to pay a premium for systems integrated with software whose reliability, ease of use, appearance and applications were a notch above what the masses buy.
We can't blame Motorola for not being able to keep up with a company that does 1000 times the volume and doesn't have limited resources in the same way Motorola does. Face it, Motorola has lost - they and Apple have yet to admit it - but they're never going to catch up.
DUH! I am so stupid. <img src="graemlins/embarrassed.gif" border="0" alt="[Embarrassed]" />
The biggest problem with this whole thing just hit me square in the face: Classic apps (and other apps) which may never get recompiled for this new x86 OS X. In order for Apple to make the switch, they would, indeed, have to emulate PPC on x86 (like in the 68K to PPC transition). Yikes. Not impossible, but a huge job. Not to mention you'd need a really wicked-fast x86 to get decent PPC emulation.
Alright, alright, so everybody's saying, "well, duh." I just didn't see it. I was totally honed in on OS X (without Classic) in it's current state, where there really aren't any OS X "native", legacy apps yet.
First, there's absolutely nothing impossible about switching to x86. The change would be very similar to Apple switching from 680x0 to PPC. In fact, in many respects, the microkernel architecutre of OS X would make it easier to port.
Some of the considerations would be:
1) Probably no more "classic" mode. It would hardly be worth Apples time to port Mac OS X, plus the complexities of "double" emulation would be a pretty big undertaking. Further, by the time they would accomplish this, Classic would be irrelevant anyway.
2) What's the future of x86? Intel is pretty much betting the future on it's IA64 design. So far, Merced was a dud. McKinley will be better, but buy how much? Intel is hedging it's bet on the x86 platform, but doesn't seem committed to it. The next iteration of the P4, code named Prescott is mostly just a die shrunk 90 nanometer process version of the same chip. Then there is AMD's 64bit version of the x86 architecture to consider. In short, switching to "Intel" is a bit more chaotic then you might initially think. There's a real fork in the road for that direction as well.
3) Assuming Apple did convert to x86. Would PCs be able to run OS X? If so, that would quickly shut down Apple as a hardware vendor. There's no way Apple could compete in that market. Also, does anybody remember why OS/2 failed? OS/2 could run Windows applications. Developers no longer felt it was necessary to create a specific OS/2 version of their app for the same hardware platform.
4) Consider the events over the past couple of years. Apple had developers prepare for and learn to code in the new PPC environment. Then they make a major OS change with OS X. This requires a huge amount of work for each developer. Now, we go and tell them that they should switch to entirely x86 afterall? For 3% of the market? Yes, some companies have a much larger percentage of their sales to the Macintosh market, but overall, Apple's marketshare is pretty small and not very infuential to developers.
5) Now, consider that the gain would be? Let's see, you wouldn't notice the difference in speed for business productivity apps, since they aren't CPU bound on todays hardware anyway. Apple's core market makes heavy use of Altivec through key programs like Photoshop, Cleaner5, Final Cut Pro, DVD Stuido Pro, all the "iApps", Quicktime, etc. So, that leaves you with a few specialty apps like 3D rendering where there would be some noticeable improvement. Wow... hardly seems worth it.
6) Now consider that the 2.2 GHZ P4s are as fast as they are because they've already moved to the .13u process. They are already demonstrating P4s on the .09u process. Meanwhile G4's are still being manufactured on the .18u process. In short, the .13u G4s are coming - probably this summer. Apple would be better off designing their own chips and having someone else (that's more current in fabrication technology) produce them as THT has suggested.
7) Maybe Apple knows something we don't, particularly with regards to the G5 and it's performance potential. So, let's forget this notion of switching CPU designs already.
<strong>Forget classic. Even Carbon apps would be broken.</strong><hr></blockquote>
Yes, but those could be recompiled. Chances are high that a Carbon app still has active development (or at least somebody that could recompile it).
I was talking about stuff that's still in Classic and will never get Carbonized or otherwise move to OS X "native". We still need these to work, thus a PPC emulator would be required in the switch to x86. Maybe when Classic is gone forever (68K is pretty well gone forever, right?), it could happen. The problem then would be how much "native" stuff is legacy at that point.
There's one thing you guys are overlooking when you talk about emulating a PPC on x86-- PPC has FAR more registers than x86 does (what is it-- 32 vs. 14?) That's going to cause an incredible performance hit for PPC code running on an x86 processor every time you have to swap registers in and out of memory. With a P4 2.4GHz, you might be able to squeeze performance similar to a 66Mhz 601, if you're lucky.
Going from 68k to PPC didn't have this problem, because the PPC has more registers than 68k did (32 vs. 16 in that case).
PPC emulation on x86 would be a killer for moving the OS to that platform.
The other problem would also be that users may want to run Windows on their new x86 based Apple boxes. Why? To run all the software out there that is Windows only. If users have both OSes, then developers may want to save money and develope for just Windows. Next thing you know, everything is Windows only so you might as well just buy a PC for cheaper and forget running OSX which has no software developed for it.
It would take years to port and optimise Mac OS X until it's usable, and considering that they've spent years on getting it where it is now, a switch to the x86 would just seem like a joke. General speed, Altivec (Final Cut Pro along with it), Classic, many current applications... gone, at least for a while! Wouldn't that be lovely?
That's ignoring that the x86 architecture would be a waste of time to port to anyway, since it is bound to be in flux in the coming years. 64-bit x86 = <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />
"The biggest problem with this whole thing just hit me square in the face: Classic apps (and other apps) which may never get recompiled for this new x86 OS X. "
There's nothing Steve Jobs dislikes more than legacy technology and I'm sure he hates Classic even more than floppy drives.
It's nice to see some intelligent conversation about the possibility of moving to x86. Usually this is met with a Chicken Little response.
I don't think Microsoft would immediately punish Apple for moving to x86. I doubt Bill Gates even spends one minute a day thinking about Apple. in his mind he has rationalized that Microsoft won the market by giving the people what they want and Apple is like one of those artsy movie theaters that plays films that most people have no interest in. When Steve Jobs announced the switch he could just claim that he felt Motorola would fall behind forever and that using x86 would be save Apple a lot of money in R&D.
For them to do so, they'd have to have a portable (platform independant) operating system, written in a highly portable language, like C, one that can be easily recompiled.
As for apps, this new OS would have to have hooks for some new kind of programming language. Unlike classic or carbon, this language would have to be VERY portable, no legacy. Like C based or something. But objective, so that apps could be built quickly.
This C based, 'objective', future language should have a catchy name, like how Java does. People like coffee. Maybe some other hot beverage. Like say..
...'Ovaltine'.
Anyway, once this portable, C based operating system (pref. a thoroughly tested, rock-solid one, built around industry standards. In fact,it would be nice to see them use a free, open *nix of some sort. Let's say... Linux!) and it's forward thinking object-oriented, C-based 'Ovaltine' APIs were in place, then Apple would be far less platform-dependant. Then maybe they could make the switch, once developers were comfortable with Ovaltine.No PPC emulation, just recompiled, clean, portable code with all the optimization flags set.
(Now that I think about it, Apple could just take Linux, and harness all the developers/apps for it, and focus on the GUI aspect, which Linux has traditionally been weak at! Then Apple could save itself 90% of the work of making their OS! It would be like, The Power of Linux, the Simplicity of the Mac!)
But I do not see such an OS on the horizon. Nor do I think Apple would have the sense to include an advanced API like my theoretical 'Ovaltine'.It's just not going to happen.
And thus is my reasoning that Apple will not make the switch. They never foresaw a situation like they are now in. Besides, PPC, though it doesn't have the market share/profitability, designers/engineers or fabs, and is aimed towards embedded appliances, is still better than a dual AMD box at Photoshop. At least at a couple of filters.
Let's clear up a few misconceptions here. It is possible for OS X, OS, programs, and all to be put on x86. However, I believe it would only be used as a last ditch effort if Motorola were no longer a viable option. I think Apple is going to be lagging for awhile due to Motorola and won't catch up (if ever) unless Motorola has a few tricks up its sleeve. Everything is tight lipped at Apple and Motorola, so no one can definitely say what hardware will and will not be released. That aside, there are a few issues porting OS X to x86 architecture. While I've heard many x86 users (Windows and *nix included) say they'd use OS X as their primary OS if it were ported to x86, it's not going to happen. Sure, there's Darwin for x86, but that doesn't amount to much. It's still lacking Cocoa, Quartz, Carbon, Aqua, and all of the things that make OS X what it is. Currently, it is all powerpc code. It would be possible to get Carbon and Cocoa programs to work under x86 if Cocoa and Carbon were rewritten. If Apple were slick with their implementation, all that would be needed would be a simple recompile of the program. There would be some low level emulation involved. However, with the high end AMDs kicking the G4 where it hurts, this would be unnoticeable. Apple pissed off a lot of people with OS X, because the programmers had to reimplement their code to make it native. On x86, a more or less similar process would be required. You'd either have emulation on the x86 side, or both the PPC and x86 having native applications. This could lead to confusion when consumers go to buy the software, because one would have the PPC code version and the x86. Also, knowing Apple, they'd be so radical as to discontinue PPC support if they went this route. Rest assured though, Apple would not port the code unless it was a last ditch effort. Apple is and has always been about vertical integration. They want to control the hardware which runs their operating system. In one sense this is good, because it makes for a more pleasureable UI that's seamlessly integrated with the hardware, but it's also bad because you're stuck with what Apple feeds you for hardware options. PC hardware is changing so rapidly that every chipset and motherboard manufacturer is struggling to stay afloat. There are a myriad of choices. Apple doesn't want this for its hardware. If there were an OS X port to x86, Apple would somehow make it so it would only run on proprietary Apple branded hardware. However, it would only be a matter of time before someone were to crack it and start installing it on a generic x86 machine. This is Apple's biggest concern, aside from pissing off software developers.
I'm hoping that Motorola either a) gets its act toghet or b) sells its cpu division to Apple.
I have a new reason for why it'll never happen (as mentioned by others) which isn't technical at all. Making the switch is possible, but a very bad move.
If you put an x86 processor in the box, everybody will expect (probably demand) that it be able to run Windows apps. Makes sense, right? If the Mac is practically a PC (hardware-wise), Apple's going to be under immediate, constant pressure to make OS X run Windows applications. As soon as that happens, however, all the other OS X APIs (Carbon, Cocoa, whatever) are dead. Why would a developer wishing to support OS X use anything other than the Windows API; they get Windows and OS X support all at once. This would make OS X simply a Windows clone (like IBM's OS/2), albeit perhaps better. Apple is then in direct competition with Microsoft which controls the API. Uh oh.
However, this makes me think about the reverse situation: write for Cocoa on OS X and run on Wintel, too. Maybe Apple should bring back the x86 Yellow Box?
<strong>Yellow box is a bad idea. That's how OS/2 got canned. Why write macOS Apps if Windows apps work in OS X anyways.</strong><hr></blockquote>
I think you've got it backwards. x86 Yellow Box is, essentially, Cocoa on Wintel (not Win32 on OS X). You write for OS X (using Cocoa APIs) and it runs, with a dll, on Wintel as well. This is attractive to Windows developers. Instead of writing to the (antiquated ) Win32 API, they can use Cocoa (much nicer) and target both Windows and Mac OS X.
Comments
<strong>Power4 is the fastest chip in the world and could maybe do nice things for 3D and graphics like it does for servers. I wonder if Apple or IBM could create a PPC2 based on Power4? From what I understand the Power4 has all the instructions a PPC has and more (minus Altivec).
</strong><hr></blockquote>
In addition, it has about as many pins alone as all the chips on Apple's current mainboards summed up, and eats more watts than a small cluster of G4s (costs more too!).
Do you have any idea how incredibly expensive a single Power4 processor is, and how utterly and completely misplaced it would be in a Mac?
Bye,
RazzFazz
<strong>There was a discussion on /. a few moths ago where a person posted a story about OSX and non-ppc hardware. He worked for Apple and knew that Apple has an OSX version for Intel in parallel development with the ppc version we all know.</strong><hr></blockquote>
Then again, he never proved his claim of working at Apple in any way, so there's hardly a way to tell if his claims were accurate.
For one, I kinda find it unlikely that Apple has an internal, fully-functional OS X/x86 version, given the horrid state of Darwin/x86 (at least the publicly available version), which in fact manages to have an even shorter hardware compatibility list than BeOS/x86.
Bye,
RazzFazz
<strong>The problem. You're not seeing the problem.</strong><hr></blockquote>
I am seeing the problem. I'm trying to break the problem down from the vague "it's impossible or too hard" to something more concrete.
[quote]<strong>To quote from above, "strictly as a technical exercise, all of MacOS software, including MacOS itself, can be ported to x86. A significant (like, major) undertaking, but doable.
[snip]
The best Apple could hope for would be a small disaster.</strong><hr></blockquote>
Much too vague. It's easy to say it would be a disaster. I want to know why. No hand waving.
Here are the five issues involved in such a transition that I've identified so far:
1. endianness
2. existing PPC assembly
3. existing Altivec code
4. keeping OS X off Wintel PCs
5. portables (x86 is too hot and hungry)
The first three I addressed in my first post on this thread (a few up from here). 4 and 5 don't look that bad. I can't see how to get around 4 right off, but, seeing how small and light some Sony VAIOs are, 5 is probably not a big problem.
Does anybody see any other issues? Is it just a matter of the speed gap getting a teensy bit bigger before Apple does this?
1. The amazing (to me) transition from 68K to PPC
2. Carbon
<strong>For one, I kinda find it unlikely that Apple has an internal, fully-functional OS X/x86 version, given the horrid state of Darwin/x86 (at least the publicly available version), which in fact manages to have an even shorter hardware compatibility list than BeOS/x86.</strong><hr></blockquote>
Sure, but keep in mind that Apple would retain control of the hardware, even if it were x86-based.
I believe they do have an internal version of OS X for x86 (including a non-public Darwin) which works only on a specific x86 setup, not on any old PC you can pick up at CompUSA.
I would like to remind everyone that Apple did change processor architectures before when it moved from CISC to RISC. I remember buying my first PowerPC Mac and the claim was that the chip was so fast it could run all the old stuff faster under emulation than the old chip.
Folks, depending on what you believe, Intel and AMD chip performance combined with the high rate of change on their MHz and the low rate of change on motorola chips, could soon mean that G4 code could be run faster in emulation on a fast x86 than natively on an actual G4.
Apple uses industry standard parts on every other component of their machines except the CPU. The retardation of the G4 with respect to bus speed support, memory speed support, etc... forces the use of inferior components throughout the rest of the mac line.
If Apple released dual 2.2 Ghz P4 machine with native support of Darwin and the rest of the system emulating a G4, I wouldn't be surprised to see performance vs. today's G4s be roughly equal on an overall basis. Especially since this system would have DDR RAM, 266MHz bus, etc..
It wouldn't cost Apple any more to build than today's G4 based systems.
Why would MicroSoft view Apple as a more direct competitor unless Apple chose to become a software company, just because they used the same CPU that microsoft's software is compiled for. MS would only look at this as another opportunity to go to the wallets of their Mac users with another upgrade, this time compiled for X on x86. In the long run, this can only help them reduce engineering costs where code needs to be optimized for only one chip rather than two.
The notion that hackers could allow any PC user to run MacOS is surely one that Apple could deal with in a number of ways.
In short, I agree that this is possible, and although a large undertaking, perhaps a worthwhile one if indeed the very survival of Apple will depend on it.
This move would finally acknowledge that Apple cannot lead on the engineering of components, and was instead pursuing a niche targeting users who were prepared to pay a premium for systems integrated with software whose reliability, ease of use, appearance and applications were a notch above what the masses buy.
We can't blame Motorola for not being able to keep up with a company that does 1000 times the volume and doesn't have limited resources in the same way Motorola does. Face it, Motorola has lost - they and Apple have yet to admit it - but they're never going to catch up.
The biggest problem with this whole thing just hit me square in the face: Classic apps (and other apps) which may never get recompiled for this new x86 OS X. In order for Apple to make the switch, they would, indeed, have to emulate PPC on x86 (like in the 68K to PPC transition). Yikes. Not impossible, but a huge job. Not to mention you'd need a really wicked-fast x86 to get decent PPC emulation.
Alright, alright, so everybody's saying, "well, duh." I just didn't see it. I was totally honed in on OS X (without Classic) in it's current state, where there really aren't any OS X "native", legacy apps yet.
[ 03-13-2002: Message edited by: spotbug ]</p>
Some of the considerations would be:
1) Probably no more "classic" mode. It would hardly be worth Apples time to port Mac OS X, plus the complexities of "double" emulation would be a pretty big undertaking. Further, by the time they would accomplish this, Classic would be irrelevant anyway.
2) What's the future of x86? Intel is pretty much betting the future on it's IA64 design. So far, Merced was a dud. McKinley will be better, but buy how much? Intel is hedging it's bet on the x86 platform, but doesn't seem committed to it. The next iteration of the P4, code named Prescott is mostly just a die shrunk 90 nanometer process version of the same chip. Then there is AMD's 64bit version of the x86 architecture to consider. In short, switching to "Intel" is a bit more chaotic then you might initially think. There's a real fork in the road for that direction as well.
3) Assuming Apple did convert to x86. Would PCs be able to run OS X? If so, that would quickly shut down Apple as a hardware vendor. There's no way Apple could compete in that market. Also, does anybody remember why OS/2 failed? OS/2 could run Windows applications. Developers no longer felt it was necessary to create a specific OS/2 version of their app for the same hardware platform.
4) Consider the events over the past couple of years. Apple had developers prepare for and learn to code in the new PPC environment. Then they make a major OS change with OS X. This requires a huge amount of work for each developer. Now, we go and tell them that they should switch to entirely x86 afterall? For 3% of the market? Yes, some companies have a much larger percentage of their sales to the Macintosh market, but overall, Apple's marketshare is pretty small and not very infuential to developers.
5) Now, consider that the gain would be? Let's see, you wouldn't notice the difference in speed for business productivity apps, since they aren't CPU bound on todays hardware anyway. Apple's core market makes heavy use of Altivec through key programs like Photoshop, Cleaner5, Final Cut Pro, DVD Stuido Pro, all the "iApps", Quicktime, etc. So, that leaves you with a few specialty apps like 3D rendering where there would be some noticeable improvement. Wow... hardly seems worth it.
6) Now consider that the 2.2 GHZ P4s are as fast as they are because they've already moved to the .13u process. They are already demonstrating P4s on the .09u process. Meanwhile G4's are still being manufactured on the .18u process. In short, the .13u G4s are coming - probably this summer. Apple would be better off designing their own chips and having someone else (that's more current in fabrication technology) produce them as THT has suggested.
7) Maybe Apple knows something we don't, particularly with regards to the G5 and it's performance potential. So, let's forget this notion of switching CPU designs already.
Steve
<strong>Forget classic. Even Carbon apps would be broken.</strong><hr></blockquote>
Yes, but those could be recompiled. Chances are high that a Carbon app still has active development (or at least somebody that could recompile it).
I was talking about stuff that's still in Classic and will never get Carbonized or otherwise move to OS X "native". We still need these to work, thus a PPC emulator would be required in the switch to x86. Maybe when Classic is gone forever (68K is pretty well gone forever, right?), it could happen. The problem then would be how much "native" stuff is legacy at that point.
Going from 68k to PPC didn't have this problem, because the PPC has more registers than 68k did (32 vs. 16 in that case).
PPC emulation on x86 would be a killer for moving the OS to that platform.
That's ignoring that the x86 architecture would be a waste of time to port to anyway, since it is bound to be in flux in the coming years. 64-bit x86 = <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />
There's nothing Steve Jobs dislikes more than legacy technology and I'm sure he hates Classic even more than floppy drives.
It's nice to see some intelligent conversation about the possibility of moving to x86. Usually this is met with a Chicken Little response.
I don't think Microsoft would immediately punish Apple for moving to x86. I doubt Bill Gates even spends one minute a day thinking about Apple. in his mind he has rationalized that Microsoft won the market by giving the people what they want and Apple is like one of those artsy movie theaters that plays films that most people have no interest in. When Steve Jobs announced the switch he could just claim that he felt Motorola would fall behind forever and that using x86 would be save Apple a lot of money in R&D.
For them to do so, they'd have to have a portable (platform independant) operating system, written in a highly portable language, like C, one that can be easily recompiled.
As for apps, this new OS would have to have hooks for some new kind of programming language. Unlike classic or carbon, this language would have to be VERY portable, no legacy. Like C based or something. But objective, so that apps could be built quickly.
This C based, 'objective', future language should have a catchy name, like how Java does. People like coffee. Maybe some other hot beverage. Like say..
...'Ovaltine'.
Anyway, once this portable, C based operating system (pref. a thoroughly tested, rock-solid one, built around industry standards. In fact,it would be nice to see them use a free, open *nix of some sort. Let's say... Linux!) and it's forward thinking object-oriented, C-based 'Ovaltine' APIs were in place, then Apple would be far less platform-dependant. Then maybe they could make the switch, once developers were comfortable with Ovaltine.No PPC emulation, just recompiled, clean, portable code with all the optimization flags set.
(Now that I think about it, Apple could just take Linux, and harness all the developers/apps for it, and focus on the GUI aspect, which Linux has traditionally been weak at! Then Apple could save itself 90% of the work of making their OS! It would be like, The Power of Linux, the Simplicity of the Mac!)
But I do not see such an OS on the horizon. Nor do I think Apple would have the sense to include an advanced API like my theoretical 'Ovaltine'.It's just not going to happen.
And thus is my reasoning that Apple will not make the switch. They never foresaw a situation like they are now in. Besides, PPC, though it doesn't have the market share/profitability, designers/engineers or fabs, and is aimed towards embedded appliances, is still better than a dual AMD box at Photoshop. At least at a couple of filters.
[ 03-14-2002: Message edited by: stimuli ]
[ 03-14-2002: Message edited by: stimuli ]</p>
I'm hoping that Motorola either a) gets its act toghet or b) sells its cpu division to Apple.
I have a new reason for why it'll never happen (as mentioned by others) which isn't technical at all. Making the switch is possible, but a very bad move.
If you put an x86 processor in the box, everybody will expect (probably demand) that it be able to run Windows apps. Makes sense, right? If the Mac is practically a PC (hardware-wise), Apple's going to be under immediate, constant pressure to make OS X run Windows applications. As soon as that happens, however, all the other OS X APIs (Carbon, Cocoa, whatever) are dead. Why would a developer wishing to support OS X use anything other than the Windows API; they get Windows and OS X support all at once. This would make OS X simply a Windows clone (like IBM's OS/2), albeit perhaps better. Apple is then in direct competition with Microsoft which controls the API. Uh oh.
However, this makes me think about the reverse situation: write for Cocoa on OS X and run on Wintel, too. Maybe Apple should bring back the x86 Yellow Box?
<strong>Yellow box is a bad idea. That's how OS/2 got canned. Why write macOS Apps if Windows apps work in OS X anyways.</strong><hr></blockquote>
I think you've got it backwards. x86 Yellow Box is, essentially, Cocoa on Wintel (not Win32 on OS X). You write for OS X (using Cocoa APIs) and it runs, with a dll, on Wintel as well. This is attractive to Windows developers. Instead of writing to the (antiquated