Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Yellow Box for Windows Still Exists?
- Thread starter MacRumors
- Start date
- Sort by reaction score
No, more likely done on downloads, otherwise it would be outright lying, a line I'm pretty sure Apple would not be willing to cross so blatantly.
It is easy enough for them to track the downloads themselves. There are several different ways, including: making the download link link to a page which tracks the download and then redirects to the download; making the download itself be a page which tracks the download and then streams the file; having a module on the server which tracks the views for a certain page/file (the file being the download), and having a full server log and something which parses the full server logs (this is unlikely, though, in my opinion).
that's not what he's saying.
Apple is reporting downloads.
Browser marker share is based on actual web traffic. So people have to both download Safari and use it to boost market share.
I think people are underestimating the number of people who will actually use safari. There are quite a few mac people in the world who are forced to use Windows as well for whatever reason. Many of those people will opt to use safari to have a consistent browser experience. That's an instant boost in market share.
A ton of people use iTunes on Windows. Many of those same people will feel quite comfortable with Safari. Especially when Safari is out of beta, Apple can make installing safari an option when people upgrade their iTunes. They have a million downloads of iTunes/day. They don't need them all to run safari to boost market share, but they have a built in way to get people to try it out. And when they do, people will like little things like resizing the text entry fields, like I did for this post. Rearranging tabbed views, etc.
And it's pretty much completely irrelevant what windows die hards think about Safari. Dual OS users, iPod owners, iTunes users. That's a pretty big pool of potential users.
Apple is reporting downloads.
Browser marker share is based on actual web traffic. So people have to both download Safari and use it to boost market share.
I think people are underestimating the number of people who will actually use safari. There are quite a few mac people in the world who are forced to use Windows as well for whatever reason. Many of those people will opt to use safari to have a consistent browser experience. That's an instant boost in market share.
A ton of people use iTunes on Windows. Many of those same people will feel quite comfortable with Safari. Especially when Safari is out of beta, Apple can make installing safari an option when people upgrade their iTunes. They have a million downloads of iTunes/day. They don't need them all to run safari to boost market share, but they have a built in way to get people to try it out. And when they do, people will like little things like resizing the text entry fields, like I did for this post. Rearranging tabbed views, etc.
And it's pretty much completely irrelevant what windows die hards think about Safari. Dual OS users, iPod owners, iTunes users. That's a pretty big pool of potential users.
err.. Yellow box was to help devs port their Mac apps to Windows, not to help them port their windows apps to Mac.
It's also one of the few browsers that correctly renders the Acid2 test. IE can't do it, Firefox can't do it. Opera can but only at v9. There is value in a browser that is as compliant with standards as we can reasonably test it to be. Safari has it's warts (proxy support, among a list of others) but I've downloaded it on windows and keep it around just because I now have a compliant browser to test against.
More web developers should do the same.
Hoax?
The package has six C source files, all sample code provided by Apple. Five of these are authored by Ali Ozer who writes TextEdit and one is authored by Derek Clegg also of Apple.
It also has a "README" explaining how you build the apps.
But it also has five .DS_Store files.
He says he does this natively on Windows yet the "zip" he provides is ripe with .DS_Store files which you don't exactly get on Windows.
The package has six C source files, all sample code provided by Apple. Five of these are authored by Ali Ozer who writes TextEdit and one is authored by Derek Clegg also of Apple.
It also has a "README" explaining how you build the apps.
But it also has five .DS_Store files.
He says he does this natively on Windows yet the "zip" he provides is ripe with .DS_Store files which you don't exactly get on Windows.
There are two options here. Either you'd jump all over Cocoa or you're nowhere near being a developer. Not a professional one at any rate.
Oh I get it. Hey everyone! Stop what you're doing and check this out! This is a GREAT IDEA! Let's make all our apps with a totally crapped out interface and full of security holes - and then we can sell millions on Windows!
Get out of the Mac bubble!
Yes, it's an open source project (Cocoatron) rather than official, but the philosophy is the same. Let's hope it gets up to production quality soon!
I'm not going to go through the whole thread picking out individuals to correct, though (on the whole) this is one of the least off base NeXT related threads I've seen in a long time.
Given that, lets hit on some topics that seem like areas of confusion for many people.
What is Yellow Box?
It is an application environment based on the OpenStep APIs (which in turn were based on the NEXTSTEP APIs but were modified by NeXT and Sun to create the OpenStep Specification). This was the native application environment of Rhapsody (for more on Rhapsody, I wrote a What is Rhapsody article for my Rhapsody web site), but it was also designed to be cross platform (as in multiple operating systems).
Yellow Box for Windows
As has been pointed out, there was a product called OpenStep Enterprise for Windows. In the NeXT days (that is, before 2000 when Apple stopped selling NeXT products) this was the foundation of a number of key products, including Portable Distributed Objects, Enterprise Objects Framework and WebObjects.
Apple was considering continuing along these lines and included Yellow Box for Windows with the Rhapsody developer releases in 1997 and 1998.
What happened to Yellow Box for Windows?
Nothing, really...
It was never actually supposed to be a shipping product. The idea was the developers would license the runtime environment from Apple and include it with their Yellow Box apps so they could run on Windows systems. That licensing deal is what was cut off.
Yellow Box (everything that was included on the developer CDs) was released within WebObjects 4. And any applications developed for Yellow Box for Windows ran just fine on Windows with WebObjects 4.x.x installed.
Rhapsody apps for Windows... not quite
One of the biggest misconceptions about Yellow Box for Windows was that this was a write once, use anywhere type of development environment. It wasn't.
Yellow Box applications for Rhapsody would not run within Yellow Box for Windows without some extensive reworking. As such, only the smallest handful of Rhapsody apps were ever ported to Yellow Box for Windows (I display a number of these in screen shots of Yellow Box on Windows NT 4 and Yellow Box on Windows 2000 Professional).
Other Boxes
To help with the transition to Rhapsody, Apple developed Blue Box which seems to be largely based on the technology used for MAE (Macintosh Application Environment for Unix systems) and A/UX.
While early versions had some issues with running a little slow, the later versions that were included with Rhapsody 5.3-5.6 (Mac OS X Server 1.0-1.2) were actually very nice speedwise (I ran a test on my main Rhapsody system using Mathematica, the results are here), and the Blue Box environment is much more stable than the Mac OS running on it's own.
There are rumors all around that Apple was developing Red Box for the Intel version of Rhapsody. I cover that area in an article here.
That brings us to the Where are they now? section.
Yellow Box became Cocoa. And while everyone seems up in arms about Apple not making Carbon 64 bit, I would point out that the best Mac apps actually make use of both Carbon and Cocoa frameworks. Developers have been mixing the two to get the best of both for many years now.
While I pointed out that Yellow Box for Windows basically became WebObjects 4, Apple made some major changes with WebObjects 5... mainly the removal of Objective C support (making it Java only).
While many are under the misconception that the Rhapsody project was a failure, that couldn't be further from the truth... unless Mac OS X is a failure. Mac OS X is an evolution of Rhapsody.
The first thing Apple did was put in Carbon. While many mistakenly think this was some how based on code used for QuickTime... it wasn't. QuickTime had been on Rhapsody from the very beginning, without Carbon. The foundations of Carbon are based in Copland. Apple's developers were already hard at work developing a streamlined version of the Macintosh Toolbox that could be implemented on a kernel based operating system when the Copland project was dropped. When looking for a similar solution for Rhapsody, that Copland environment was placed within Rhapsody to make a suitable environment for existing Mac apps with small amounts of code changes. Within weeks of getting Carbon into Rhapsody a number of demo apps were compiled and running (including Simple Text, AppleWorks and Photoshop 5).
The second thing was removal of licensed aspects of 4.4BSD from Rhapsody's foundation (which gave us Darwin) followed by the removal of Adobe's Display Postscript. Both of these steps were taken to reduce the cost of the operating system. Considering that Rhapsody 5.6 cost about $500 where as Mac OS X v10.0 cost $129, I'd say that Apple did a good job of getting rid of expensive licenses.
Rhapsody was sold as a product from early 1999 until the summer of 2001, and the very first developer release of Mac OS X (Mac OS X Developer Preview 1) was nearly identical to the shipping version of Rhapsody (Mac OS X Server 1.x) from a users stand point.
So yeah, from my point of view, Rhapsody was very successful.
Given that, lets hit on some topics that seem like areas of confusion for many people.
What is Yellow Box?
It is an application environment based on the OpenStep APIs (which in turn were based on the NEXTSTEP APIs but were modified by NeXT and Sun to create the OpenStep Specification). This was the native application environment of Rhapsody (for more on Rhapsody, I wrote a What is Rhapsody article for my Rhapsody web site), but it was also designed to be cross platform (as in multiple operating systems).
Yellow Box for Windows
As has been pointed out, there was a product called OpenStep Enterprise for Windows. In the NeXT days (that is, before 2000 when Apple stopped selling NeXT products) this was the foundation of a number of key products, including Portable Distributed Objects, Enterprise Objects Framework and WebObjects.
Apple was considering continuing along these lines and included Yellow Box for Windows with the Rhapsody developer releases in 1997 and 1998.
What happened to Yellow Box for Windows?
Nothing, really...
It was never actually supposed to be a shipping product. The idea was the developers would license the runtime environment from Apple and include it with their Yellow Box apps so they could run on Windows systems. That licensing deal is what was cut off.
Yellow Box (everything that was included on the developer CDs) was released within WebObjects 4. And any applications developed for Yellow Box for Windows ran just fine on Windows with WebObjects 4.x.x installed.
Rhapsody apps for Windows... not quite
One of the biggest misconceptions about Yellow Box for Windows was that this was a write once, use anywhere type of development environment. It wasn't.
Yellow Box applications for Rhapsody would not run within Yellow Box for Windows without some extensive reworking. As such, only the smallest handful of Rhapsody apps were ever ported to Yellow Box for Windows (I display a number of these in screen shots of Yellow Box on Windows NT 4 and Yellow Box on Windows 2000 Professional).
Other Boxes
To help with the transition to Rhapsody, Apple developed Blue Box which seems to be largely based on the technology used for MAE (Macintosh Application Environment for Unix systems) and A/UX.
While early versions had some issues with running a little slow, the later versions that were included with Rhapsody 5.3-5.6 (Mac OS X Server 1.0-1.2) were actually very nice speedwise (I ran a test on my main Rhapsody system using Mathematica, the results are here), and the Blue Box environment is much more stable than the Mac OS running on it's own.
There are rumors all around that Apple was developing Red Box for the Intel version of Rhapsody. I cover that area in an article here.
That brings us to the Where are they now? section.
Yellow Box became Cocoa. And while everyone seems up in arms about Apple not making Carbon 64 bit, I would point out that the best Mac apps actually make use of both Carbon and Cocoa frameworks. Developers have been mixing the two to get the best of both for many years now.
While I pointed out that Yellow Box for Windows basically became WebObjects 4, Apple made some major changes with WebObjects 5... mainly the removal of Objective C support (making it Java only).
While many are under the misconception that the Rhapsody project was a failure, that couldn't be further from the truth... unless Mac OS X is a failure. Mac OS X is an evolution of Rhapsody.
The first thing Apple did was put in Carbon. While many mistakenly think this was some how based on code used for QuickTime... it wasn't. QuickTime had been on Rhapsody from the very beginning, without Carbon. The foundations of Carbon are based in Copland. Apple's developers were already hard at work developing a streamlined version of the Macintosh Toolbox that could be implemented on a kernel based operating system when the Copland project was dropped. When looking for a similar solution for Rhapsody, that Copland environment was placed within Rhapsody to make a suitable environment for existing Mac apps with small amounts of code changes. Within weeks of getting Carbon into Rhapsody a number of demo apps were compiled and running (including Simple Text, AppleWorks and Photoshop 5).
The second thing was removal of licensed aspects of 4.4BSD from Rhapsody's foundation (which gave us Darwin) followed by the removal of Adobe's Display Postscript. Both of these steps were taken to reduce the cost of the operating system. Considering that Rhapsody 5.6 cost about $500 where as Mac OS X v10.0 cost $129, I'd say that Apple did a good job of getting rid of expensive licenses.
Rhapsody was sold as a product from early 1999 until the summer of 2001, and the very first developer release of Mac OS X (Mac OS X Developer Preview 1) was nearly identical to the shipping version of Rhapsody (Mac OS X Server 1.x) from a users stand point.
So yeah, from my point of view, Rhapsody was very successful.
Hey; I'm Brian (the guy who got things to compile against CoreFoundation and CoreGraphics and is linked in the article).
This isn't Cocoa but could be used to write some Cocoa-like code with MingW/GCC's objective-C compiler and CoreFoundation.
However, tread carefully.
I got a takedown notice from Apple for posting the details and example code on my site (admittedly the example code was Apple's, but the details are not Apple information, Apple just claims they violate the Safari license). I've taken it down (mostly) because I don't have the time or money to fight Apple legally and want to avoid that issue (chilling effect of the American law system at its finest).
-
Brian
This isn't Cocoa but could be used to write some Cocoa-like code with MingW/GCC's objective-C compiler and CoreFoundation.
However, tread carefully.
I got a takedown notice from Apple for posting the details and example code on my site (admittedly the example code was Apple's, but the details are not Apple information, Apple just claims they violate the Safari license). I've taken it down (mostly) because I don't have the time or money to fight Apple legally and want to avoid that issue (chilling effect of the American law system at its finest).
-
Brian
There are two options here. Either you'd jump all over Cocoa or you're nowhere near being a developer. Not a professional one at any rate.
Oh I get it. Hey everyone! Stop what you're doing and check this out! This is a GREAT IDEA! Let's make all our apps with a totally crapped out interface and full of security holes - and then we can sell millions on Windows!
Get out of the Mac bubble!
Perhaps the 1 million downloads could be accounted for by 500,000 people having to download it twice in the 48 hour period.
Once to get the first version, then a second time a day later, to get hold of the fixes for the security holes that were found within two hours of its launch.
No.
Of course not.
Cocoa is a lot more than CoreFoundation and CoreGraphics!
I was just pointing out that experienced Cocoa developers could create a terribly vauge but still better approximation of the Cocoa development experience by using these libraries and the mingw Objective-C compiler (some people seem to get the idea that Objective-C is some super-special Apple thing). That's all.
However, I can compile many of the CoreGraphics and CoreFoundation samples (the non-Cocoa, non-UI ones) on Windows, which is fairly exciting since a lot of CoreFoundation and CoreGraphics is very nice (I personally like using CoreGraphics for PDFs). This approach will never be fesable in a real/production app though, due to its questionable legality and Apple's usual "send the lawyers" reaction, which is the other point I was trying to make with my post.
This isn't even close to being Cocoa for Windows. Sorry for any confusion.
Of course not.
Cocoa is a lot more than CoreFoundation and CoreGraphics!
I was just pointing out that experienced Cocoa developers could create a terribly vauge but still better approximation of the Cocoa development experience by using these libraries and the mingw Objective-C compiler (some people seem to get the idea that Objective-C is some super-special Apple thing). That's all.
However, I can compile many of the CoreGraphics and CoreFoundation samples (the non-Cocoa, non-UI ones) on Windows, which is fairly exciting since a lot of CoreFoundation and CoreGraphics is very nice (I personally like using CoreGraphics for PDFs). This approach will never be fesable in a real/production app though, due to its questionable legality and Apple's usual "send the lawyers" reaction, which is the other point I was trying to make with my post.
This isn't even close to being Cocoa for Windows. Sorry for any confusion.
Apple may have made certain promises but that was probably when Amelio was still in charge. Jobs had no ambitions to follow through on earlier Apple promises.
For one... while the technology was great then, the *release versions* were never updated and released to the masses. Key word... to the masses. I'm sure the technology continued on within Apple's hallowed halls. There was no further releases of NeXT's compilation tools for Intel after the Apple release so that they could work on Windows. This literally took a number of applications that had existed on the Windows side using the NeXT API's, and stopped PC development. Omniweb, as a browser... once ran on top of Openstep Enterprise on Windows NT 4!
http://www.stepwise.com/
Still a remnant of the old NeXT NeXTSTEP/Openstep days.
The tools were heralded by all, much as WebObjects was (only reason it's led a path to obscurity is that Apple's presence in Enterprise was and remains nowhere near the focus of what NeXT was trying to achieve... Amelio fell in love with the technology, and it was great... but Apple's legacy market had very little to do with WebObjects' primary focus; Creative types aren't genuinely geeky about web apps. in masses). Many of Sun's own development staff were absolutely in love with the technology and there was actually an Openstep Enterprise release for SunOS/Solaris as well as Windows NT.
I think in many ways it was this technology that led to the development of Java. Where Java was the philosophy of writing once and running everywhere, Openstep Enterprise was literally write once, compile (on each platform) and run everywhere as a native appearing application on any platform the NeXT API's were piggybacked onto. The old NeXT Applications on Windows looked and felt like a normal Windows application. In contrast... Apple is not focusing on making applications "Windows-like" and in contrast, is trying to differentiate itself from the whole of Microsoft's UI to try to look more appealing and favorable to the Mac. This isn't an Apple->Windows transition strategy... but a further attempt, by Apple, to transition Windows users to the Mac via as many watershed efforts as possible. Whether trojan horses like AppleTV, iPhone, and the iPod... to Safari and iTunes. Anything Apple can give away for free that can put on a favorable user experience, leads the potentials of bringing PC users to the Mac. It must be working as computer market share #'s are up and Apple's been about the healthiest PC vendor of the lot for the last few years. I say "PC vendor" because I'm not referring to anything but that.
Openstep as a technology base was an absolute marvel, and it's API's are still largely being leveraged today. The one misguided notion about the old API's were that you were locked in to using Objective C. While it was, at the time, a superior technology... it also had a learning curve compared to the more popular programming languages because it was different in syntax and people are genuinely reluctant to change unless there's a short walk to the light of prosperity at the end of the tunnel. So while it might have been superior... superior doesn't always win the war. If it did, Beta would've beat VHS, the Mac would've beat Windows, and the Amiga and Be OS would likely be the strong one's that inherited the Earth.
Apple learned from this. In many ways Jobs knows all of this all too well. Not only did he, while working at Apple, see the mistakes that were made... not only did he watch inferior technology in software and hardware prevail... but he also experienced a rather dismal time in his life when the plans and investment and awesome technologies involved in NeXT failed to bear fruit. The amount of $ invested and the literal fire sale elements that befell NeXT were about the most tragic things to happen to Steve in computerdom other than getting fired at Apple. While NeXT was a love-affair... Apple was and always will be his first love.
That is why Cocoa is largely an evolution of Openstep Enterprise and Openstep as a whole. Yet instead of becoming an evolution of Objective-C, it's become inclusive to include C++ and Java in the transition. Make no mistake, when Apple announced the transition from Rhapsody to Mac OS X... it wasn't an Earth-shattering change between the 2. It was an evolution/rethink of what had failed under the initial plan and a restructuring of how to make it all work. If Apple couldn't bring Adobe and Microsoft to Yellow Box then, it could find the balance to get both to Carbon/Cocoa now.
The evolution literally is kind of a funny deal when you look on it in hindsight. Apple, prior to the NeXT purchase... had a system evolution plan in place to transition from Mac OS 7.x+-8.x into what was known as Copland. Copland would then transition to Gershwin which was more evolutionary than revolutionary in comparison to the Mac OS 8-Copland transition. Both were, in effect, a gutting and rethinking of Classic Mac OS wherein the "portable API's of the Mac would be gutted and moved to a new and thoroughly more modern kernal known then as NuKern.
Funny thing is... that's exactly what Carbon is today.
It's a gutting of the portable API's of Mac OS Classic so that they work on a newer and thoroughly more modern kernal. 'Cept... it's not NuKern.Those that preach about how Safari is not Cocoa and this and that... the reality is, Carbon in a lot of ways is built on some of the guts of Cocoa. It has to be, since a large portion of the way things work in OS X is built on NeXT's shoulders, the wrappers for applications on Mac are using Interfacebuilder within XCode (no more Codewarrior) and slowly and surely the 2 are becoming on big melting pot.
The irony is that while Copland and Gershwin faded into obscurity in theory... the practice literally has taken Mac OS X and succeeded in ways that Openstep failed. While Openstep locked you into developing in Objective-C, the merger of the portable Mac API's from Classic Mac OS with the already portable and robust API's of NeXT has brought us into the OS X age where it's more and more software code agnostic in terms of what language you want to develop in. You can produce apps. written in Objective C, you can produce apps. written in C++, you can produce apps. written in Java, and all of them can take the Interface Builder wrapper (in the case of Java, this is an OS X "system-specific" Java application; running contrary to Sun's focus) that was intrinsic to the old NeXT development environment and run as compiled apps. in OS X.
It's also more than a bit telling in hindsight when looking back that I remember something that Jobs noted during the development of Mac OS X. I can't remember the exact timeframe or date or the exact quote but it was during the developments of Cocoa and Carbon that there was some questions posed to Steve about the performance of the PowerPC and he posted a barb in his response that still sticks in my mind to this day. He basically noted that once Cocoa and Carbon could come to full fruition, it was equally possible for both to be transitioned to any other platform they wanted to. In essence, they could become platform independent and choose whatever processor family provided the best performance and return on investment. He said something to the effect that it'd be at least 4 years before they could commit to that transition strategy.
Irony that even during those days... and I'm sure it was before they'd even jumped back in bed with IBM after Motorola/Freescale's woes... that he'd already had a potential transition strategy to Intel from PowerPC in his mind, and that Carbon (as noted earlier)... eventually would culminate into a bridged development strategy for OS X, and not be merely a transition platform to ween people to full-on Cocoa. While many developers from the NeXT days preached of how Apple should work more and more to deprecate large chunks of Carbon to push people to Cocoa and therefore Objective-C, the reality is... that was never the ideal. The ideal was to provide developers with every and all options they could. That's why Carbon is still a big part of the Mac today and into the future, why Cocoa remains a big part, and why Java is and will remain part of the OS as well. The three technologies are synergistic and the lines will continue to blur as all three are bolstered and reworked continually to become more robust and parity-rich.
It should be interesting to see, however... if Apple would ever allow an Interface Builder wrapper to build around C# code.
Oh and as far as "Red Box" as some suggest... that was more a rumor than a reality at this stage. If it existed, I somehow doubt that Apple would give us Boot Camp instead (after all, OS/2 Warp had an equivalent to this very technology rolled in to allow Windows applications to run). In contrast... Star Trek and Star Trek NG have founding in reality. Star Trek was Mac OS Classic for x86 (confirmed) which was put together and scrapped in favor of PowerPC (Sculley and Spindler era). Star Trek Next Generation well... happened when Mac OS X was released for Intel under Jobs.
It Lives!!!
This is from inside Apple's HQ beta testing as of '08
I got fired a few days ago, and decided to shed some light on the mystery surrounding OS X's "Yellow Box", it's still buggy as all get out, that's why it hasn't been released Yet. On Windows, there are problems so bad that to even re-announce the project would be a catastrophic outtake for Apple. Besides, they don't care about software anymore, it's all iPhone, iPod now. Oh and P.S. as for "Red Box" (post above me) look no further than Parallel's Coherence. If you can't stand the Windows boot time, adjust the settings to make it suspend on close.
So without any harm of lawsuits, Here it is:
![Xcode.jpg]()
This is from inside Apple's HQ beta testing as of '08
I got fired a few days ago, and decided to shed some light on the mystery surrounding OS X's "Yellow Box", it's still buggy as all get out, that's why it hasn't been released Yet. On Windows, there are problems so bad that to even re-announce the project would be a catastrophic outtake for Apple. Besides, they don't care about software anymore, it's all iPhone, iPod now. Oh and P.S. as for "Red Box" (post above me) look no further than Parallel's Coherence. If you can't stand the Windows boot time, adjust the settings to make it suspend on close.
So without any harm of lawsuits, Here it is:
