Wine, Crossover Office, and Cedega

Water or Wine?

Bernd Villiger, Oliver Frommel and Jörg Luther

If you need to make a Windows application run on Linux, there is no better way than Wine. We investigated the free and commercial Wine variants to see how they bear up under real-life conditions.

In 1993, Sun Microsystems developed a small tool designed to let users run Windows applications in Solaris out of the box - that is, without needing to port the applications first. Just a few months later, the first attempt was made to make the tool run on BSD and Linux, and this step marks the birth of what has now become known as the Wine project. The name Wine, an acronym in typical GNU tradition, stands for "Wine is not an Emulator."

And Wine [1] really isn't an emulator in the traditional sense. The tool neither emulates a different kind of CPU, nor, strictly speaking, an operating system. Instead Wine inserts itself as a translation layer between Linux and the Windows application the user wants to run. It intercepts any Windows API calls made by the application and attempts to convert them to equivalent Unix and X11 calls. From a technical point of view, Wine is a loader, which loads and launches Windows programs, and a suite of libraries that translate or emulate Windows API calls.

Most of Wine's problems reflect its role as a translator between Windows applications and Linux. A translation can only be as good as the translator's knowledge of the language and culture. It is well known that Microsoft does not like to let strangers gain knowledge of the internal workings of its operating systems and applications. But MS is not the only software manufacturer that likes to keep secrets; many other vendors have been reluctant to port their products to Linux.

Adobe's Acrobat Professional is one example of this phenomenon, and this is why we opted for Acrobat Pro as our test software. Our test machine was a HP laptop with a 1.7 GHz Pentium 4 CPU and 256 Mbytes RAM. Suse Linux 9.0 Professional was our choice of operating system.

Box 1: Wine Remover

Whatever you do, do not attempt to run parallel or multiple Wine installations. Before you install a new release, it makes sense to remove the previous version.

First of all, you need to find out which version is installed:

# rpm -qa | grep -i wine
wine-20040505-1

Your system should respond with the version label - which you can point to as the program to be removed. In our example, this would be rpm -e wine-20040505-1. Then remove the directories that Wine creates for each account:

# rm -rf /root/.wine
# rm -rf /home/user/.wine
[...]

This step should clean up the waste deposits, opening the way for a Wine upgrade. You can use the same approach to remove a Wine installation that has gone wrong.

Figure 1: A very strange sight: launching the Windows Acrobat Installer on the Linux desktop with the Wine emulator.

Installing Wine

All major distributions include Wine as a standard component, although the package is not usually installed by default. To find out if Wine is already installed on your system, enter the following command for RPM-based distributions:

rpm -qa | grep -i wine

Box 2: Wine is not an Emulator

In contrast to Wine, a real emulator creates an isolated area in which it simulates a computer. You may even need to install the operating system separately in order to use this "box in the box." Based on the same principle, you can install and use any application written for the virtual machine's operating system. The loss of performance due to the simulation overhead, and the license costs (the virtual machine needs a complete operating system) are the major drawbacks of this approach.

Wine implements a logical alternative: instead of simulating the whole operating system, it restricts itself to faking an environment that lets Windows applications feel at home. And this leads to the name used internally by Wine, "fake windows":

# ls -a /home/user/.wine
dosdevices fake_windows [...]

The data structure within the Wine directory is based on that of the "real thing." However, the facsimile is a lot different, and this is the major design weakness. Applications that access specific Windows elements often run into a (virtual) wall.

If Wine is installed, you should see a message such as wine-20040505-1 (Suse 9.0) or wine-20040813-7 (Suse 9.2). As you can see, the release date is the version number at the same time.

Just in case, you might like to replace any older versions you find with a recent (2005) version. This is quite easy to do and gives you the advantage of a useful default configuration in most cases. However, you will need to deinstall the previous version to avoid issues (see "Box 1: Wine Remover").

Figure 2: Although not officially supported by Wine, Adobe Acrobat proves cooperative.

