Wine, Crossover Office, and CedegaWater or Wine?Bernd Villiger, Oliver Frommel and Jörg Luther |
![]() |
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. |
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").
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).
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.
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.
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 ...
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.
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/ |