Brief overview of Wine architecture...
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 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 versions), 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)||Win64 (PE)||Winelib|
|Multitasking||Only one application at a time (except for TSR)||Cooperative||Preemptive||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.||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 64-bit Windows API.||Will call the 32/64-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).||Only available on AMD64 architectures.||Flat model, with 32/64-bit addresses.|
|Multi-threading||Not available.||Not available.||Available.||Available.||Available, but must use the Win32/64 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, as 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 KRNL386.EXE).