Open Source

Wine on Linux can run Windows apps--but not the ones you'd want

Some organizations are experimenting with Linux desktops, but many still need to run some Windows apps that don't have a Linux equivalent. One option is to run these apps on Wine. Here's a look at how Wine works and its usefulness in a business setting.


Five words sum it up: "Wine is not an emulator." This is also a clever acronym for the program Wine, which can help you run your Windows programs under Linux. Wine is an implementation of the Windows API that allows programs using the API to run on an operating system that doesn't natively support the application. It's important to note that Wine doesn't emulate a full x86 system but rather provides the software APIs that make it possible to run Windows programs. This allows a program to run at full speed, since no emulation is taking place. Emulation generally slows down software.

Let's install Wine on a Linux system, attempt to install an ordinary Windows application, and take a look at how well it works.

Downloading and installing
I'm using Red Hat Linux 9 for this article, so I'll download and install the latest RPM distribution of Wine from the Wine Web site. I need a version of Wine that supports glibc 2.3, and at the time of this writing, the version available on the Wine site supports only glibc 2.2. However, the Wine site offers a link to Source Forge, which hosts the version I need.

To install the RPM version of Wine that I downloaded for my Athlon-based system running Red Hat 9, I use the following command:
rpm -i wine-20030911-1rh9winehq.athlon.rpm

If you have a different version of Red Hat or a different processor, be sure to download the appropriate file and modify this command accordingly. On my system, which is pretty standard, the installation went smoothly.

What did it do?
Upon initial installation via RPM, Wine is configured and ready to start running Windows programs. In fact, Wine installs a couple of common Windows apps, such as Notepad and the (all-important) game Minesweeper.

Wine requires a "C: �drive" onto which Windows applications are installed. This is handled by the creation of a folder in /usr/share named wine-c. If you decided to compile Wine rather than use the RPMs, this location may be different. Figure A shows the familiar contents of this location on my testing lab's Red Hat 9 system. As you can see, the common Windows directories have been created; Wine uses these directories for program installation.

Figure A


I mentioned that Notepad is installed. To run it, just type notepad at the prompt. Since Notepad is provided with Wine, you can run it directly. However, this isn't true for other applications. Figure B shows Notepad on Linux with the File | Open dialog box open. There is a definite, noticeable lag during which the mouse won't even move when you first open this dialog box.

Figure B


What about other applications?
Although Notepad can certainly serve a purpose, you'll probably want to install something a tad more useful on your Linux system. A vast number of applications—1,604 as of this writing—are listed in the Wine application database. This doesn't mean that the application necessarily works, but that someone has taken the time to attempt it.

Installing programs under Wine can take significant time and effort. Often, it's not a matter of sticking the CD in the system and running the installer. You have to do a lot of tweaking, and you might be lucky to get the application to start at all. That's the price you must pay to run an application on an OS that it wasn't designed to run on. To demonstrate, I'll try to install an evaluation copy of JASC's Paint Shop Pro 8.

Paint Shop Pro 8
First, I download Paint Shop Pro 8 from the JASC Web site. Then, I use this command to begin the installation:
/usr/bin/wine psp801ev.exe

where psp801ev.exe is the downloaded file. I'm greeted with the installation wizard shown in Figure C.

Figure C


The wizard will install Paint Shop Pro 8 to the "C: drive" that Wine uses. Unfortunately, this is about as far as I get before I'm unceremoniously dropped back to a Wine command prompt. At that point, I type quit to exit, and the installer stops. A huge number of errors are reported in the shell screen I used to launch the Wine/PSP8 installation, as well.

Thinking that maybe Paint Shop Pro 8 is too new and includes some feature that Wine doesn't yet support, I try the CD version of Paint Shop Pro 7—but the results are similar. The Wine application support site offers instructions to get PSP7 running. Unfortunately, they're for a specific edition of PSP7. The workarounds to get PSP7 running under Wine basically involve installing it on a Windows machine and then copying the entire installation along with the related registry keys over to the Linux machine. When I try this, the Wine version of Regedit crashes each time I attempt to import the registry keys that PSP7 needs.

Software that does work
The Wine Web site includes a couple of lists of software that works with little or no tweaking. These applications include PuTTY, mIRC, WS-FTP LE, Acrobat Reader 5.05, WinZip, WinAmp, and SnagIt. Although I respect the work that has been done to get Wine where it is, I'm not sure that these Windows applications are all that useful under Linux, since it already has native utilities that will do the same things. It's not like running OpenOffice instead of Microsoft Office, where differences in functionality could confuse users. I much prefer native utilities, and I think most people would want to use Wine to run Windows applications that don't have an equivalent program on Linux.

What I learned
Would I use Wine in a production environment? The answer, unfortunately, is no. Despite my respect for the project effort, in a production environment where users are pounding away at machines and trying to meet deadlines, the house of cards that is built with Wine alone might create serious support issues for the IT department—as well as productivity problems for users. Sure, an application might be able to run after some tweaking and creative thinking, but troubleshooting a software problem would be much more difficult due to all of the added factors involved. In addition, to get certain applications running, you need to find DLLs (on older Windows CDs or on Web sites that house them) and copy them to appropriate locations on the Wine machine.

I would rather run CrossOver Office 2 by CodeWeavers (the primary corporate backer of the open source Wine Project), which nicely supports a number of common and useful Windows programs such as Microsoft Office 2000. (It's also been reported that Paint Shop Pro 8 installs flawlessly under CrossOver Office 2.) I don't see programs such as mIRC and WS-FTP LE—which Wine supports nicely—being all that useful for businesses.

Wine seems to be a good starting point for users who want to make the break from Windows to Linux and who don't mind experimenting. But companies that want to run Linux desktops and still need to access several Windows applications may be better served by running CrossOver Office.

Editor's Picks