A more practical approach would be to license Mac OS X to the entire IBM range of workstations. IBM does that kind of hardware better than Apple probably could.
....</strong><hr></blockquote>How many people remember that Steve Jobs licensed NeXTSTEP to IBM back in the late '80s or early '90s? I wonder if that agreement is still in effect.
Question: wouldn't Apple have to scrap the Carbon API's for a x86 change over? Not everyone is getting on the Cocoa bandwagon it seems in the developer arena. Wouldn't that make a switch even more painful?</strong><hr></blockquote>
No -- Carbon is an API just like Cocoa is -- there is no reason both of them cannot be endian-safe, and "just work" on any processor architecture -- the hard stuff is handled by the kernel.
The largest obstacle to having code work properly on x86 vs. PPC is handling the fact that the processors handle their register internal differently. Let's say you have this text (read in as a 32 bit integer) in a register on the PPC:
ABCD
That's four bytes of ASCII, sitting in a 32 bit PPC register. On an x86 machine, it would be in the register as:
DCBA
The thing is, this only comes into play when reading something from an external source -- either a file or a from a network packet. So you just need code to make sure that you swap the endianess of what you're reading in -- from then on, everything else "just works"
Since many file formats are already platform-neutral, many of these issues have already been solved for major applications. Any Mac software that reads files in that also work on the PC are handling the endian issues in one manner or another already -- the same with any Mac games that can play networked PC games.
I don't mean to trivialize the problem -- certainly application authors who are not xplat minded will have some work to do in order for their applications to behave properly, but it isn't rocket science.
Carbon is just an API like any other API -- some are cross platform, some aren't -- if they designed it in a processor neutral way, then there's no reason it can't work on any computer architecture. That's one of the reasons you use an API -- let the OS vendor take care of the nasty details for you.
People who have been tracking Apple's move from "The Toolbox" to Carbon will note, no doubt, the inclusions of accessors for low memory globals, and also accessor function for getting at system data structure information (such as a window record).
This allows the API to be more portable, because the details of how the data is stored is hidden from the calling application -- system calls return the information to you in a known format that you can just use.
The work that application developers would have to do would be mostly just ensuring they didn't make endian assumptions when reading in their own file formats or network packets.
<strong>I don't mean to trivialize the problem -- certainly application authors who are not xplat minded will have some work to do in order for their applications to behave properly, but it isn't rocket science.</strong><hr></blockquote>
I think a nice example of how "hard" it is to port software would be the Blender 3D package - they have a 3D realtime animation package that is less than a 2mb download (by now opensource, GPL, so you you all can have a look at the <a href="http://www.blender.org"; target="_blank">www.blender.org</a> website). It runs on anything from x86 PCs (Windows/Linux) to Sparc, PowerPC and MIPS architectures. When they started out in 1998 their motto was "You want a port - send us a free hardware kit and we port it for you in a few days max."
When the first PowerPC Linux port was made the developer (Daniel Dunbar, extremely talented, imho) simply moved the source to the machine and asked "So, is it big or small endian?" and had it compile shortly after that. Oh and there even was an iPaq port around.
Btw, Apple is one of the main sponsors of the Blender Foundation - they recieved a nice dual ghz XServe to host the site on.
Whether Carbon can be made to work on the other platform or not, asking developers like Adobe or Macromedia to build OS X apps for x86 means more work for them, not less. Their Win32 code bases will remain separate from any future Mac OS code base, just like they are now. The APIs will remain different, the interfaces will remain different, etc.
Again, until someone can give a logical reason why 3rd party developers like Adobe or Aspyr or Filemaker will want to spend the time and money to port their apps *again*, for an OS that will have a significantly smaller user base than even OS X right now ... I can't see how this will possibly materialize. It's just not practical - especially in slow economies.
And the idea of Win32 apps running on OS X makes me ill. I don't want to run apps with crappy Windows interfaces; I paid for and use OS X for a reason. As someone else pointed out earlier - if I want to use Windows programs I'll buy a Windows box.
[quote]""Now software... Adobe, Microsoft, Macromedia, Quark, Intuit... You name it. Nearly ALL Mac software developers also develop for Wintel. Imagine if these companies could maintain a single code-base to support all platforms. Theoretically, the hardware is the same. I know there's much more to software development than targeting the hardware, but that's just one less thing to worry about."
I want applications with a Mac OS X interface. If I want Windows apps, I'll run Windows. If I have taste and want good interfaces in applications, I'll buy Mac OS X. What your proposing eliminates the key advantage Macs have over Wintel. ITS ABOUT THE SOFTWARE, AND MAC SOFTWARE IS BETTER." <hr></blockquote>
I agree. Mac versions of the software is better. That's why I use a Mac. The implication is that devs retain the Mac base to use for targeting the Windows platform. A Mac base could be used for Mac, Windows, or other *NIX. The Windows base would only work for Windows. If you had both bases, which would you scrap?
[quote]Apple does what IBM tried to to. Sell boxes with a Windows compatible OS. That failed. People buy Windows because they are sheep. Sheep won't buy Mac OS X if it runs Wintel apps, because it is still different. The only way Apple will, without becoming a PC-clone maker, ever get marketshare over 10% is if Microsoft collapses.<hr></blockquote>
I don't believe it is impossible. Most of the people I know who haven't yet switched to the Mac are holding out because of some very specific software titles. (Much like why many haven't yet upgraded from OS9) Few want to re-purchase their entire software library (assuming they even could) to move to the Mac platform. Imagine what would happen if they didn't have to. Just think of the Ad: "Windows crashed? Good thing you're on OSX!"
[quote]""Now software... Adobe, Microsoft, Macromedia, Quark, Intuit... You name it. Nearly ALL Mac software developers also develop for Wintel. Imagine if these companies could maintain a single code-base to support all platforms. Theoretically, the hardware is the same. I know there's much more to software development than targeting the hardware, but that's just one less thing to worry about."
I want applications with a Mac OS X interface. If I want Windows apps, I'll run Windows. If I have taste and want good interfaces in applications, I'll buy Mac OS X. What your proposing eliminates the key advantage Macs have over Wintel. ITS ABOUT THE SOFTWARE, AND MAC SOFTWARE IS BETTER." <hr></blockquote>
I agree. Mac versions of the software is better. That's why I use a Mac. The implication is that devs retain the Mac base to use for targeting the Windows platform. A Mac base could be used for Mac, Windows, or other *NIX. The Windows base would only work for Windows. If you had both bases, which would you scrap?
[quote]Apple does what IBM tried to to. Sell boxes with a Windows compatible OS. That failed. People buy Windows because they are sheep. Sheep won't buy Mac OS X if it runs Wintel apps, because it is still different. The only way Apple will, without becoming a PC-clone maker, ever get marketshare over 10% is if Microsoft collapses.<hr></blockquote>
I don't believe it is impossible. Most of the people I know who haven't yet switched to the Mac are holding out because of some very specific software titles. (Much like why many haven't yet upgraded from OS9) Few want to re-purchase their entire software library (assuming they even could) to move to the Mac platform. Imagine what would happen if they didn't have to. Just think of the Ad: "Windows crashed? Good thing you're on OSX!"
<strong>You know, Apple could migrate the xServe to an AMD chip--that's kind of crazy, but since they don't have to worry so much about legacy apps, it isn't totally nutso.</strong><hr></blockquote>
I like this plan the best. This gets Macs around some of the purchasing rules in some anti-mac shops. The bulk of OS X server's 'power' tools are OSS anyway. The third party tools people would want on the server aren't GUI kings and generally have an XWindows version.
And the best part is it ties in with the steep price differential due to not paying for Doze-clients. (Mac OS X Server has unlimited clients allowed).
The 'normal' plan: sell $500 x86 (or AMD) boxen with an Apple logo. Suck the R&D out of somewhere else, because the $500 box is a loss leader. Pray you don't sell too many.
The 'XServe-AMD' plan: sell $4000 AMD boxes with an Apple logo. We're already in the well-padded area -> probably profitable at a very low number of boxes sold.
Compared to the 'normal' plan, the 'XServe-AMD' seems like low-hanging fruit.
Comments
<strong>....
A more practical approach would be to license Mac OS X to the entire IBM range of workstations. IBM does that kind of hardware better than Apple probably could.
....</strong><hr></blockquote>How many people remember that Steve Jobs licensed NeXTSTEP to IBM back in the late '80s or early '90s? I wonder if that agreement is still in effect.
<strong>Hey, long time lurker, first time poster.
Question: wouldn't Apple have to scrap the Carbon API's for a x86 change over? Not everyone is getting on the Cocoa bandwagon it seems in the developer arena. Wouldn't that make a switch even more painful?</strong><hr></blockquote>
No -- Carbon is an API just like Cocoa is -- there is no reason both of them cannot be endian-safe, and "just work" on any processor architecture -- the hard stuff is handled by the kernel.
The largest obstacle to having code work properly on x86 vs. PPC is handling the fact that the processors handle their register internal differently. Let's say you have this text (read in as a 32 bit integer) in a register on the PPC:
ABCD
That's four bytes of ASCII, sitting in a 32 bit PPC register. On an x86 machine, it would be in the register as:
DCBA
The thing is, this only comes into play when reading something from an external source -- either a file or a from a network packet. So you just need code to make sure that you swap the endianess of what you're reading in -- from then on, everything else "just works"
Since many file formats are already platform-neutral, many of these issues have already been solved for major applications. Any Mac software that reads files in that also work on the PC are handling the endian issues in one manner or another already -- the same with any Mac games that can play networked PC games.
I don't mean to trivialize the problem -- certainly application authors who are not xplat minded will have some work to do in order for their applications to behave properly, but it isn't rocket science.
Carbon is just an API like any other API -- some are cross platform, some aren't -- if they designed it in a processor neutral way, then there's no reason it can't work on any computer architecture. That's one of the reasons you use an API -- let the OS vendor take care of the nasty details for you.
People who have been tracking Apple's move from "The Toolbox" to Carbon will note, no doubt, the inclusions of accessors for low memory globals, and also accessor function for getting at system data structure information (such as a window record).
This allows the API to be more portable, because the details of how the data is stored is hidden from the calling application -- system calls return the information to you in a known format that you can just use.
The work that application developers would have to do would be mostly just ensuring they didn't make endian assumptions when reading in their own file formats or network packets.
<strong>I don't mean to trivialize the problem -- certainly application authors who are not xplat minded will have some work to do in order for their applications to behave properly, but it isn't rocket science.</strong><hr></blockquote>
I think a nice example of how "hard" it is to port software would be the Blender 3D package - they have a 3D realtime animation package that is less than a 2mb download (by now opensource, GPL, so you you all can have a look at the <a href="http://www.blender.org"; target="_blank">www.blender.org</a> website). It runs on anything from x86 PCs (Windows/Linux) to Sparc, PowerPC and MIPS architectures. When they started out in 1998 their motto was "You want a port - send us a free hardware kit and we port it for you in a few days max."
When the first PowerPC Linux port was made the developer (Daniel Dunbar, extremely talented, imho) simply moved the source to the machine and asked "So, is it big or small endian?" and had it compile shortly after that. Oh and there even was an iPaq port around.
Btw, Apple is one of the main sponsors of the Blender Foundation - they recieved a nice dual ghz XServe to host the site on.
Again, until someone can give a logical reason why 3rd party developers like Adobe or Aspyr or Filemaker will want to spend the time and money to port their apps *again*, for an OS that will have a significantly smaller user base than even OS X right now ... I can't see how this will possibly materialize. It's just not practical - especially in slow economies.
And the idea of Win32 apps running on OS X makes me ill. I don't want to run apps with crappy Windows interfaces; I paid for and use OS X for a reason. As someone else pointed out earlier - if I want to use Windows programs I'll buy a Windows box.
I want applications with a Mac OS X interface. If I want Windows apps, I'll run Windows. If I have taste and want good interfaces in applications, I'll buy Mac OS X. What your proposing eliminates the key advantage Macs have over Wintel. ITS ABOUT THE SOFTWARE, AND MAC SOFTWARE IS BETTER." <hr></blockquote>
I agree. Mac versions of the software is better. That's why I use a Mac. The implication is that devs retain the Mac base to use for targeting the Windows platform. A Mac base could be used for Mac, Windows, or other *NIX. The Windows base would only work for Windows. If you had both bases, which would you scrap?
[quote]Apple does what IBM tried to to. Sell boxes with a Windows compatible OS. That failed. People buy Windows because they are sheep. Sheep won't buy Mac OS X if it runs Wintel apps, because it is still different. The only way Apple will, without becoming a PC-clone maker, ever get marketshare over 10% is if Microsoft collapses.<hr></blockquote>
I don't believe it is impossible. Most of the people I know who haven't yet switched to the Mac are holding out because of some very specific software titles. (Much like why many haven't yet upgraded from OS9) Few want to re-purchase their entire software library (assuming they even could) to move to the Mac platform. Imagine what would happen if they didn't have to. Just think of the Ad: "Windows crashed? Good thing you're on OSX!"
I want applications with a Mac OS X interface. If I want Windows apps, I'll run Windows. If I have taste and want good interfaces in applications, I'll buy Mac OS X. What your proposing eliminates the key advantage Macs have over Wintel. ITS ABOUT THE SOFTWARE, AND MAC SOFTWARE IS BETTER." <hr></blockquote>
I agree. Mac versions of the software is better. That's why I use a Mac. The implication is that devs retain the Mac base to use for targeting the Windows platform. A Mac base could be used for Mac, Windows, or other *NIX. The Windows base would only work for Windows. If you had both bases, which would you scrap?
[quote]Apple does what IBM tried to to. Sell boxes with a Windows compatible OS. That failed. People buy Windows because they are sheep. Sheep won't buy Mac OS X if it runs Wintel apps, because it is still different. The only way Apple will, without becoming a PC-clone maker, ever get marketshare over 10% is if Microsoft collapses.<hr></blockquote>
I don't believe it is impossible. Most of the people I know who haven't yet switched to the Mac are holding out because of some very specific software titles. (Much like why many haven't yet upgraded from OS9) Few want to re-purchase their entire software library (assuming they even could) to move to the Mac platform. Imagine what would happen if they didn't have to. Just think of the Ad: "Windows crashed? Good thing you're on OSX!"
<strong>You know, Apple could migrate the xServe to an AMD chip--that's kind of crazy, but since they don't have to worry so much about legacy apps, it isn't totally nutso.</strong><hr></blockquote>
I like this plan the best. This gets Macs around some of the purchasing rules in some anti-mac shops. The bulk of OS X server's 'power' tools are OSS anyway. The third party tools people would want on the server aren't GUI kings and generally have an XWindows version.
And the best part is it ties in with the steep price differential due to not paying for Doze-clients. (Mac OS X Server has unlimited clients allowed).
The 'normal' plan: sell $500 x86 (or AMD) boxen with an Apple logo. Suck the R&D out of somewhere else, because the $500 box is a loss leader. Pray you don't sell too many.
The 'XServe-AMD' plan: sell $4000 AMD boxes with an Apple logo. We're already in the well-padded area -> probably profitable at a very low number of boxes sold.
Compared to the 'normal' plan, the 'XServe-AMD' seems like low-hanging fruit.