jan2002.tar

WINE: The Open Source Way to Run Windows Applications

Marcel Gagné

I usually recommend Linux when discussing alternative operating systems, and I've found that many people are open to the concept but they continue to run at least some Windows applications. How can you have the best of both Linux and Microsoft worlds? Dual booting is an option, but having to boot from Linux to Windows and back simply to run a single program seems counterintuitive at best. Luckily, there are other options.

VMWare and Win4Lin are well-known products that allow you to run Microsoft Windows programs on your system, but they also require a full, licensed version of Windows to achieve that end. While either of these alternatives provides an excellent means of running Windows applications on Linux, neither lets you circumvent Windows.

WINE, which stands for "WINE Is Not an Emulator", is different in that it does not require a copy of Microsoft Windows in order to run programs, thus saving the cost of a license. WINE provides a complete rewrite of the Win32 APIs that contains no Microsoft code. Don't think of it as Windows, but rather a productivity layer that lets you run some Windows applications. Furthermore, WINE is open source and freely distributed, so the price can't be beat. Keep in mind that WINE is designed for X86 architectures, which means that you can compile it on your Intel box running Linux, FreeBSD, or even Solaris. However, Solaris SPARC workstations, having different hardware architecture, will not work.

If you would like to try WINE, you can get the latest sources from the WINE headquarters at http://www.winehq.com. Building from source may not be necessary. The site has links to daily builds in many different formats. Should you wish to obtain the source and build for yourself, you'll find that it is pretty straightforward:

gunzip Wine-20010824.tar.gz
tar -xvf Wine-20010824.tar
cd wine-20010824
./configure
make depend
make
make install

However, when you pick up the source in this manner, it tends to trail behind actual WINE development. The more recent your WINE version, the better your productivity application (or favorite game, for that matter) will run, which is another reason why the daily builds may be a better option. If you'd still prefer to build it yourself (maybe giving the source a few tweaks), then CVS is an option:

export CVSROOT=:pserver:cvs@cvs.winehq.com:/home/wine
cvs login
cvs -z 3 checkout wine

This will create a directory called "wine" relative to where you were when you started the checkout. If you have never downloaded anything from a CVS, it is a little different from grabbing a source tarball. A listing will appear in your terminal window as, one-by-one, the files will be downloaded into your directory. When the process is finally complete, you can build WINE using the same technique as in the previous "tarball" example starting with the ./configure step. From your source directory, cd to programs, type make regapi, and cd back to your source directory.

To run WINE, you need a personal ".wine" directory inside of which resides a config file. You can start by copying the default file from the source distribution, which you can find in your WINE source tree under the documentation/samples directory:

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

The config file has quite a few parameters, so I'll focus on some of the more important ones. The single most important thing you need to identify is your C: drive (in old DOS parlance). This is important because this is where WINE will create its C: drive hierarchy, which means identifying a location for the WINDOWS and SYSTEM directories, among others. The following section from the ~/.wine/config file shows one such configuration with a hypothetical C: drive at /data1/dosc. Which path you choose is up to you:

[Drive C]
Path=/data1/dosc
Type=hd
Label=MS-DOS
Filesystem=win95

Despite the fact that this is a Windows-free installation, you will need to create some of the basic Windows structure. You must create empty directories for "windows", "system", and a couple of others. In my case, I would do the following:

cd /data1/dosc
mkdir -p windows/system
mkdir -p windows/Start\ Menu/Programs

These will be represented to WINE as more classic MS-DOS pathnames:

c:\windows
c:\windows\system
c:\windows\Start Menu
c:\windows\Start Menu\Programs

To see how this affects the WINE configuration file, locate the beginning of the [wine] section. There is no need to do editing here, but this section shows the importance of what we have done so far, including that of properly defining the C: drive. Everything builds from that earlier foundation:

[wine]
Windows=c:\windows
System=c:\windows\system
Temp=e:\
Path=c:\windows;c:\windows\system;e:\;e:\test;f:\
Profile=c:\windows\Profiles\Administrator
GraphicsDriver=x11drv

Additional drives, such as your A: or D: drives, are configured in a similar fashion. The Path parameter is the UNIX/Linux path to the device itself. Type can be either hd (for a hard drive or directory), cdrom (for a CD-ROM drive), floppy (for a diskette), and network. For instance, the following paragraph defines a CD-ROM device as drive D:

[Drive D]
Path=/mnt/cdrom
Type=cdrom
Label=CD-Rom
Filesystem=win95

Notice the Filesystem parameter, which defines the structure that is being used. win95 and vfat are equivalent. You can also specify msdos for old eight-character filenames with three-character extensions. dos and fat are synonyms for msdos.

Next, use regapi to install a default registry. (I'm assuming that you aren't running as root here.) Return to the WINE source directory and type:

programs/regapi/regapi setValue < winedefault.reg

Now, forego any further configurations and try something simple. I'm going to copy a certain card game from an existing Windows installation into my "fake" Windows directory. To run a program under WINE, simply type "wine" followed by the program name. The program name can have a number of different formats. Assuming that I am in the Windows directory (a mounted vfat partition), any of the following would work:

cd /data1/dosc/windows ; wine sol.exe
wine /data1/dosc/windows/sol.exe
wine "c:\windows\sol.exe"

Figure 1 shows a snapshot of WINE running this familiar card game.

