Daniel Eran Dilger
Random header image... Refresh for more!

Safari’s Controversial Potential as a New Yellow Box for Windows

Daniel Eran Dilger

Friday’s article, “Cuckoo for Cocoa: Is Safari on Windows the next iTunes?” generated a response from a couple readers and other blogs concerned that I had presented cross platform development issues in a misleading and inaccurate way. Here’s some clarification on the subject.
[Cuckoo for Cocoa: Is Safari on Windows the next iTunes?]
 
The Beast with Two Backs.
The article itself was two stories ideas that intermingled to the point where i couldn’t figure out how to untangle them, so I published them as one, both vying to capture the article’s shared headline.
 
The first idea looked at how Safari is similar to iTunes; how both promote open standards to create a level playing field, and how Safari might be of interest to Mac-curious Windows users as well as those interested in specific unique features Apple offers, following the pattern set by iTunes and QuickTime.
 
None of that was controversial. What did raise questions is the secondary idea of the article, which presented how Apple chose to deliver Safari for Windows, why it did, and what it could mean in Apple’s unfolding strategies.
 
Was my characterization of Cocoa and Yellow Box misleading? A brief recap of the origins of Cocoa and Mac OS X will hopefully clear up any confusion.
 
The Evolution of NeXT Before Apple.

Before being bought up by Apple, NeXT’s operating system strategy had made evolutionary progress in a number of directions. NeXTSTEP originated as a complete operating system based on a monolithic kernel that paired portions of Mach with the standard Unix kernel of BSD.
 
On top of this core Mach/BSD OS–which could be considered roughly equivalent to Linux in functionality–NeXT had developed other layers of functionality that went beyond the typical operating system to provide a robust set of object oriented frameworks. These not only powered its built-in functions, but also served as a rapid application development engine for third parties.
 
NeXT was heavily influenced by the Macintosh; many of its engineers had come directly from Apple, hoping to develop the next “insanely great” system after John Sculley’s Apple had settled into a more conservative strategy–largely influenced by Jean Luis-Gassée–of maintaining the Mac as a low volume, high profit platform.
 
NeXTSTEP was modularized into a number of “kits” that acted like functionally-specific Mac Toolboxes. However, instead of being Mac-like procedural libraries based in Pascal or C, NeXT implemented these libraries as modern object oriented frameworks using the Objective-C language. These kits included:
 

. The Foundation Kit of core functions.
.
. The App Kit related to application level functions.
. The Sound Kit, Music Kit, DB Kit, etc. for specialized functions.

 
The functionality of these kit frameworks was later peeled away from the underlying Mach/BSD core operating system, resulting in the OpenStep specification, which was ported to run on top of both Sun Solaris and Microsoft’s Windows.
 
[
The Secrets of Pink, Taligent and Copland (and OpenStep)]
[Why OS X is on the iPhone, but not the PC]
[The Microkernel Myth: What is Mach?]
 
Rhapsody Reborn as Mac OS X.
Apple originally hoped to migrate its Mac OS users directly to a PowerPC port of NeXTSTEP/Mach. Doing so would have allowed Apple to continue offering the OpenStep frameworks for Solaris and Windows, which would continue to be compatible with its new, NeXTSTEP-based Power Mac operating system.
 
Apple started calling NeXTSTEP/Mach “Rhapsody” and began referring to OpenStep as the “Yellow Box.” If Apple could have gotten developers to quickly migrate to writing natively for the Yellow Box, it would have had the same advanced, cross platform environment NeXT offered.
 
This plan was sent back to the drawing board for several reasons:
 

. Developers demanded native-level compatibility for their existing Mac apps.
. NeXTSTEP included licensed technologies like Display PostScript that were too expensive to use in a low cost, consumer operating system (NeXTSTEP had sold for $700 a copy).
. NeXTSTEP needed some significant retooling and modernization in 1997, since little development had been invested in it over the previous several years. Faced with the impossible barriers erected by Microsoft to maintain its monopoly, NeXT had given up on its OS around 1994 and instead tried targeting specialized platforms, first with its OpenStep environment on other operating systems, and then the web with WebObjects.

 
By the time Apple delivered the first release of its new hybrid of NeXT and Mac technologies in 2001’s Mac OS X, it had progressed far beyond both the Mac OS or NeXTSTEP in significant ways. It had also dropped all plans to offer a Yellow Box runtime for other platforms.

 
Among the changes involved in that strategy was the augmentation of NeXT’s object oriented kits with procedural C++ libraries, including Core Foundation.
 
