The Options
There are three major options, two of which, at this stage, are "not working".
Option 1 is to run Windows in an emulator like VMWare. This is already possible on PowerPC machines, and the speed is okay for "serious" apps on faster PowerPC based machines. It's not terribly desirable as most of us have no great liking of putting entire desktops inside windows, and full screen seems like the worst of all worlds - it's slower than the real thing, but you can't "run" Mac apps (well, you can, but they're not accessable while VMWare/etc are up, so they might as well not be running.)
Option 2 is to run Windows as a seperate operating system. This will be possible eventually on Intel based machines, but isn't today, despite the best efforts of thousands of hackers (in the positive sense: Woz, not Mitnick) across the world. This one has various implications:
- If a user spends a lot of time in Windows, they'll probably migrate there permanently (because that's what the rest of the world uses), whereas if they spend a lot of time in Mac OS X, they'll probably still occasionally boot into Windows to run the app that's only available in Windows because that's what the rest of the world uses.
- OS X is unavailable while Windows is running, it's an either/or, and the switch isn't painless. Unreal Tournament runs better in OS 9 on my PowerBook than it (the Carbon version) does under OS X, but I rarely boot into OS 9. Lose all my browser tabs? Close all my terminal sessions? Just to play a game?
- On the positive note, Windows is running as fast as it can, and is 100% compatable with all software that runs on that hardware. This is the
only practical option that runs games, for instance.
3. An Windows API for Mac OS X
This is already under development, though you'll probably need to use it with X11. It's called
WINE. In concept, it's not far different from Classic. The API implementation maintains windows (just as Classic's windows looked unrelated to Aqua), and the GUI looks similar to Windows. The major issue with this approach is compatability. WINE's developers are continually playing catch up. Some of this is alleviated by the fact WINE can use a real Windows installation for the majority of the APIs if one is available, but you have to be able to install Windows to begin with to make this work.
For some types of app, the programs will run at near full speed compared to option 2. For others, the programs will not run at all, or will crawl. While some progress was done adapting Windows games to the platform by Transgaming, the entire notion you have to adapt the games should tell you how compatable this is as an option. And if you thought OS 9 apps looked a little out of place under Classic, just think how ugly Windows apps will look under OS X, with their menus at the top of each window, for instance. Windows is document centric, not application centric like OS X, and this will also make integrating the two grating for end-users.
Leaving that side, the major consequences of this approach (which
is going to happen) are:
- Smaller shops will see little value in porting their apps to two platforms if their app written for one runs "acceptably" under the other.
- Switchers will find that only some of their existing Windows apps run under their new Macs, and will be disappointed.
- But users will generally have less incentive to run Windows as a seperate operating system on their computers.
All three options will be available in the near future. The first is ready now, with varying degrees of usability (the person who thinks Office only uses 1% of CPU because, er, that's what it uses when idling, will probably find BOCHS on a 266MHz G3 fine for their needs *snort*); the second will almost certainly be available in a form blessed by Microsoft once Vista comes out, and the third is being worked on and, to a certain extent, I'm surprised it's not out already - but it's far from ideal.
The other wildcard with all of this is .NET. As time goes by, more and more Microsoft software will be written for the .NET platform, a supposedly platform independent high-level API inspired by the Java system. While Mono, a free-software implementation of .NET, is available today, it's X11 dependent and any app running under it will appear to be butt-ugly under Mac OS X, just as with those using Wine. However, .NET is high-level enough (like Java), for it to be reasonable to suggest a native OS X version of Mono might actually run .NET apps so they integrate better with the UI. Like Java apps, they'll always have quirks, but, well, I don't know about you, but the majority of Java programs I see running under OS X are acceptable, and there's no reason to think the same will not be true of .NET.
That doesn't affect things today that much. In five years though, it may make a world of difference.
