The past few months have spurred lots of discussion and opinions about Mac on Intel. One thing that’s been neglected in most commentary I’ve seen is mention of Apple’s old “Box” model.

Back in the late 90s, Mac OS X wasn’t called “Mac OS X”, it was called “Rhapsody”. The developer previews ran on both PPC Macs and normal Intel PCs. Apple spoke of different application environments that would be enabled in Rhapsody:

• The Yellow Box was the OpenStep application framework collection, which is now called Cocoa;


• The Blue Box was the legacy Mac OS 9 compatibility environment, now called Classic;


• The Red Box was the rumored (never confirmed by Apple) Windows compatibility environment that would allow Rhapsody for Intel to run Windows applications in a native environment, similar to VirtualPC, but running full-bore at native speed since no CPU emulation would be necessary.

Well, Rhapsody begat Mac OS X, and Mac OS X wasn’t going to be available for Intel. Apple stopped talking about their “boxes”, VirtualPC worked pretty well, and the world moved on. Now, the Mac is veering back toward Intel, and before we know it we’ll be running with Intel, and Microsoft will surely sell native-speed VirtualPC for running Windows…

But, what if there’s another way? What if we could run Windows apps on Mac OS X/Intel that were freed from the VirtualPC OS-in-a-window appearance? What if we could run Windows apps with something that strives toward a Mac OS X look? What I’m thinking about are the WINE project and its offshoot, Darwine.

For those who don’t know, WINE (which stands for “WINE Is Not an Emulator) is an independent implementation of a subset the win32 APIs, which most existing Windows applications are built on top of. The main purpose of WINE is to be able to run Windows software on Linux (the Darwine offshoot targets running Windows software on Mac OS X). Both projects sport ”http://www.winehq.com/site?ss=1">screenshots showing a variety of applications running. WINE’s subset of the win32 APIs seems to be quite a large subset indeed.

WINE’s main advantages over VirtualPC are twofold: First, it doesn’t require Windows in order to run (VirtualPC actually has a Windows installation) since it’s a reimplementation of some APIs rather than a full OS. Second, Windows created by WINE can be mixed on the screen with standard Mac windows, instead of being trapped inside another window.

Before WINE is fully ready to provide a proper Mac experience however, there are (at least) three main hurdles to overcome:

1. Incomplete APIs. WINE can run lots and lots of applications, but to be on a par with VirtualPC, it really needs to run nearly everything.


2. X-Windows. The current implementation of Darwine using X-Windows for drawing. This is an obvious stepping-stone for the developers, but in the long term it needs to use standard Quartz windows.


3. Windows look’n’feel. Windows applications running in WINE look like, well, Windows applications. Ideally we’d want them to look more like Mac applications. I’m not sure if there’s any simple workaround for this; My (perhaps mistaken) understanding is that win32 is usually used in a fairly low-level way, and that Windows apps (or the libraries they’re built with) actually draw most of their components themselves, including “standard” buttons, etc, so it would be difficult to give them Aqua-styled buttons, scrollbars, bevels, etc. But it seems like some things could be done to make the experience more Mac-like, perhaps by forcing menu bars to draw at the top of the screen or something.

Now, I’m sure that the WINE and Darwine teams have limited resources like most open-source projects do. But, hey, Apple has some cash in the bank, and a great team of engineers. What if they set a team to work on taking the existing WINE codebase, completing more APIs and adding some polish, to provide a smooth Windows-on-Mac experience for Mac OS X 10.5 on Intel? And then submitting most of their enhancements back to the original project? They’ve pulled similar stealth stunts before, both with building Safari from KDE code, and building the core Darwin OS with parts of various BSD UNIXes. If anyone can do it, Apple can.

What we’d end up with is a more flexible Mac OS X that would, in addition to the current APIs from Cocoa, Carbon, POSIX, and Java, support Win32 as well. This would even further ease things for potential switchers, since even though we assume that there are equal or better Mac apps for most uses, it would be even easier for people to switch if they knew they could bring their favorite text editor or graphics package with them.

I have absolutely no inside knowledge of what’s going on inside Apple, and no idea if this concept has even been considered, let along worked on, but it seems to me like lots of people would appreciate this.