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.