Some people suggested rewriting Windows for Linux and X11, and then laughed at their own joke.
History
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.
Maybe it's Not a Joke, After All
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.
What Wine Does
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.
Better Than Better...
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.
How Wine Does It
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.
Running Wine
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.
In the Future
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.
In the Present
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.
Bob Amstadt graduated from Rose-Hulman Institute of Technology in 1986
with a BS in both Electrical Engineering and Computer Science. For the
past five years he has worked as an independent engineering consultant
specializing in embedded control and communications systems. His first
exposure to Linux was in December 1992 when he installed it on his e-mail
server. He began work on Wine as a result of discussions on comp.os.linux
in May and June of 1993.