Image Image Image ImageImage
Image
Welcome!
Image
Creative Services for
Image
Roughly Drafted
Image
Daniel Eran
Image
Image
Image
Image
Image Image

Unraveling the Red Box Myth
According to proponents of the Red Box Myth, Mac OS X will supposedly soon run Windows software natively, perhaps as soon as Leopard 10.5. They're wrong; here's why.

Page 1 | 2 | 3 | 4
Image
Red vs. Blue
So now take a step back from Classic and the Blue Box and just imagine what would be required to build a Windows "Red Box."

For starters, while the Mac API was small enough to be described in a few volumes, the Windows API is not. In fact, there is not one Windows API, but several: the original, archaic Win16 from the 80's, the Win32 introduced by Windows NT in the 90's (along with enhanced and limited versions), and the evolving .Net framework, which was originally intended to become WinFX, the Longhorn API that would entirely replace Win32.

Within these gross abstractions of definition are scores of different programming models, reams of bug ridden code which has never seen the light of day in third party review, and plenty of dead-end routines which were intended to provide some feature set that was later abandoned or superseded, but not removed from the expansive Windows codebase because of backward compatibility concerns. Conversely, there are even more workarounds in Windows designed by Microsoft to accommodate the errors in bad third party software.

Casually referring to the "Windows API" as if it were some simple monolithic standard that can be easily ported to another platform is the hallmark of a clueless tech writer. Win32 is nothing like cross platform API models such as POSIX, Java, or OpenStep. It was designed solely to enrich Microsoft, not to adapt or exist in a form that could benefit anyone else.



Recall that in the early 90's, Microsoft and its partners struggled to deliver cross platform versions of Windows NT for PowerPC, MIPS and ALPHA hardware. They ultimately abandoned the strategy.

Microsoft was not duplicating and porting the Windows APIs to other platforms, as a Red Box would require, but only compiling the Windows NT source code for different hardware, similar to what NeXT Computer was doing with their NeXTStep hardware.

How could the much smaller group of NeXT developers build and maintain a cross platform operating system, while Microsoft couldn't? Microsoft's historical contempt for interoperability on any and every level was a part of the problem, but a huge reason why Microsoft failed then, and why it is so late in releasing Longhorn/Windows Vista today, is that the company has to struggle with such a huge and expansive set of legacy Windows APIs, much of which is sheer crap.

Of course, Microsoft knows this, and that's why the company wants to replace Win32 with WinFX, a modern and secure set of managed APIs.

However, any changes to the API, even bug fixes or security patches, are nearly certain to break existing software. Windows doesn't just run retail packages; much of the really critical business software that holds people to Windows is custom written, specialized in-house software, which is more likely to break (and more difficult to fix) if Microsoft fumbles its backward compatibility regression testing. That takes time, and that causes delays. Imagine trying to do anything like that without having the resources Microsoft has.

Herding Cats
Further, recall that before the delays of Longhorn/Vista engineering (2001-2006), Microsoft first struggled and failed to migrate DOS users to NT 3.x (1993-1995), then struggled and failed to migrate DOS/Windows 95/98 users to NT 4.0 (1996-1999), then struggled and failed to migrate DOS/Windows 95/98/Me users to NT 5 / Windows 2000 (2000-2001).

It wasn't until Windows XP, almost a decade after NT first appeared, that Microsoft could finally get the majority of its DOS users running on an NT-based operating system. Clearly, the "Windows API" is not some simple thing that can be slapped onto an operating system and run without much effort or thought involved.

Also think of all the specialized application frameworks that Microsoft has tied into the Windows API: the web and xml APIs of Internet Explorer that were embedded into Win32 in order to keep the Justice Department confused; the extensive and complex MAPI code that underlies Exchange messaging, email, calendaring, and telephony services; several generations of media APIs, from DirectX to the other various gaming, controller, sound and video APIs; the historical lineup of DDE, OLE, and COM functionality; the secret frameworks that only Microsoft had access to when developing Office; and so on... the list is so long that any suggestion that anyone could just pull a Windows compatibility layer out of their butt and somehow have a way to run Windows applications flawlessly on another OS, is plainly absurd.


The WINE project has been trying to do this for Linux for over twelve years and still has quite a ways to go. Apple can't just slap WINE into Mac OS X either; for Apple, having the WINE code is like "having" the Classic Mac API. There's still at least a half decade of integration work to get from WINE to a minimally functional Red Box compatibility environment in Mac OS X.

Earlier, I mentioned WINE or virtualization as a more ideal solution to running Windows applications on Mac hardware, compared to dual booting. Since then, Apple's Boot Camp arrived as a supported way to boot into Windows XP, and Parallels Workstation arrived as a virtualization tool for running Windows inside Mac OS X. Each serves different purposes in different ways.

I think it's clear that Apple will only offer support for dual boot, leaving third parties to improve upon running Windows within Mac OS X, or emulating the Windows APIs necessary to run some Windows apps.

For its part, Microsoft is already busy trying to derail the efforts of WINE and similar projects, efforts that would also complicate and thwart any theoretical Red Box in Mac OS X. At the same time, Microsoft is pushing full speed ahead on delivering its new generation of APIs and development frameworks.
Apple's striving to deliver Win32 compatibility for Mac OS X while Microsoft focuses on WinFX would be a lot like IBM's ill fated decision to focus on building Win16 compatibility in OS/2, while Microsoft worked on Win32.


Continued: More Nails in the Coffin




Image

More Journal Entries | More Tech Articles | Get Tech Support | My Resume | Links | Contact RoughlyDrafted

 Articles Copyright © 2006 Daniel Eran. All rights reserved.
Suggestions and comments welcome. Contact RoughlyDrafted.
Read more about:
Click one of the links above to display related articles on this page.