Red Box for MacIntel ; Yellow Box for Wintel
... or how to run Windows apps on Mac, and Mac apps on Windows.
Before Mac OS X 10.0 was achieved, the work-in-progress project was called "Rhapsody". At this time Rhapsody ran officially onto PowerPC and Intel x86 processors (two separate versions). Well, now we know that this has been the case for each Mac OS X version. And in the future, we can argue that only the Intel version will survive.
But circa '97/98, there was also two projects linked to Rhapsody:
- "Red Box", which ran onto Rhapsody for Intel: it could execute Windows applications right into our system.
- "Yellow Box for Windows" then "Cocoa for Windows", a port of Objective-C (Cocoa) APIs as a layer on Windows: Cocoa Mac apps right into Microsoft's OS.
1/ Mac OS X for Intel now is pretty much the same thing as Rhapsody for Intel was (plus evolution), so I think with version 10.5 Leopard we will see the return of Red Box. Perhaps not directly from Apple (who really knows?) but certainly from projects such as WINE, derivatives such as CrossOver from CodeWeavers (who already committed for it), and OS virtualization softwares such as VMware (this kind even becoming part of the hardware itself with future Intel "Vanderpool" technology).
? Read the article "OS X Leopard to be compatible with Windows Apps?" from Kelly McNeill, at OSviews.com Jun 23, 2005).
2/ As for Yellow Box for Windows, I think the project was terminated with the birth of Mac OS X because from day one, most of developers refused to rewrite all their Mac OS C++ source codes from scratch into Objective-C/Java. That's even why Apple had to introduce Carbon APIs: to make the transition easier.
Now with Mac OS X on Intel, all developers finally must drop their CodeWarrior-like environments to use Xcode. One processor, one developing tool (hey that's exactly what Apple wanted them to do initially...). And Cocoa for Windows can come back to life.
? Read these blogger posts: "It's all about Xcode, not Intel" (06/9/2005) and "Cocoa for Windows? Xcode for Windows?" (069/10/2005).
So Windows applications could run on Mac OS X.
And Mac OS X applications could run under Windows.
Before Mac OS X 10.0 was achieved, the work-in-progress project was called "Rhapsody". At this time Rhapsody ran officially onto PowerPC and Intel x86 processors (two separate versions). Well, now we know that this has been the case for each Mac OS X version. And in the future, we can argue that only the Intel version will survive.
But circa '97/98, there was also two projects linked to Rhapsody:
- "Red Box", which ran onto Rhapsody for Intel: it could execute Windows applications right into our system.
- "Yellow Box for Windows" then "Cocoa for Windows", a port of Objective-C (Cocoa) APIs as a layer on Windows: Cocoa Mac apps right into Microsoft's OS.
1/ Mac OS X for Intel now is pretty much the same thing as Rhapsody for Intel was (plus evolution), so I think with version 10.5 Leopard we will see the return of Red Box. Perhaps not directly from Apple (who really knows?) but certainly from projects such as WINE, derivatives such as CrossOver from CodeWeavers (who already committed for it), and OS virtualization softwares such as VMware (this kind even becoming part of the hardware itself with future Intel "Vanderpool" technology).
? Read the article "OS X Leopard to be compatible with Windows Apps?" from Kelly McNeill, at OSviews.com Jun 23, 2005).
2/ As for Yellow Box for Windows, I think the project was terminated with the birth of Mac OS X because from day one, most of developers refused to rewrite all their Mac OS C++ source codes from scratch into Objective-C/Java. That's even why Apple had to introduce Carbon APIs: to make the transition easier.
Now with Mac OS X on Intel, all developers finally must drop their CodeWarrior-like environments to use Xcode. One processor, one developing tool (hey that's exactly what Apple wanted them to do initially...). And Cocoa for Windows can come back to life.
? Read these blogger posts: "It's all about Xcode, not Intel" (06/9/2005) and "Cocoa for Windows? Xcode for Windows?" (069/10/2005).
So Windows applications could run on Mac OS X.
And Mac OS X applications could run under Windows.
Comments
Originally posted by Cosmos 1999
...
But circa '97/98, there was also two projects linked to Rhapsody:
- "Red Box", which ran onto Rhapsody for Intel: it could execute Windows applications right into our system.
The Red Box was a rumor, not a project. Knowing all that we know now, I think it safe to say that a rumor is all that it ever was.
Originally posted by Cosmos 1999
- "Yellow Box for Windows" then "Cocoa for Windows", a port of Objective-C (Cocoa) APIs as a layer on Windows: Cocoa Mac apps right into Microsoft's OS.
Objective-C is a programming language, not a set of API's. The Yellow Box was really just OpenSTEP. NeXT had so well abstracted OpenSTEP from the underlying kernel that it was deployed on Mach, Windows NT, Solaris, and a few other OSes, IIRC, the Yellow Box was supposed to extend the supported hosts to include MacOS 9, and others. That's right, Apple's plans for Rhapsody included running the Yellow Box on MacOS 9 as well as running the Blue Box (MacOS 9) on Rhapsody.
Originally posted by Cosmos 1999
... I think with version 10.5 Leopard we will see the return of Red Box. Perhaps not directly from Apple (who really knows?) ...
We cannot return to the Red Box because it never existed. And we do know. The open source community will have WINE on MacOS X/Intel in short order. CodeWeaver has indeed announced that it is porting CrossOver. Microsoft will port VPC:mac to Intel. Other emulators and virtual machines can be expected to support Windows applications on the Mac. Why should Apple spend its resources on this effort when so many others are willing to do it?
Originally posted by Cosmos 1999
2/ As for Yellow Box for Windows, I think the project was terminated with the birth of Mac OS X because from day one, most of developers refused to rewrite all their Mac OS C++ source codes from scratch into Objective-C/Java. That's even why Apple had to introduce Carbon APIs: to make the transition easier.
You are confusing issues. Yellow Box for Windows was practically a free ride for Rhapsody developers. They would just continue to do what OpenSTEP developers had done for years. They distributed what we now call universal binaries. The best theory is that Apple killed the Yellow Box for Windows because it did not want to be in the business of supporting Windows.
Originally posted by Cosmos 1999
Now with Mac OS X on Intel, all developers finally must drop their CodeWarrior-like environments to use Xcode. One processor, one developing tool (hey that's exactly what Apple wanted them to do initially...). And Cocoa for Windows can come back to life.
They don't have to do anything. However, moving to Xcode gives developers the greater number of options for the least amount of work.
Originally posted by Cosmos 1999
So Windows applications could run on Mac OS X.
And Mac OS X applications could run under Windows.
There is no doubt about the former. Although Apple has made no such announcement about the latter, it would not surprise me. Most people would disagree and Apple's actions so far support that view.
When it comes down to it, it is essentially Virtual Mac for Windows users. Sure in theory it could be developed by Apple, and allow developers to deploy their applications across multiple OS (sounds familiar?).
But how really how useful would it be for a hardware company to allow software written for its hardware to used on a non-Apple hardware computer.
What would the point of buying a Mac if I could run Yellowbox (i.e., Cocoa) applications on a cheap PC though Apple's Yellowbox environment? This is really no different than installing Mac OS X on a cheap PC.
Originally posted by Dave K.
When it comes down to it, it is essentially Virtual Mac for Windows users.
Actually no. It is completely different from a Mac emulation like VPC is a PC emulation.
But how really how useful would it be for a hardware company to allow software written for its hardware to used on a non-Apple hardware computer.
Remember Ballmer's monkey dance? Developers, developers, developers, developers...
There has been a tug-of-war going on for at least 15 years now about developer support. The critical thing is the API developers choose to code to, because it usually favors one platform over the other.
Making OS/2 compatible with the Windows API was one of the reasons for its demise. WINE is one of the reasons hardly any commercial software is ported to Linux.
Reinvigorating Cocoa for Windows could convince some developers to choose it over .NET/C#.
The OS will lose its importance over the next 10 years, because less and less developers will be willing to let themselves be tied to one platform or maintain two or more codebases. This will be a major challenge for Apple, but getting devs to their API can only be a good thing.
Originally posted by Smircle
Reinvigorating Cocoa for Windows could convince some developers to choose it over .NET/C#.
Yes! This is THE point.
Note that iTunes is still a Carbon app, and not yet Mac OS X x86-native. In Jobs' demo, it ran with the help of Rosetta.
Whether or not it is ported on MacIntel using Cocoa or Carbon in Xcode, I don't know (anyone?). But I though that it was Carbon to help the development remaining on par with its Windows counterpart.
If iTunes 5 must be Cocoa, then how will they derivate the Windows version from it?
iTunes for Windows is the best "Apple trojan horse" so far. In fact it is even the best "trojan horse inside trojan horse" considering it installs QuickTime on Windows too.
Now imagine iTunes 5 is made using Cocoa. No need to make two separate versions anymore. Put "WinCocoa" DLLs inside the installer package, and that's it. Third trojan level, enabling use of all others Cocoa applications
Also, let people download "WinCocoa" for free as a standalone installer, and developers use it to make Really-Universal Binaries apps with Xcode, where they would compile a single Cocoa bundle "Mac OS X PPC" + "Mac OS X x86" + "Windows x86".
This would not kill the need to own Mac OS X, because even if Windows could run Mac applications, it will still never offer the same user experience as Apple's OS.
Originally posted by Cosmos 1999
Now imagine iTunes 5 is made using Cocoa. No need to make two separate versions anymore. Put "WinCocoa" DLLs inside the installer package, and that's it. Third trojan level, enabling use of all others Cocoa applications
Also, let people download "WinCocoa" for free as a standalone installer, and developers use it to make Really-Universal Binaries apps with Xcode, where they would compile a single Cocoa bundle "Mac OS X PPC" + "Mac OS X x86" + "Windows x86".
This would not kill the need to own Mac OS X, because even if Windows could run Mac applications, it will still never offer the same user experience as Apple's OS.
I am not sure how this is accomplished, though this is what I was thinking during the keynote as well.
Make the Cocoa API widely distributed accross platforms and let developers compile applications to different platforms/OSes in one go.
Stretching this very wide, I'm not really sure how useable it becomes. Say Cocoa supported 3 platforms with 2 different OSes on each (very little probability, but still doable), which means a universal binary would have to include 6 versions of the same executable.
Even with the XBox now being based on PPC (Cell), "porting" the Cocoa API for compilation to the Xbox 360 Windows, a universal binary would include runnable code for:
- MacOS X PPC
- MacOS X x86
- Win x86
- Xbox PPC
Not considering the huge overhead of compilation of each and every application, accually testing and making sure that your applications are running correctly accross platforms and operating systems are a giant task. If this is the case, I would much more prefer to use a Virtual Machine language with a much-improved HotSpot Compiler (That accually compiles the HotSpots into a persistant storage on the harddrive, instead of being lost when the application quits - being the case with todays HotSpot).
In the long run, I do think that VM languages will have the edge over compiled languages. I'm doing mostly Java programming myself, and I love the portability of it. The Cocoa API would kinnda provide the same portability with Universal Binaries, but I think that the accual compilation to different platforms and increasing the applications size isn't neccessarily the proper way to deal with it (in the future).
Originally posted by Cosmos 1999
This would not kill the need to own Mac OS X, because even if Windows could run Mac applications, it will still never offer the same user experience as Apple's OS. [/B]
I'm not sure that this is a risk either way. I mean C#-developed applications can run on MacOS X through the mono project, but I do not think that this has had an impact on the sales of either MacOS or Windows. I mean, if all applications were developed in one programming language, but they could still be ran on any operating system (Kinnda like Java applications), operating systems would have to start competing at a different level.
Today this fight is 1. who ha the most/best applications, 2. who has the best features / is the most user friendly - in that order of "importance". If appliations could run accross any operating systems the fight would be very different, and only concerning which operating system that were the most user friendly, or the best features, alternatively how secure the operating system is and how stable it is.
That being said, I certainly do not miss Windows' viruses, trojan horses, malware, bloatware, etc.
Originally posted by BoeManE
Stretching this very wide, I'm not really sure how useable it becomes. Say Cocoa supported 3 platforms with 2 different OSes on each (very little probability, but still doable), which means a universal binary would have to include 6 versions of the same executable.
But is this really the case ? Sure there are two different binaries (inside one bundle) between x86 and PPC version of a Mac application, but would there also be two different binaries between x86 Cocoa under Mac OS X and x86 Cocoa under Windows? I don't think so. I think that one signle x86 Cocoa binary can run whatever the OS, if that OS has a Cocoa runtime in it.
TextEdit, TIFFany, Interface Builder etc... ran onto Yellow Box for Windows NT 4.0 and Yellow Box for Windows 200 Pro (screenshots available) in the past. But these applications were not especially compiled for MS OSes, were they?
I think the compile options for a pure Cocoa development project would only be:
- PPC (Mac OS X on PowerPC processors)
- x86 (Mac OS X or Windows or other OS on Intel processors)
Thus the only thing you need to run the application on the various OSes would be Cocoa runtime layer intalled (except for Mac OS X, which already has Cocoa).
Do I make any mistake?
Originally posted by Cosmos 1999
I think that one signle x86 Cocoa binary can run whatever the OS, if that OS has a Cocoa runtime in it.
TextEdit, TIFFany, Interface Builder etc... ran onto Yellow Box for Windows NT 4.0 and Yellow Box for Windows 200 Pro (screenshots available) in the past. But these applications were not especially compiled for MS OSes, were they? [/B]
I'm not sure if they were especially compiled. I guess it the WinCocoa DLL in windows would map to make Windows GUI calls (whatever they are, can't remember) I guess this would work.
know that if I compile a Cocoa application on my Mac that it lies on a layer on top of the operating system making calls to it, and it is the operating systems responsibility to render the on-screen presentation of the GUI, and to handle user input (and forward these to the application).
Apple has a few charts on their site showing the system layers:
(Taken from: http://developer.apple.com/documenta...iew/index.html)
Windows would have a similar type of setup, so I guess a WinCocoa DLL could lie in between the application and the operating system, translating all the Cocoa call to WinAPI calls. This would of-course be somewhat time consuming, but developers might not care about the (small) performance cost. After all the Cocoa API is a really good API, which is certainly the case now with "Core" APIs apple has added to Cocoa.
Heck, now that Cocoa is mature enough to ensure developers that the Core classes (I mean the Core classes, not the Core APIs) wont change much in the future, A WinCocoa DLL might even be a very good option. I would most defiantely be using Cocoa to develop applications for Windows if I could choose between Cocoa and the Win32 API.
Note. From the images of YellowBox you provided they all have the Windows look and feel, which suggests to me that this is the approach apple used with the Yellow Box, unless the Yellowbox would accually compile into "normal" Windows .exe files, converting from cocoa to win32. The former seems like the elegant apple way of doing such an implementation, while the second one seems like a less elegant way of solving the problem.
Originally posted by BoeManE
I am not sure how this is accomplished, though this is what I was thinking during the keynote as well.
Make the Cocoa API widely distributed accross platforms and let developers compile applications to different platforms/OSes in one go.
Stretching this very wide, I'm not really sure how useable it becomes. Say Cocoa supported 3 platforms with 2 different OSes on each (very little probability, but still doable), which means a universal binary would have to include 6 versions of the same executable.
Even with the XBox now being based on PPC (Cell), "porting" the Cocoa API for compilation to the Xbox 360 Windows, a universal binary would include runnable code for:
- MacOS X PPC
- MacOS X x86
- Win x86
- Xbox PPC
Not considering the huge overhead of compilation of each and every application, accually testing and making sure that your applications are running correctly accross platforms and operating systems are a giant task. If this is the case, I would much more prefer to use a Virtual Machine language with a much-improved HotSpot Compiler (That accually compiles the HotSpots into a persistant storage on the harddrive, instead of being lost when the application quits - being the case with todays HotSpot).
In the long run, I do think that VM languages will have the edge over compiled languages. I'm doing mostly Java programming myself, and I love the portability of it. The Cocoa API would kinnda provide the same portability with Universal Binaries, but I think that the accual compilation to different platforms and increasing the applications size isn't neccessarily the proper way to deal with it (in the future).
No. Cocoa applications would ship as universal binaries on a single CD or DVD. The runtine environment for non-MacOS X hosts could be a separate installation. If you support Win XP, the runtime needs to be installed only once. All Cocoa applications would use the same runtime environment. This would require no "huge overhead of compilation of each and every application" because developers could compile to a single target.