| previous | next |
In World Domination 201, Eric and I identified a number of capabilities the new 64-bit OS would have to achieve in order to gain widespread acceptance. The five categories were device drivers, legacy API support, preinstalls, killer apps, and data file formats (especially multimedia).
Which ones remain blocking issues, and which ones have been solved? We'll look at the current status of each one.
Linux has two options, using Wine or running a copy of 32-bit Windows under an emulator such as QEMU.
Wine hasn't fully solved the Windows compatability problem yet, but it continues to make steady progress, averaging two releases per month. Last month, there were 640 messages posted to the wine developers' mailing list, which does not include the user list or bug reporting list.
The stock version of Wine now has good support for Direct3D (see here and here). Last year the developers proposed a 1.0 release sometime in 2007, and talk continues about "the pending 1.0 feature freeze", but it hasn't happened yet. Unbuntu does not plan to preinstall Wine on the Dell Linux machines, but perhaps a 1.0 release will change Mark Shuttleworth's mind. Ubuntu is apparently growing support for using autorun.inf to launch Wine when a cdrom is inserted.
Wine developers are focusing on fixing bugs in apps they use, such as iTunes, Sims 2, and a number of older games and productivity apps.
Wine used to have trouble building on x86-64, but the next 64-bit version of Ubuntu (the 7.04, or October 2007 release) should contain an x86-64 version of Wine.
The other option for Linux is virtualization, booting and running an existing 32-bit copy of Windows inside a program that emulates PC hardware. The obvious downside of this is it requires a complete copy of 32-bit windows, with the appropriate licensing considerations. Most people have such a copy already, often many different copies purchased over the years: another copy comes bundled with each machine you buy, so you wind up paying them again and again for the same old Windows rather than being allowed to move any of your existing copies to a new machine. Of course Microsoft wants to be paid yet again for permission to move a copy of Windows from real hardware into an emualator. This is makes the Wine approach preferable, although another alternative is running ReactOS (a derivative of Wine that boots as a separate operating system) as a virtualized guest OS under Linux.
The best of breed open source program to run virtual guest operating systems under is qemu, which can either run guests somewhat slowly (about 1/5 native speed) entirely in software as a normal user program, or at almost native speed through use of the kqemu kernel module.
Another approach Linux is KVM, which is partially based on qemu. This is another kernel module, this one already merged into the official Linux kernel, which differs from kqemu in that kvm is designed around new virtualization extensions in x86-64 processors. KVM uses code from qemu to emulate hardware (like video and network cards) for the guest OS, but uses the processor's virtualization extensions rather than softare to handle CPU emulation. For processors that don't have such virtualization extensions, kqemu is recommended instead.
Other popular virtualization alternatives for Linux include VMWare and Xen, but they have no real benefits over qemu/kqemu or KVM.
Apple's legacy API support strategy centers around emulation and dual booting. Their virtualization strategy uses the proprietary third party programs parallels and vmware, both of which have evaluation versions but are intended to be separately purchased. Their dual-boot utility is called boot camp.
Apple doesn't have anything like Wine, although Wine has some minimal support for MacOS X and individual users still express interest, but without any obvious direct input from Apple or mention on apple.com. Parallels uses some Wine code, apparently similar to the way KVM uses some qemu code, and Parallels recently sent their changes back to Wine to comply with the LGPL. But the primary target of Wine (and focus of almost all development) is Linux. (Note: the older darwine project was aimed at porting Wine to the PowerPC version of MacOS X, and was essentially abandoned when Apple moved to Intel processors.)
As for Microsoft, once again Vista makes Linux look better than XP did. The list of 32-bit windows programs that won't run under even 32-bit Vista remains long and varied. The incompatabilities introduced by the switch to 64-bits can easily be lost in the noise of the incompatabilities between 32-bit Vista and older Windows releases. But is that a good strategy for encouraging the userbase to migrate to the 64-bit version of your API?
Microsoft's bundling has distracted itself. The move to 64-bits was not the focus of Vista, and Microsoft is overwhelmed by other incompatability problems. Microsoft is struggling to migrate its userbase to Vista, but mostly to the 32-bit version.