After running your first program on WINE, look at the $HOME/.wine directory. Notice that WINE has created some registry files, which you can recognize by the .reg extensions. Also notice the cachedmetrics:0.0. When you first started your application with WINE, you might have noticed some messages about creating font metrics. These "metrics" are stored here. This font discussion brings leads to the topic of how WINE applications behave in UNIX and Linux environments.

The [x11dev] section lets us define how the WINE session will appear and interact with the X-Window managers. For example, notice the line that says "Managed = N", which is only a portion of this section:

[x11drv]
; Color depth to use on multi-depth screens
;;ScreenDepth = 16
; Name of X11 display to use
;;Display = :0.0
; Allow the window manager to manage created windows
Managed = N

With the parameter set to "N", WINE creates unmanaged windows that are independent of the current X Window manager, which you can test by running an application and then minimizing it. Notice that the minimize (and maximize) button is the classic Windows button. In writing this article, I was running KDE as my X desktop and when I minimized the application, I got a small icon floating on my desktop. If I switch from one desktop to another, the minimized icon follows me and maintains its position on the desktop. In fact, it sits on top of any windows I have open, which is not what I wanted and probably not what you want either. When Managed is set to Y, applications running under WINE are under the control of your Window manager. Minimized tasks (in the case of my KDE desktop) drop into the taskbar, and they do not follow from one virtual desktop to another.

Another option is to comment out the Managed line and to use the Desktop setting instead:

Desktop = 800x600

My X desktop runs at 1024x768. The above setting creates a virtual desktop upon which my application runs. My card game can be minimized on that desktop while the desktop itself is controlled by my X Window system.

The Dreaded DLLs

Since WINE is designed to run without Windows being present, certain DLLs are built in as part of the distribution. WINE can use these or use the native Windows versions if they are present. This is handled through the [DllDefaults] and [DllOverrides] section of the config file:

[DllDefaults]
EXTRA_LD_LIBRARY_PATH=/usr/lib/wine
DefaultLoadOrder = native, builtin, elfdll, so

You may find that some applications work better when using the native DLLs. The order in which WINE loads and uses these programs can be specified on a DLL-by-DLL basis:

[DllOverrides]
kernel32, gdi32, user32 = builtin
krnl386, gdi, user = builtin
toolhelp = builtin
comdlg32, commdlg = elfdll, builtin, native
version, ver = elfdll, builtin, native
shell32, shell = builtin, native

Attached devices need to be dealt with in the configuration as well. Things such as printers and serial ports must be identified. The serial ports section is self-explanatory:

[serialports]
Com1=/dev/ttyS0
Com2=/dev/ttyS1
Com3=/dev/modem,38400
Com4=/dev/modem

Printing is, of course, an important consideration. Your setup for LPT1 (or 2 or 3) is defined in the [spooler] section. Unless you are writing text directly to a printer port (as in the example for LPT3), you will probably want to specify an existing print queue:

[spooler]
LPT1:=|lpr -Phplj5
LPT2:=|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -
LPT3:=/dev/lp3

The way decorations (such as buttons and title bars) are displayed under WINE is a function of the WineLook parameter, which you will find in the [Tweak.Layout] section of your config file:

[Tweak.Layout]
;; WineLook=xxx (supported styles are 'Win31'(default), 'Win95', 'Win98')
WineLook=Win95

Like the Managed parameter I previously discussed, this is another parameter to play with. There is no right or wrong for this one, but a matter of preference. Figure 2 shows a sampling of the different appearances.

Before Its Time?

I mentioned that only some Windows applications will work well with WINE. You can read about the experiences of users with your application of choice, and sometimes a little tweaking with the configuration or a run-time flag is all that is necessary to get you on your way to WINE nirvana. To discover what games run and how well they run, visit LinuxGames' WINE success stories page at:

http://www.linuxgames.com/wine/

For a browseable list of general-use applications, see CodeWeavers' Application Database at:

http://appdb.codeweavers.com

CodeWeavers has made it their mission to (in their words) "help our customers leverage Windows technology on Linux and other alternate operating systems". They are in the process of creating a friendly, easy-to-install version of WINE and are pushing the project toward the ultimate goal of an official 1.0 release. CodeWeavers' WINE provides a configuration wizard (to edit your config file), an application launcher, and virtually seamless integration into KDE and GNOME. You can download an RPM package (the only format at this time) from:

http://wine.codeweavers.com

The database covers a number of items and rates them according to the level of success users have had -- from running Internet Explorer to Word and Excel. You'll also find many other popular nonMicrosoft applications. For istance, I've found that my copy of Quickbooks accounting works very well under WINE, as does Pegasus (an email client). I have a friend who still considers Lotus Organizer indispensible. WINE handles this one very well.

In the end, WINE may not be the answer to all your Windows needs, especially if they are relatively complex. The WINE Web site warns, "WINE is still under development, and is not suitable for general use." WINE does, however, run a number of applications very well and it is getting better all the time. And because it is free, it may be worth some of your time to discover whether you can use WINE to save the cost of buying Windows licenses or the hassles of dual booting.

Marcel Gagné lives in Mississauga, Ontario. He is the author of Linux System Administration: A User's Guide (ISBN 0-201-71934-7), published by Addison Wesley. In real life, he is president of Salmar Consulting Inc, a systems integration and network-consulting firm. He is also a pilot, writes science fiction and fantasy, and is co-editor of TransVersions, a science fiction, fantasy, and horror anthology. He loves Linux and all flavors of UNIX and will even admit it in public. He can be reached via email at: mggagne@salmar.com. You can discover lots of other things (including great WINE links) from Marcel's Web site at: http://www.salmar.com/marcel/.

