Although the various Linux distributions have a wide variety of software available, you may have a few Windows programs that you may not be willing or able to part with. Although many people dual-boot or use virtual machines to get around this problem, there is yet another potential option that many people new to Linux may not have considered--- Wine. Wine stands out from the other options because it does not require a separate Windows license.
Wine is a program that allows you to run Microsoft Windows programs on Linux. Although it is emulator-like in appearance and by observation, Wine is not an emulator; in fact, the very name of Wine is an acronym for Wine is not an Emulator. A true emulator can emulate CPU architecture in addition to the actual software it is running. For instance, a program that could execute Intel x86-based Windows software on SPARC-based systems running the Solaris operating system would be a true emulator. However, Wine is actually a compatibility layer since both Windows and Wine run natively on x86 and no hardware emulation is required.
Wine works by recreating a miniature Windows installation in your home folder, (the .wine directory) complete with a virtual C:\ (drive_c) and registry. Contained within drive_c is a Program Files folder and a Windows folder complete with a system32 folder that has the most important Windows system files in it. Please note that these files are recreations of the Windows files of the same name rather than being the actual files that are included in a real Windows installation. In other words, the user32.dll file that comes with Wine is not the same file as the user32.dll that can be found in a real 32-bit Windows installation. Instead, each of the dll files in a Wine environment has been painstakingly reverse-engineered to match the functionality of the original as much as possible. Wine can also use actual Windows drivers if need be, but you must supply these yourself. Furthermore, Wine has its own implementation of the Windows registry with a knock-off of Regedit to configure it.
A compatibility layer like Wine is capable of translating Windows system calls to Linux system calls. Although it works as a translation layer, Wine runs in userland like any other program on Linux and has nothing to do with the Linux kernel. Everything a Windows binary does when you run it is funneled through Wine before being passed through to the rest of the Linux system. If the libraries needed by a Windows program are installed, this functionality allows the Windows software to run on Linux to some extent. This ultimately allows Wine to re-create the Windows API in a state that is somewhat similar to Windows XP. Some programs work better than others, but Wine is constantly improving and the list of fully compatible programs is always getting bigger. While Wine may run some programs adequately enough for production use, this will not be the case for every program you may need to use.
Although Wine strives to work as well as possible, it is not always a perfect solution for every problem. Wine's functionality is still determined on a per-program basis, and this may fluctuate drastically when you factor in certain variables that are determined based on your system configuration. WineHQ (the Wine developers' website) has a database of programs, with each entry assigned a rating based on how well it works on Wine. The ratings run from Platinum (works perfectly with no configuration required) on the high end to “Garbage” (does not work at all) on the low end. This rating may change from distro to distro, and may even fluctuate between distro versions; for instance, a hypothetical program may have a “Platinum” rating on Ubuntu 9.04, a “Gold” rating on Ubuntu 8.10, “Silver” on Gentoo, and a “Garbage” rating on any version of Mandriva. If the program you want to run has a “Garbage” rating, your only real choice is to dual-boot or use a virtual machine to run it. The good news is that once a program is in a usable state, it will probably stay that way in future versions of Wine unless you do something to break it.
There are several ways to acquire Wine for any Linux distro. While most distros include a Wine binary somewhere in the main software repositories, the binary in question may be quite old and will not offer the best possible performance. With Wine, you should always use the latest version. Therefore, the best option is to acquire a Wine binary directly from WineHQ. For instance, Ubuntu users are able to add the WineHQ repository to their sources.list file. Binaries from WineHQ are updated regularly and are usually the latest stable version. However, not all distros have a separate WineHQ build. If your distro has a separate WineHQ repository, you should definitely use it, since this method allows you to keep your Wine installation up-to-date with the latest stable version without having to download and install packages manually every time there is an update.
For Ubuntu, add “deb http://wine.budgetdedicated.com/apt $version main”. ($version should be the nickname of your Ubuntu version, like hardy, intrepid, jaunty, karmic, etc) to your /etc/apt/sources.list file. (you need to use sudo or root for this) Next, add the GPG key for the repository: “wget -q http://wine.budgetdedicated.com/apt/387EE263.gpg -O- | sudo apt-key add -” Finally, run “sudo apt-get update” and then “sudo apt-get install wine”.
For OpenSUSE, (We assume you are using 11.1) add the following repository through YaST's Repository Management tool: “http://download.opensuse.org/repositories/Emulators:/Wine/openSUSE_11.1/” YaST will verify the repository and then install the key. Open the software installation tool in YaST and search for Wine. Choose the wine-snapshot package (make sure it comes from the WineHQ repository) and then install it.
Fedora users should just run “yum install wine” as root since that distro has no special repository for cutting-edge releases.
Likewise, Mandriva users should install the most recent version of Wine from the Mandriva software management tool.
Alternatively, you can always download the source from WineHQ and compile your own Wine binary-- you have to do it that way if you need to hack in extra functionality that does not come in the stock binaries. However, this is generally a last-resort option and is not beginner-friendly. If you customize Wine too much just to get one program running, it will probably break support for other programs. Furthermore, this method will not auto-update, so you will need to repeat the process every time a new version you want to update to comes out. Fortunately, the Wine build process follows the standard “./configure && make && make install” recipe, although it takes forever to compile.
Wine includes a powerful tool called winecfg that allows you to control how the system behaves. Winecfg appears as a Windows-style tabbed configuration window with options that allow you to to tweak the behaviors for Wine, including:
Traditionally, Wine is invoked through a command-line interface. This is done by opening a terminal, navigating to the directory the executable file you wish to run is in, and then by invoking the executable by running “wine program.exe” (where program.exe is the name of the program you wish to run) As with everything else on Linux, Wine is case-sensitive, so Program.exe is not the same thing as “program.exe”. The terminal will then produce output that shows what Wine is doing while the program is running. This output is often critical for working around problems.
Furthermore, Wine has extensions that allow Windows binaries to be launched by double-clicking on them in Nautilus, just like in Windows. Although this is more convenient, it does not produce any helpful output like the more conventional method does.
Although Wine can mimic native Linux window decorations on Windows applications to make them look like the rest of your native Linux programs, some applications tend to work improperly when you run them in this way. (for instance, they can take over your display, change the screen resolution, and then fail to change it back when you exit) To limit how much a Windows program can affect the rest of the system, you can bind it to a floating virtual desktop in winecfg. When the Wine Desktop setting is enabled, all Wine programs you launch are confined to a Wine desktop window and cannot escape. They are then forced to run at a resolution you define (1024x768 is good, since the default 800x600 is a little too small) and have a plain Windows 9x-style window decoration. Wine is very good at keeping the Wine Desktop separate from everything else and even has countermeasures to keep the pointer from escaping when the desktop window has focus. Although the Wine desktop can be cumbersome for regular applications, it is often essential for games.
Although recent versions of Wine work reasonably well with most general-purpose software, Wine is still very experimental when it comes to gaming. We cannot stress that enough. During our tests, we noticed that there is quite a bit of lag time between when a game first comes out and the time when Wine supports it well. (Wine is usually several years behind the curve) Therefore, Wine is great for occasional gamers who don't mind playing older titles, but those who want to play the newest and most demanding games when they first come out are much better off dual-booting if they want to play them on the PC instead of a console. Does this mean that Wine is bad or useless? Not at all. We're amazed that it works as well as it does, considering that everything that Wine can do has been painstakingly reverse-engineered by volunteers. In Wine's defense, support for DirectX and gaming in general is much better than it used to be. However, this is often not enough to play the latest titles.
We should also mention that there is an alternative to Wine called Cedega that is also designed to play Linux games. Wine and Cedega were originally the same project, but Cedega (then called WineX) split from Wine before Wine adopted the LGPL. This allowed Cedega to remain proprietary, and for a long time it offered better game support than Wine did. (Today, they are roughly equal in terms of DirectX support) However, Cedega still has better support for game copy protection mechanisms than Wine does. Cedega is technically open source in that a rather crippled version of the source code is available through CVS, but it is not free in the same sense that Wine is. In the same vein, another proprietary derivative of Wine called Crossover was specifically designed to run software like Microsoft Office, even though regular Wine can do this too.
Old games that use variants of the Quake 3 engine run flawlessly on Wine with no tweaking or configuration needed, games that came out a few years ago (like Half Life 2/other source engine games and Painkiller) work with some minor tweaking, but new releases (Like Fallout 3 or Crysis) may have significant problems or not work at all.
One of the largest problems that relate to gaming on Wine is that practically all games today enforce a CD-check mechanism that may not work properly. Wine supports SecuROM, but Safedisc and other measures have not been fully implemented. Once the CD-check problem has been dealt with, Wine is capable of running many (but not all) modern games that use DirectX 9.
Fortunately, there is a legitimate workaround to this problem. Valve's Steam distribution system works flawlessly with Wine. (a Gecko-based rendering engine replaces the Steam components that require Internet Explorer on Windows) Since the games on Steam do not come on physical discs and therefore lack CD-check mechanisms, quite a few of them will work to some extent if launched through the Steam interface. (however, this is not universally true, since the standalone version of a game may work whereas the steam version will not) Most video cards will work on Linux, (either through the NIVDIA or the ATI Catalyst drivers) and Wine is able to use them. Keep in mind that an inadequate video card can keep programs that would otherwise work from running properly. Onboard video is not a substitute for a decent graphics card in either Wine or Windows.
To test Steam's capabilities on Wine, we acquired and tested Half Life 2 (and other Source-engine Games) and Fallout 3 from Steam in addition to a standalone boxed version of Painkiller that we had available for testing. Here are the specs for the test machine we used:
To minimize problems, we downloaded all Steam games and components (including the Steam client itself) to the Ubuntu partition so everything would be running on a native ext3 filesystem. We did this because FUSE utilities like ntfs-3g caused problems with Wine-related gaming in our early tests when we tried using the Wine installation that was already on the Vista partition. We later concluded that these problems were caused by issues in the games (Half-Life 2, specifically) rather than due to a deficiency in Wine, since many other applications from the Vista partition usually work well in Wine. We also disabled PulseAudio (for the entire system, not just for Wine) since many games do not work well with it; we had the sound drop off suddenly in many Source-engine based games when PulseAudio was in use. Instead, we recommend using ALSA (best choice) or even the legacy OSS driver.
Painkiller functioned beautifully, and we were able to crank the settings up as high as they would go. Everything worked, including the Bloom and HDR lighting effects. Game performance was very fluid and we did not experience any frame rate lag whatsoever. The only problem we encountered was that the boss maps took much longer to load than the others, but they worked just as well when they did.
Half Life 2 worked very well once we tweaked the game settings to optimize it for Wine. We chose to confine it to a Wine desktop (many games misbehave somewhat if you run them full screen) and we also disabled intro videos and allocated 512MB of extra swap space. Once we fixed the Pulseaudio bug, game performance was silky smooth, even with the settings maxed and 6x anti-aliasing enabled. The only bug we could find is that the flashlight caused flat white areas to appear on NPCs (non-player characters like zombies, combine soldiers, etc.) and various objects (crates, barrels, saw blades, etc.) when it shone on them, but this did not pose any real problem as far as gameplay was concerned.
We tested other source engine games (the various HL2 episodes and Portal) and they all worked. Half Life 2: Episode 1 ran as smooth as glass with Full HDR, even though there was no anti-aliasing support. The only glitch we could find was some strange static effects on the citadel core. (see screenshot) Episode 2 (the most demanding of the series in terms of system requirements) ran with minor frame rate issues and the cursor tended to wander off the screen a little bit. Although HL2:E2's bloom and HDR functions worked, we could not get any anti-aliasing here either. Lastly, we had to launch the game from a desktop shortcut to make it work properly. Portal had jerky gameplay, but the bloom and HDR functionality worked well and the game was playable. (no anti-aliasing)
Our experience with Fallout 3 was the complete opposite and was really frustrating. While it is possible to get Fallout 3 running on Linux at this time, (several people have done it, based on the screenshots at WineHQ and several Youtube videos) the methods to do so are not completely reliable. Furthermore, we can attest that these methods do not work with the Steam version, but might work on the standalone boxed version. At the moment, the most successful way to get Fallout 3 working is to download the Wine source code, patch better DirectX 9c support into it, and then recompile it. (Beware... replacing the standard Wine binary with this patched version can temporarily break other games that do work until the standard version is replaced) Unfortunately, our first attempt based on this method was unsuccessful.
Next, we tried PlayOnWine, which is an add-on for Wine that installs games and other applications via automated scripts, thereby eliminating much of the guesswork. Although this method allowed us to adapt the Steam version of Fallout 3 that we had, went on to patch Wine for us, installed DirectX 9c, and resolved many other dependencies, (like Microsoft's Windows Live Gaming system) Fallout 3 still wouldn't work. We spent two full days tinkering with Wine and Fallout 3, and we were not able to get past the main launcher interface to play the actual game. (Wine would crash every time we tried) Because of this experience, we must re-emphasize that gaming on Wine is still highly experimental and that games will only work if all of the multiple variables related to system configuration are set properly. In short, Wine has come a long way yet should still be regarded as being an alternative (not necessarily a replacement) for dual-booting or virtualization.