How to Run Windows Software (and Games) on Linux with Wine

Posted 08/06/2009 at 8:00am | by Will Kraft

29

Comments

Print

Using Wine

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.

Gaming With Wine

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:

• 64-bit AMD Phenom Triple-Core CPU running at 2.3 GHZ
• 4 GB system RAM
• NVIDIA GeForce 8400 GS with 512 MB of RAM (Driver Version 180)
• Dual-boot Ubuntu 8.10 and Windows Vista
• Wine 1.1.26

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.