How Wine Works

Wine is composed of a MS-Windows program loader and a library of MS-Windows functions.

How Wine Loads Programs

Wine’s first duty is to load an MS-Windows executable image into memory. This also includes any DLL files and other resources that the application needs. MS-Windows uses a different executable image type than DOS which is called NE, or new executable. DLLs and font files also use this NE format, which makes Wine’s job easier.

Individual segments of the NE image must be loaded into memory, and references to other DLL and Windows calls need to be resolved. Calls to functions outside an image are referred to by the module name and function number. A call to Ellipse is actually stored as GDI.24.

After an executable image is loaded into memory, Wine simply jumps to the WinMain() function defined in the image. A call to MS-Windows graphics function Ellipse is stored as GDI.24. GDI is the name of the MS-Windows graphics library, and 24 is the position in that DLL where Ellipse starts. Wine does not need to do any instruction emulation because both Linux and MS-Windows use the i386 instruction set. When an MS-Windows primitive function is called, Wine intercepts that call and passes it to a matching library routine.

The Wine Library

Wine converts the MS-Windows API to the matching X or UNIX API calls. A call to the MS-Windows Ellipse function to draw an ellipse in a window has the following format:

Ellipse (hdc, xLeft, yTop, xRight, yBottom);

The definitions of xLeft, yTop, xRight, and yBottom are a bounding box for an ellipse.

The same ellipse is drawn under the X API XDrawArc function:

XDrawArc(display, d, gc, x, y, width, height, angle1, angle2);

Wine needs to do a little math to convert the coordinates from an Ellipse call to that of an XDrawArc call. Other parameters of the XDrawArc call are a bit easier to map. The d refers to a drawable area, which is typically a handle to a window. Under MS-Windows, this is contained in the hdc structure. The gc is a graphics context and is analogous in functionality to the hdc under MS-Windows. As X is capable of displaying on different machines over a network, the display parameter describes which display to use. The display parameter remains constant over the life of a Wine session. The last thing Wine has to consider is that an MS-Windows Ellipse call can also specify a filled ellipse. Wine checks the hdc and possibly uses XFillArc instead.

There are nearly 300 graphics primitives available under MS-Windows that need to undergo similar translations. While this might seem to be a bit of work, the graphics conversions are among the simpler things to emulate under MS-Windows.

Where Does Wine End and MS-Windows Begin?

Because Wine currently requires parts of MS-Windows to operate, it is a bit confusing to know where Wine ends and MS-Windows begins. Wine currently provides API calls for the following parts of a typical MS-Windows installation:

Wine requires access to some parts of MS-Windows to use features that are not implemented by Wine. One example is the MS-Windows dynamic link library OLECLI, which implements the OLE client. The Wine team has made significant headway in reducing the amount of files needed. The Wine project charter includes removing any dependency on MS-Windows files. This includes utilities and file organizations to install MS-Windows applications.

Some of the simplest MS-Windows applications run today under Wine without need of any MS-Windows code or access to any MS-Windows directories. WINMINE.EXE and SOL.EXE are examples of such applications. Although no suggested directory organization exists to support this, a quick example of doing this is the following:

1.  Copy winmine.exe and win.ini to a Linux directory such as /users/windows.

2.  Change the Windows path options in wine.conf to /users/windows, for example.

3.  Dismount your MS-DOS partition.

4.  Run Wine.

Limitations of Wine

Only a few MS-Windows software packages run correctly under Wine. Luckily, it is possible to estimate how likely a program is to run correctly without actually executing it. Unfortunately, there are some classes of applications that are unlikely to ever run under Wine.

Software That Works

The most recent versions of Wine support a good number of the MS-Windows applets and games included with the stock MS-Windows 3.1. There are considerable variations between each release of Wine. Changes that help some applications often break others. But here are some of the accessories and games that work reasonably well under Wine:

•  calc.exe

•  clock.exe

•  cruel.exe

•  golf.exe

•  notepad.exe

•  pipe.exe

•  pegged.exe

•  reversi.exe

•  winmine.exe