With the fundamental architecture of Wine stabilizing, and
people starting to think that we might soon be ready to
actually release this thing, it may be time to take a look at
how Wine actually works and operates.
Wine is often used as a recursive acronym, standing for
"Wine Is Not an Emulator". Sometimes it is also known to be
used for "Windows Emulator". In a way, both meanings are
correct, only seen from different perspectives. The first
meaning says that Wine is not a virtual machine, it does not
emulate a CPU, and you are not supposed to install
Windows nor any Windows device drivers on top of it; rather,
Wine is an implementation of the Windows API, and can be
used as a library to port Windows applications to Unix. The
second meaning, obviously, is that to Windows binaries
(.exe files), Wine does look like
Windows, and emulates its behaviour and quirks rather
closely.
"Emulator": The "Emulator" perspective should not be thought of as if
Wine is a typical inefficient emulation layer that means
Wine can't be anything but slow - the faithfulness to the
badly designed Windows API may of course impose a minor
overhead in some cases, but this is both balanced out by
the higher efficiency of the Unix platforms Wine runs on,
and that other possible abstraction libraries (like Motif,
GTK+, CORBA, etc) has a runtime overhead typically
comparable to Wine's.
Wine's main task is to run Windows executables under non
Windows operating systems. It supports different types of
executables:
DOS executable. Those are even older programs, using
the DOS format (either .com or
.exe (the later being also called
MZ)).
Windows NE executable, also called 16 bit. They were
the native processes run by Windows 2.x and 3.x. NE
stands for New Executable <g>.
Windows PE executable. These are programs were
introduced in Windows 95 (and became the native
formats for all later Windows version), even if 16 bit
applications were still supported. PE stands for
Portable Executable, in a sense where the format of
the executable (as a file) is independent of the CPU
(even if the content of the file - the code - is CPU
dependent).
Winelib executable. These are applications, written
using the Windows API, but compiled as a Unix
executable. Wine provides the tools to create such
executables.
Let's quickly review the main differences for the supported
executables:
Table 7-1. Wine executables
DOS (.COM or .EXE)
Win16 (NE)
Win32 (PE)
Winelib
Multitasking
Only one application at a time (except for TSR)
Cooperative
Preemptive
Preemptive
Address space
One MB of memory, where each application is loaded
and unloaded.
All 16 bit applications share a single address
space, protected mode.
Each application has it's own address
space. Requires MMU support from CPU.
Each application has it's own address
space. Requires MMU support from CPU.
Windows API
No Windows API but the DOS API (like Int
21h traps).
Will call the 16 bit Windows API.
Will call the 32 bit Windows API.
Will call the 32 bit Windows API, and possibly
also the Unix APIs.
Code (CPU level)
Only available on x86 in real mode. Code and data
are in segmented forms, with 16 bit
offsets. Processor is in real mode.
Only available on IA-32 architectures, code and
data are in segmented forms, with 16 bit offsets
(hence the 16 bit name). Processor is in protected
mode.
Available (with NT) on several CPUs, including
IA-32. On this CPU, uses a flat memory model with
32 bit offsets (hence the 32 bit name).
Flat model, with 32 bit addresses.
Multi-threading
Not available.
Not available.
Available.
Available, but must use the Win32 APIs for
threading and synchronization, not the Unix ones.
Wine deals with this issue by launching a separate Wine process (which
is in fact a Unix process) for each Win32 process, but not for Win16
tasks. Win16 tasks are run as different intersynchronized Unix-threads
in the same dedicated Wine process; this Wine process is commonly
known as a WOW process (Windows on Windows),
referring to a similar mechanism used by Windows NT.
Synchronization between the Win16 tasks running in the WOW
process is normally done through the Win16 mutex - whenever
one of them is running, it holds the Win16 mutex, keeping
the others from running. When the task wishes to let the
other tasks run, the thread releases the Win16 mutex, and
one of the waiting threads will then acquire it and let its
task run.
winevdm is the Wine process dedicated to running the
Win16 processes. Note that several instances of this process could
exist, has Windows has support for different VDM (Virtual Dos
Machines) in order to have Win16 processes running in different
address spaces. Wine also uses the same architecture to run DOS
programs (in this case, the DOS emulation is provided by a Wine only
DLL called winedos.
English
Español
