This issue includes: Headlines, Poll Results, Feature: Wine
Architecture, Keeping Track of Wine and Discussions on
wine-devel.
“Feature: Wine Architecture
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 neither 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.”
“Note: 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.”