This implementation allowed older Mac OS applications to be run natively using a matching C++ higher level library called Carbon. It also appeared to nail the lid on the coffin of Yellow Box.
 
[
Cocoa and the Death of Yellow Box and Rhapsody]
 
Yellow Box is Not Cocoa.
Apple also provided a more modern, object oriented set of high level frameworks called Cocoa, corresponding to the App Kit in NeXTSTEP. Cocoa wrapped up the underlying procedural C++ functions in Core Foundation with object oriented interfaces.
 
While many refer to Yellow Box as being a “Cocoa for Windows,” that’s not really accurate. Yellow Box included a lot of the functionality that ended up as shared C++ code in Mac OS X, which was never part of what Apple ever referred to as Cocoa.
 
Cocoa is not the Yellow Box.
The comments I made about the “portions of Cocoa” being ported to Windows to support Safari were not precisely accurate either, because those were really analogous to portions of Yellow Box that were never part of Cocoa.
 
The precise difference between Yellow Box and Cocoa is not really a critically important detail in the point being made in the article however. The point is that Apple has delivered large portions of what relates to the functionality of Yellow Box for Windows as part of Safari.
 
That means that third parties could conceivably use the same Windows DLLs that ship with Safari as a mechanism to help port their own apps, if Apple decided it would be useful to offer this.
 
Interestingly, Apple has already delivered a subset of Core Foundation in CF Lite, which is an open source library designed expressly to allow developers to adapt their custom applications written for Mac OS X to other platforms, particularly Unix-like environments like Linux.
 
That means the principle I was describing
has already been implemented in a limited way; its only a matter of how much further Apple will go in improving upon this support, and whether the company decides such a strategy is maintainable and makes sense.
 
[
Creating Cross-Platform Applications with Core Foundation and Open Source]
 
Still Cuckoo for Cocoa?
Apple could also choose to deliver a full Cocoa implementation for Windows, which would be easer now that large portions of Core Foundation and Core Graphics are already there. The fact that Apple adapted Cocoa to work on the ARM-based iPhone indicates there has been attention given to make Cocoa portable.
 
Splitting hairs about the definition of Cocoa is an exercise in pedantic semantics. The simple reality is that Apple has demonstrated an interest in basing Safari on Windows upon its own frameworks.
 
Beyond making Safari a more “Mac-like” browser on Windows, this is what opens the opportunity for third party app portability, although there is still work to be done. It would not be easy in many cases to port existing Mac apps, but it could serve as an alternative to .Net to provide Apple with a Windows deployment strategy.
 
As I pointed out earlier this
may not be Apple’s business plan; the idea already failed twice a decade ago at NeXT and then at Apple, although the circumstances have since changed dramatically.
 
The Constant of Change.
Two years ago, Apple announced at WWDC 2005 that it was moving the Mac to Intel. Within six months, we were soaking in Intel Macs and a new Universal Binary architecture that made the move nearly seamless.
 
It is no stretch to suggest that Apple could similarly open Xcode development for cross platform deployment in the near future, specifically targeting Windows with a runtime based on the work already delivered for Safari.
 
Stating this as a carefully framed possibility is not inaccurate or misleading. The original article did describe the ported Safari on Windows as having a “Cocoa UI,” which is more accurately described as a “Mac-like Aqua Unified UI,” but most readers would relate a Cocoa UI to Aqua. Cocoa doesn’t really have a particular UI.  
 
Safari on Windows does not appear to use the object oriented Cocoa frameworks at all. However, it does deliver the closest thing to the Yellow Box in ten years. That’s more important and significant than niggling over the words that serve as marketing abstractions at Apple.