There have been several attempts down the years to make Windows unnecessary. The most audacious is doubtless ReactOS, which cuts to the heart of things and wants to be a complete Windows XP-compatible OS. Needless to say, this is no small project and will take a long time to complete; right now, I'd call it somewhere between completely useless and intriguingly experimental. (It runs Skype, at least.) I'm also concerned that if they ever do get it anywhere near useful completion, Microsoft will stomp on it hard.
That's certainly the high road. But how necessary is it to clone the whole damned OS? A Windows app, after all, is just a block of x86 machine code that makes calls into one or more APIs. If you can clone the APIs in an acceptably clean-room manner, you don't need to duplicate the entire architecture, kernel and all.
And that brings us to one of the oldest and oddest ongoing projects in open-source computing: Wine, which dates back to 1993, and provides a compatibility layer consisting of clean-room DLLs implementing the Win32 APIs, plus whatever magic is necessary to make the deeper host OS machinery look like Windows to the app. This is easier than implementing a whole OS, with the further advantage that if done properly, Wine can act as a Windows compatibility layer over several Unix-like OSes, rather than only Linux. Currently, Wine can operate over Linux, Mac OS X, FreeBSD Unix, and x86 Solaris.
After 16 years of dogged work, Wine actually works pretty well. Part of its success is due to a remarkable cooperation between the Wine project and a commercial software house in St. Paul named Codeweavers. Codeweavers sells a $40 deployment/management utility for Wine called Crossover, which basically makes Wine noob-friendly. (Naked Wine is pretty stark.) Codeweavers also tweaks Wine itself to improve app compatibility, and contributes those tweaks back to the Wine project under LGPL. Some financial support is also provided to the otherwise volunteer-based Wine project. Wine's maintainer, Alexandre Julliard, is an employee of Codeweavers, where he works full-time on Wine development.
Codeweavers focuses mostly on big-market apps like Microsoft Office, and doesn't officially support apps beyond a relatively short list of "gold" software. However, I've found that a great many Windows apps install and run just fine under Crossover whether they're on the list or not. InDesign 2.0 is listed on the site as "known not to work" but apart from a minor display glitch, it seems to work as always. (I haven't tested it deeply so far.) Most Microsoft apps work beautifully (especially older ones) and I've been using Office 2000 and Visio 2000 under it without incident since last fall.
Wine implements a sort of runtime environment emulation for Windows called a "bottle." More than one bottle may be created on a single host OS, and each bottle has its own emulated C: drive and Registry. By giving each Windows app its own bottle under Wine, apps are prevented from interfering with one another in the dreaded "DLL Hell" effect. Because it's not a VM, the performance hit for running Wine/Crossover is very small, and most important, you do not need to have a legal copy of Windows running in the VM. On the other hand, a bottle looks enough like Windows to be infectable by Windows malware, though one bottle probably can't infect other bottles on a Linux system, or the underlying system itself. (From what I've heard, the low-level system tricks played by many malware packages keep them from running or at least running completely.) There are known conflicts between WGA and Wine, so don't install WGA if you can avoid it.
Bottom line: If Wine supports all the Windows apps you absolutely must use, you do not need Windows at all. I haven't tested all the Windows packages that I use here (next up is MapPoint 2004) but for Office and Visio 2000 it's been nothing short of magical, and I'm guessing InDesign will come along eventually. In a mature software market, time works in our favor: One by one, existing apps will be installable under Wine, and each time that happens, Windows slips a little bit deeper beneath the waters of irrelevance.
That's certainly the high road. But how necessary is it to clone the whole damned OS? A Windows app, after all, is just a block of x86 machine code that makes calls into one or more APIs. If you can clone the APIs in an acceptably clean-room manner, you don't need to duplicate the entire architecture, kernel and all.
And that brings us to one of the oldest and oddest ongoing projects in open-source computing: Wine, which dates back to 1993, and provides a compatibility layer consisting of clean-room DLLs implementing the Win32 APIs, plus whatever magic is necessary to make the deeper host OS machinery look like Windows to the app. This is easier than implementing a whole OS, with the further advantage that if done properly, Wine can act as a Windows compatibility layer over several Unix-like OSes, rather than only Linux. Currently, Wine can operate over Linux, Mac OS X, FreeBSD Unix, and x86 Solaris.
After 16 years of dogged work, Wine actually works pretty well. Part of its success is due to a remarkable cooperation between the Wine project and a commercial software house in St. Paul named Codeweavers. Codeweavers sells a $40 deployment/management utility for Wine called Crossover, which basically makes Wine noob-friendly. (Naked Wine is pretty stark.) Codeweavers also tweaks Wine itself to improve app compatibility, and contributes those tweaks back to the Wine project under LGPL. Some financial support is also provided to the otherwise volunteer-based Wine project. Wine's maintainer, Alexandre Julliard, is an employee of Codeweavers, where he works full-time on Wine development.
Codeweavers focuses mostly on big-market apps like Microsoft Office, and doesn't officially support apps beyond a relatively short list of "gold" software. However, I've found that a great many Windows apps install and run just fine under Crossover whether they're on the list or not. InDesign 2.0 is listed on the site as "known not to work" but apart from a minor display glitch, it seems to work as always. (I haven't tested it deeply so far.) Most Microsoft apps work beautifully (especially older ones) and I've been using Office 2000 and Visio 2000 under it without incident since last fall.
Wine implements a sort of runtime environment emulation for Windows called a "bottle." More than one bottle may be created on a single host OS, and each bottle has its own emulated C: drive and Registry. By giving each Windows app its own bottle under Wine, apps are prevented from interfering with one another in the dreaded "DLL Hell" effect. Because it's not a VM, the performance hit for running Wine/Crossover is very small, and most important, you do not need to have a legal copy of Windows running in the VM. On the other hand, a bottle looks enough like Windows to be infectable by Windows malware, though one bottle probably can't infect other bottles on a Linux system, or the underlying system itself. (From what I've heard, the low-level system tricks played by many malware packages keep them from running or at least running completely.) There are known conflicts between WGA and Wine, so don't install WGA if you can avoid it.
Bottom line: If Wine supports all the Windows apps you absolutely must use, you do not need Windows at all. I haven't tested all the Windows packages that I use here (next up is MapPoint 2004) but for Office and Visio 2000 it's been nothing short of magical, and I'm guessing InDesign will come along eventually. In a mature software market, time works in our favor: One by one, existing apps will be installable under Wine, and each time that happens, Windows slips a little bit deeper beneath the waters of irrelevance.
No comments:
Post a Comment