Wine

In the first few years of Linux, many people asked whether it would be possible to run MS Windows under Linux. They were tired of rebooting over and over to run applications such as word processors that are available under Windows, but not under Linux.

Since Windows (in some incarnation) runs under SCO, iRTX, QNX, and SVR4 of various flavors, why couldn't it run under Linux as well? The immediate answer was that all the other OS's that run Windows 3.1 have access to some Windows source code, and are working under “non-disclosure agreements” from Microsoft, and that Windows, as it comes out-of-the-box, takes over the entire machine. It is possible to run Windows 3.0 in “real mode”, where it doesn't take over the machine, but very few applications will run in that mode.

Others pointed out that most of the other implementations crash just as often as Windows itself does, and that Linux is a 32-bit operating system, while Windows is a 16-bit system, and that standard Windows binaries are 16-bit binaries.

Some people suggested rewriting Windows for Linux and X11, and then laughed at their own joke.

Attention turned to the DOS emulator that became widely useable about a year and a half after Linux's debut. Many were excited when, with some rather ugly hacks, the DOS emulator was able to run Windows 3.0 in “real mode”, at least for a few developers who knew what they were doing. It became apparent that there are very few useful Windows applications which still run in real mode, that it would be very difficult to get Windows to run in standard mode under Linux, and that if Windows could be made to run under Linux, it would make the system unstable.

A year ago or so (in June 1993), Bob Amstadt started writing the beginnings of Wine. He started by writing the code necessary to load Windows binaries into memory (Windows binaries are not in a format Linux understands, and need to be “fixed up” when they are run) and some code for Linux to allow modifying some of the memory management structures (the LDT) in such a way that Windows binaries could run.

He set up a structure for rewriting the rest of Windows, and a few programmers joined him in writing these functions. A year later, over 35% of the functions have been written, and many small applications run, more or less. These include the standard Windows applets Solitaire and Winmine, as well as a commercial security system application. Each week, more programs are added to the success list.

Wine translates the Windows API (Application Programming Interface, how Windows applications call Windows) into equivalent functionality available through the standard Unix and X interfaces. When a Windows program creates a window, Wine converts that into a call to create a window through the standard Xlib library. When DOS interrupts are called, for example to read a file, Wine translates them into Unix system calls.

Wine also implements other API's that are available for Windows. For instance, the WinSock API is becoming the standard way of accessing TCP/IP networking under Windows, and Wine provides the functionality of WinSock, mapping it to the standard Unix socket calls.

Wine should run applications at approximately the same speed as Windows, because the application code is running on the native CPU-Wine does not emulate a 386 or 486 processor. Because Wine itself is a 32-bit application, it has a chance to be faster than MS Windows in some areas. Windows, by contrast, runs in 16-bit mode and has to do a lot of “segment arithmetic” that is not necessary in 32-bit mode.

Wine loads Windows binaries; it also loads the closely related DLLs (dynamically linked libraries) which most applications require. Wine itself uses a DLL called sysres.dll, in which are stored all the bitmaps for the standard buttons on the title bar.

OS/2 2.x was marketed as “A better Windows than Windows”, and in some ways this was true. OS/2 provides “Crash Protection”, whereby one misbehaving Windows application cannot crash another application. Windows, on the other hand, does not adequately protect applications from each other. With Wine, each program is run as a separate process, which utilizes the protection already provided by the Unix process model, where each process is separate.

Not only will you not crash your computer, you will not crash X either. X is designed to be robust, and to check the data that is passed to it by applications, so that random bad data will not cause the X server to crash.

There are additional benefits beyond “crash protection” to running each Window binary as a separate process. One is that each program has more resources. Instead of all the Windows programs running at the same time having to share GDI heap (a memory resource), each program has access to its own entire heap.

Under Windows, when an application is busy and changes the cursor to the dreaded hourglass, the user has to wait to use all the programs currently running on the computer. With Wine, when one application is busy, the user can let that application be busy while switching to another application and getting some work done.

In Unix, filesystems are “multithreaded”, which means that multiple processes may be reading and writing files simultaneously. DOS does not allow this, so Wine, by using the Unix functionality for reading and writing files, allows much faster and smoother access to files, both on the hard drive and on floppies. The user can back up to any medium and work at the same time, just as you would expect under Unix.

Running MS Windows programs on remote computers that are also running MS Windows is not easy or fun. It requires that special remote-access programs be running on both computers, and none of the many remote access programs is compatible with any of the other programs, because they all use closed, proprietary protocols. Furthermore, they usually require that the remote user be the sole user of the machine.

X, by contrast, is designed to run remotely, and to run on multi-user systems. Because Wine translates Windows calls into X calls, Wine allows the same easy remote access that X does. It is just as simple (although a little slower) for a user in Moscow to run the Windows application on your computer as it is for you, if you are on the Internet, and so is she, and you give her an account on your machine.

As mentioned before, Wine is a single process which translates Windows calls, including undocumented calls that applications need (and a few DOS int21 calls as well) to X and Unix calls, respectively. It is also responsible for properly loading Windows applications. Wine reads the executable file, and correctly loads the code, data, and resources into memory.

Wine is a single process which uses only one non-standard system call, which is required to be able to run 16-bit code instead of 32-bit code. Therefore, it is relatively simple to port Wine to operating systems which conform to POSIX (more or less), have X, and for which the source is free, or which provide an appropriate alternate non-standard system call for setting up the LDT so that 16-bit code can run. Wine was originally developed for Linux, but the port to FreeBSD and NetBSD took less than a week.

The most basic window-handling functions in Wine are written as an interface to the appropriate Xlib functions for manipulating X windows. However, wherever possible, other internal functions in Wine call the basic window-handling functions in Wine instead of Xlib. This has several benefits: it makes Wine more modular, it makes the basic window-handling functions be better tested, and it makes it less necessary for every Wine developer to have X programming expertise.

Wine can be run like any other X program: you can run it from the command line:

% wine sol

or you can put it in a menu, or launch it from a file manager. When launched, programs run and act as if they were running under Windows. By default, applications come up in a special kind of window that looks very much like those provided by Windows instead of looking like other X windows. It looks as if a normal Windows window popped up in the middle of all your X windows, because your window manager doesn't put a standard “frame” on the window. Unfortunately, those windows do not interact well with virtual window managers like fvwm (they don't go away when you switch to another virtual screen), so there is an option to bring up an X window that contains the application window, and this is well-behaved with virtual window managers.

Wine is still in ALPHA testing. It only runs a few applications (other than the test applications that come with it) at this point, although more are being added rapidly to the list. At some point, when Wine supports several major applications, it will be released as BETA software for anyone to play with. However, the BETA release will most likely be missing several features. DDE and OLE are not likely to be supported in the BETA release, and because X has no standard printing mechanism, printing will probably also be unsupported.

Development will not stop with the BETA release. If anything, it will speed up as more programmers become familiar with the project. New BETA releases will be released periodically as Wine progresses.

To continue to develop Wine, we need your help. All the work on the project is currently being done by volunteers with Internet access, so anyone with Internet access may join the project. If you are interested, but are not skilled at Windows programming, start by reading the FAQ, available from tsx-11.mit.edu or aris.com in /pub/linux/ALPHA/Wine/Wine.FAQ.

There are several projects that can be done by newcomers to the project who are not yet skilled in Windows programming, and there are also reading recommendations for learning the Windows programming skills you need to be of more help to the project.

If you have more money than time, please consider a donation to the Wine project. Donations will be used to hire programmers to accelerate the development. If you are interested in making a donation of any size, please contact bob@amscons.com.