The installation is just as unspectacular. First, download the current package (which weighs in at about 12MB) from WineHQ [2]. Then become root, and install on Suse 9.0, for example:

#rpm -ivh wine-20050111-U
SuSELinux90.i586.rpm
Preparing... U
######################## [100%]
1:wine... U
######################## [100%]

This actually completes the configuration at one fell swoop, as the current version comes preconfigured. If you want to view or modify the configuration, simply launch the winecfg tool, which allows you to view or change the virtual drive letter assignments for your devices (Figure 4).

Installing Windows Applications

You can now move on to installing your first Windows applications. For our test, we opted for a popular application that is not officially supported by Wine: Adobe Acrobat 5.

The installation source is the program CD and the CD ROM drive in our lab has an alias of "Z:"; so we can launch the install by typing:

wine 'Z:\media\cdrom\Acrobat U
5\Setup.exe'

Make sure you use Windows-style drive and path names. Also use quotes (`) or double quotes (") for the program path. Failure to do so would cause the Linux shell to mangle the command, the gaps, and the text that follows.

Installing Adobe Acrobat (Figure 1) took about 15 minutes in our lab, and this was just a single application. But it was worth the wait; after completing the setup, the following command

wine 'C:\Program Files\AdobeU
\Acrobat.exe'

gave us a working instance of Adobe Acrobat, as you can see from Figure 2.

Admittedly, not all program installations are as smooth as this. Attempting to install any version of NetObjects Fusion (another program which is not officially supported) demonstrates the typical pitfalls. The application cannot be installed without installing Internet Explorer first.

Figure 3: The installation and configuration steps take place in the main Crossover Office window.

Alternative: Crossover Office

If you are really interested in using Wine in a production environment, you should take a look at the Crossover Office package by CodeWeavers [3], a commercial Wine product that costs between US$ 39.95 (standard version) and US$ 69 (multiuser-capable professional version). Crossover Office provides a GUI and more user friendly handling. However, Crossover Office does not remove the general issue that Wine faces (see "Box 2: Wine is not an emulator"). Thus, Crossover Office Standard is basically a box designed to make it easier for you to use Wine.

Figure 4: The winecfg program helps configuring the Wine installation.

First, let's see how Crossover handles an Acrobat installation. This should allow us to test the program's qualities in a real-life scenario. We used the Crossover demo package, which will run for a month after downloading, although you do need to register to access the download.

The unusual but effective install process is based on a shell script:

install-crossover-standardU
-demo-4.1.sh

The installation is unspectacular and the results are self-explanatory (Figure 3). In most cases, you can simply accept the default configuration. When you are finished, you should see the main window, as shown in Figure 6.

We only found one point to criticize: to avoid conflicts at a later stage, you need to install the fonts that Windows typically installs. The Fonts tab in the main window has done the preparatory work for you so that you can remove the issue simply by downloading the required fonts.

Again, our test starts with an attempt to install Adobe Acrobat Professional 5.0. To do so, we simply clicked on Install in the Add/Remove tab. In the window that then appeared, we selected Unsupported Software and then pointed to the installation source.

After installing an application, you can either use the Menus tab in the main Crossover window or the legacy command line approach to launch the Windows application:

~/cxoffice/bin/acrobat

It does not make much sense to specify a Windows version as your environment. Windows programs will tend to run better if you keep the defaults. Windows applications that explicitly need Windows NT 4 or NT 5 (Windows 2000), will not normally run (or at least not run smoothly) under Wine, as our test with Adobe Acrobat 6 went on to prove: the Installer crashed immediately. In contrast to Wine, Crossover Office has a simple approach to rebooting Windows. To do so, type the following command at the command line:

./cxoffice/bin/cxreboot

Figure 7 shows a screenshot of the message that then appears. Of course, the message can easily be misunderstood ...

Playing with Cedega

Figure 5: The Moorhuhn game running on Cedega.

If you want to run Windows games on Linux, you need Cedega by Transgaming [4]. Cedega is a version of the Wine API emulator to which the developers have added DirectX multimedia library functions. Cedega even supports current Windows games with complex graphics such as Half Life 2 or Far Cry.

However, this kind of performance is not for free: Transgaming charges USD/EUR 5 per month with a minimal subscription of three months.

If you are just interested in taking a look at Cedega, you can download and compile most of the software yourself; however, the download lacks a few critical components, which means that many copy-protected games will not load.

Cedega from the CVS

Without a subscription the sources are only available via the CVS version control system, and you will need the cvs program to download them. Assuming you have cvs on your machine, you first need to log on to the server:

cvs -d:pserver:cvs@U cvs.transgaming.U org:/cvsroot login

If you are asked for a password, simply type cvs. If this works, the program will not give you any reply, but it will complain if things go wrong. Then download the files to your machine:

cvs -z3 U -d:pserver:cvs@cvs.transgaming.Uorg:/cvsroot co winex

After a while, you should have the complete source code in your winex directory. The build follows the normal steps, although Fedora Core 3 requires some additional options:

./configure --enable-opengl U --enable-pthreads

The make command launches the compiler and su -c 'make install' puts the program in the right directories on your disk. You can then copy the sample configuration file to the right location:

cp documentation/samples/U
config ~/.wine/config

Before you start, you first need to create a few files and directories. Cedega expects parts of the directory structure to resemble Windows. The sample file assumes you have a directory called ~/.transgaming. Create a directory with this name, or change this to ~/.wine/config; if you do so, use this directory for the following steps. Add the required subdirectories as follows:

mkdir -p ~/.transgaming/c_drive U /windows/system32
mkdir ~/.transgaming/c_drive/Uwindows/fonts

You may need to add an entry for your CD ROM drive to the configuration file. The entry for the first IDE hard disk drive is as follows:

[Drive H]
"Path" = "/media/cdrom"
"Type" = "cdrom"
"Label" = "CD-ROM"
"Filesystem" = "win95"
"Device" = "/dev/hdc"

You can now go on to install a Windows game. We used the winter edition of the Moorhuhn game that is very popular in Europe. With Cedega, you need to launch wine to install the game:

wine moorhuhn_we.exe

Complete the required steps to put the Moorhuhn program on your Cedega "disk," that is, your .transgaming/c_drive directory, which is the equivalent of C: in Windows.

To ensure that the game will find its files, change to the installation directory and launch it from there:

cd .transgaming/c_drive/Program\ U
Files/Phenomedia\ AG/Moorhuhn\ U
Winter-Edition
wine MoorhuhnWinter.exe

The game runs without any hitches and at normal speed (see Figure 5). The other games we tested all installed under Cedega, but they issued error messages and crashed when we tried to launch them because they all suspected Cedega of attempting to undermine the copy protection scheme.

The commercial Cedega version has code that prevents this from happening. If you want to run current, copy-protected games, you thus have no alternative but to opt for the commercial version.

Figure 6: After completing the simple install, you can configure Crossover Office directly.

Conclusion

Wine is a very ambitious attempt to run Windows applications natively on Unix-like systems. As a minimalist application, Wine restricts itself to providing a translation service between the operating system and the application. The simplicity of both the software and the hardware support is one of the major advantages of Wine.

CrossOver Office helps non-technical Linux users access the power of Wine. Before buying it, you should test the Crossover Trial Version to make sure the Windows application you need really runs. If an application refuses to run on Wine or Crossover, your only alternative may be to switch to a virtual machine, such as the commercial VMware or the free Qemu.

Figure 7: Who knows whether the reboot icon means a Crossover bootstrap or something more drastic?

INFO

[1] WineHQ: http://www.winehq.org/

[2] Wine packages: http://www.winehq.org/site/download

[3] Codeweavers: http://www.codeweavers.com/

[4] Transgaming: http://www.transgaming.com/