  <chapter>
    <title>Kernel modules</title>
    <para>
      This section cover the kernel modules. As already stated, Wine
      implements the NT architecture, hence provides NTDLL for the
      core kernel functions, and KERNEL32, which is the
      implementation of the basis of the Win32 subsystem, on top of
      NTDLL.
    </para>
    <sect1 id="ntdll">
      <title>NTDLL</title>
      <para>
	NTDLL provides most of the services you'd expect from a
	kernel.
      </para>
      <para>
	Process and thread management are part of them (even if
	process management is still mainly done in KERNEL32, unlike
	NT). A Windows process runs as a Unix process, and a Windows
	thread runs as a Unix thread.
      </para>
      <para>
	Wine also provide fibers (which is the Windows name of
	co-routines).
      </para>
      <para>
	Most of the Windows memory handling (Heap, Global and Local
	functions, virtual memory...) are easily mapped upon their
	Unix equivalents. Note the NTDLL doesn't know about 16 bit
	memory, which is only handled in KERNEL32/KRNL386.EXE (and
	also the DOS routines).
      </para>
      
      <sect2>
	<title>File management</title>
	<para>
	  Wine uses some configuration in order to map Windows
	  filenames (either defined with drive letters, or as UNC
	  names) to the unix filenames. Wine also uses some
	  incantation so that most of file related APIs can also
	  take full unix names. This is handy when passing filenames
	  on the command line.
	</para>
	<para>
	  File handles can be waitable objects, as Windows define
	  them.
	</para>
	<para>
	  Asynchronous I/O is implemented on file handles by
	  queueing pseudo APC. They are not real APC in the sense
	  that they have the same priority as the threads in the
	  considered process (while APCs on NT have normally a
	  higher priority). These APCs get called when invoking
	  Wine server (which should lead to correct behavior when the
	  program ends up waiting on some object - waiting always
	  implies calling Wine server).
	</para>
	<para>
	  FIXME: this should be enhanced and updated to latest work
	  on FS.
	</para>
      </sect2>

      <sect2>
	<title>Synchronization</title>
	<para>
	  Most of the synchronization (between threads or processes)
	  is done in Wine server, which handles both the waiting
	  operation (on a single object or a set of objects) and the
	  signaling of objects. 
	</para>
      </sect2>

      <sect2>
	<title>Module (DLL) loading</title>
	<para>
	  Wine is able to load any NE and PE module. In all cases,
	  the module's binary code is directly executed by the
	  processor.
	</para>
      </sect2>

      <sect2>
	<title>Device management</title>
	<para>
	  Wine allows usage a wide variety of devices:
	  <itemizedlist>
	    <listitem>
	      <para>
		Communication ports are mapped to Unix
		communication ports (if they have sufficient
		permissions).
	      </para>
	    </listitem>
	    <listitem>
	      <para>
		Parallel ports are mapped to Unix parallel ports (if
		they have sufficient permissions).
	      </para>
	    </listitem>
	    <listitem>
	      <para>
		CDROM: the Windows device I/O control calls are
		mapped onto Unix <function>ioctl()</function>.
	      </para>
	    </listitem>
	    <listitem>
	      <para>
		Some Win9x VxDs are supported, by rewriting some of
		their internal behavior. But this support is
		limited. Portable programs to Windows NT shouldn't
		need them.
	      </para>
	      <para>
		Wine will not support native VxD.
	      </para>
	    </listitem>
	  </itemizedlist>
	</para>
      </sect2>
      <sect2 id="threading">
	<title>Multi-threading in Wine</title>

	<para>
	  This section will assume you understand the basics of
	  multithreading. If not there are plenty of good tutorials
	  available on the net to get you started.
	</para>

	<para>
	  Threading in Wine is somewhat complex due to several
	  factors. The first is the advanced level of multithreading
	  support provided by Windows - there are far more threading
	  related constructs available in Win32 than the Linux
	  equivalent (pthreads). The second is the need to be able to
	  map Win32 threads to native Linux threads which provides us
	  with benefits like having the kernel schedule them without
	  our intervention. While it's possible to implement threading
	  entirely without kernel support, doing so is not desirable
	  on most platforms that Wine runs on.
	</para>

	<sect3>
	  <title> Threading support in Win32 </title>

	  <para>
	    Win32 is an unusually thread friendly API. Not only is it
	    entirely thread safe, but it provides many different
	    facilities for working with threads. These range from the
	    basics such as starting and stopping threads, to the
	    extremely complex such as injecting threads into other
	    processes and COM inter-thread marshalling.
	  </para>

	  <para>
	    One of the primary challenges of writing Wine code
	    therefore is ensuring that all our DLLs are thread safe,
	    free of race conditions and so on. This isn't simple -
	    don't be afraid to ask if you aren't sure whether a piece
	    of code is thread safe or not!
	  </para>

	  <para>
	    Win32 provides many different ways you can make your code
	    thread safe however the most common are <emphasis>critical
	      section</emphasis> and the <emphasis>interlocked
	      functions</emphasis>. Critical sections are a type of
	    mutex designed to protect a geographic area of code. If
	    you don't want multiple threads running in a piece of code
	    at once, you can protect them with calls to
	    <function>EnterCriticalSection</function> and
	    <function>LeaveCriticalSection</function>. The first call
	    to <function>EnterCriticalSection</function> by a thread
	    will lock the section and continue without stopping. If
	    another thread calls it then it will block until the
	    original thread calls
	    <function>LeaveCriticalSection</function> again.
	  </para>

	  <para>
	    It is therefore vitally important that if you use critical
	    sections to make some code thread-safe, that you check
	    every possible codepath out of the code to ensure that any
	    held sections are left. Code like this:
	  </para>

	  <programlisting>
if (res != ERROR_SUCCESS) return res;
	  </programlisting>

	  <para>
	    is extremely suspect in a function that also contains a
	    call to <function>EnterCriticalSection</function>. Be
	    careful.
	  </para>

	  <para>
	    If a thread blocks while waiting for another thread to
	    leave a critical section, you will see an error from the
	    <function>RtlpWaitForCriticalSection</function> function,
	    along with a note of which thread is holding the
	    lock. This only appears after a certain timeout, normally
	    a few seconds. It's possible the thread holding the lock
	    is just being really slow which is why Wine won't
	    terminate the app like a non-checked build of Windows
	    would, but the most common cause is that for some reason a
	    thread forgot to call
	    <function>LeaveCriticalSection</function>, or died while
	    holding the lock (perhaps because it was in turn waiting
	    for another lock). This doesn't just happen in Wine code:
	    a deadlock while waiting for a critical section could be
	    due to a bug in the app triggered by a slight difference
	    in the emulation.
	  </para>
    
	  <para>
	    Another popular mechanism available is the use of
	    functions like <function>InterlockedIncrement</function>
	    and <function>InterlockedExchange</function>. These make
	    use of native CPU abilities to execute a single
	    instruction while ensuring any other processors on the
	    system cannot access memory, and allow you to do common
	    operations like add/remove/check a variable in thread-safe
	    code without holding a mutex. These are useful for
	    reference counting especially in free-threaded (thread
	    safe) COM objects.
	  </para>

	  <para>
	    Finally, the usage of TLS slots are also popular. TLS
	    stands for thread-local storage, and is a set of slots
	    scoped local to a thread which you can store pointers
	    in. Look on MSDN for the <function>TlsAlloc</function>
	    function to learn more about the Win32 implementation of
	    this. Essentially, the contents of a given slot will be
	    different in each thread, so you can use this to store
	    data that is only meaningful in the context of a single
	    thread. On recent versions of Linux the __thread keyword
	    provides a convenient interface to this functionality - a
	    more portable API is exposed in the pthread
	    library. However, these facilities is not used by Wine,
	    rather, we implement Win32 TLS entirely ourselves.
	  </para>
	</sect3>

	<sect3>
	  <title> SysLevels </title>

	  <para>
	    SysLevels are an undocumented Windows-internal
	    thread-safety system. They are basically critical sections
	    which must be taken in a particular order. The mechanism
	    is generic but there are always three syslevels: level 1
	    is the Win16 mutex, level 2 is the USER mutex and level 3
	    is the GDI mutex.
	  </para>

	  <para>
	    When entering a syslevel, the code (in
	    <filename>dlls/kernel/syslevel.c</filename>) will check
	    that a higher syslevel is not already held and produce an
	    error if so. This is because it's not legal to enter level
	    2 while holding level 3 - first, you must leave level 3.
	  </para>

	  <para>
	    Throughout the code you may see calls to
	    <function>_ConfirmSysLevel()</function> and
	    <function>_CheckNotSysLevel()</function>. These functions
	    are essentially assertions about the syslevel states and
	    can be used to check that the rules have not been
	    accidentally violated. In particular,
	    <function>_CheckNotSysLevel()</function> will break
	    (probably into the debugger) if the check fails. If this
	    happens the solution is to get a backtrace and find out,
	    by reading the source of the wine functions called along
	    the way, how Wine got into the invalid state.
	  </para>
    
	</sect3>

	<sect3>
	  <title> POSIX threading vs kernel threading </title>

	  <para>
	    Wine runs in one of two modes: either pthreads (posix
	    threading) or kthreads (kernel threading). This section
	    explains the differences between them. The one that is
	    used is automatically selected on startup by a small test
	    program which then execs the correct binary, either
	    wine-kthread or wine-pthread. On NPTL-enabled systems
	    pthreads will be used, and on older non-NPTL systems
	    kthreads is selected.
	  </para>

	  <para>
	    Let's start with a bit of history. Back in the dark ages
	    when Wines threading support was first implemented a
	    problem was faced - Windows had much more capable
	    threading APIs than Linux did. This presented a problem -
	    Wine works either by reimplementing an API entirely or by
	    mapping it onto the underlying systems equivalent. How
	    could Win32 threading be implemented using a library which
	    did not have all the neeed features? The answer, of
	    course, was that it couldn't be.
	  </para>

	  <para>
	    On Linux the pthreads interface is used to start, stop and
	    control threads. The pthreads library in turn is based on
	    top of so-called "kernel threads" which are created using
	    the <function>clone(2)</function> syscall. Pthreads
	    provides a nicer (more portable) interface to this
	    functionality and also provides APIs for controlling
	    mutexes. There is a <ulink 
	    url="http://www.llnl.gov/computing/tutorials/pthreads/">
	    good tutorial on pthreads </ulink> available if you want
	    to learn more.
	  </para>

	  <para>
	    As pthreads did not provide the necessary semantics to
	    implement Win32 threading, the decision was made to
	    implement Win32 threading on top of the underlying kernel
	    threads by using syscalls like <function>clone</function>
	    directly. This provided maximum flexibility and allowed a
	    correct implementation but caused some bad side
	    effects. Most notably, all the userland Linux APIs assumed
	    that the user was utilising the pthreads library. Some
	    only enabled thread safety when they detected that
	    pthreads was in use - this is true of glibc, for
	    instance. Worse, pthreads and pure kernel threads had
	    strange interactions when run in the same process yet some
	    libraries used by Wine used pthreads internally. Throw in
	    source code porting using WineLib - where you have both
	    UNIX and Win32 code in the same process - and chaos was
	    the result.
	  </para>

	  <para>
	    The solution was simple yet ingenius: Wine would provide
	    its own implementation of the pthread library
	    <emphasis>inside</emphasis> its own binary. Due to the
	    semantics of ELF symbol scoping, this would cause Wines
	    own implementations to override any implementation loaded
	    later on (like the real libpthread.so). Therefore, any
	    calls to the pthread APIs in external libraries would be
	    linked to Wines instead of the systems pthreads library,
	    and Wine implemented pthreads by using the standard
	    Windows threading APIs it in turn implemented itself.
	  </para>

	  <para>
	    As a result, libraries that only became thread-safe in the
	    presence of a loaded pthreads implementation would now do
	    so, and any external code that used pthreads would
	    actually end up creating Win32 threads that Wine was aware
	    of and controlled. This worked quite nicely for a long
	    time, even though it required doing some extremely
	    un-kosher things like overriding internal libc structures
	    and functions. That is, it worked until NPTL was developed
	    at which point the underlying thread implementation on
	    Linux changed dramatically.
	  </para>

	  <para>
	    The fake pthread implementation can be found in
	    <filename>loader/kthread.c</filename>, which is used to
	    produce to wine-kthread binary. In contrast,
	    loader/pthread.c produces the wine-pthread binary which is
	    used on newer NPTL systems.
	  </para>

	  <para>
	    NPTL is a new threading subsystem for Linux that hugely
	    improves its performance and flexibility. By allowing
	    threads to become much more scalable and adding new
	    pthread APIs, NPTL made Linux competitive with Windows in
	    the multi-threaded world. Unfortunately it also broke many
	    assumptions made by Wine (as well as other applications
	    such as the Sun JVM and RealPlayer) in the process.
	  </para>

	  <para>
	    There was, however, some good news. NPTL made Linux
	    threading powerful enough that Win32 threads could now be
	    implemented on top of pthreads like any other normal
	    application. There would no longer be problems with mixing
	    win32-kthreads and pthreads created by external libraries,
	    and no need to override glibc internals. As you can see
	    from the relative sizes of the
	    <filename>loader/kthread.c</filename> and
	    <filename>loader/pthread.c</filename> files, the
	    difference in code complexity is considerable. NPTL also
	    made several other semantic changes to things such as
	    signal delivery so changes were required in many different
	    places in Wine.
	  </para>

	  <para>
	    On non-Linux systems the threading interface is typically
	    not powerful enough to replicate the semantics Win32
	    applications expect and so kthreads with the pthread
	    overrides are used.
	  </para>
	</sect3>

	<sect3>
	  <title> The Win32 thread environment </title>

	  <para>
	    All Win32 code, whether from a native EXE/DLL or in Wine 
	    itself, expects certain constructs to be present in its
	    environment. This section explores what those constructs
	    are and how Wine sets them up. The lack of this
	    environment is one thing that makes it hard to use Wine
	    code directly from standard Linux applications - in order
	    to interact with Win32 code a thread must first be
	    "adopted" by Wine.
	  </para>

	  <para>
	    The first thing Win32 code requires is the
	    <emphasis>TEB</emphasis> or "Thread Environment
	    Block". This is an internal (undocumented) Windows
	    structure associated with every thread which stores a
	    variety of things such as TLS slots, a pointer to the
	    threads message queue, the last error code and so on. You
	    can see the definition of the TEB in
	    <filename>include/thread.h</filename>, or at least what we
	    know of it so far. Being internal and subject to change,
	    the layout of the TEB has had to be reverse engineered
	    from scratch.
	  </para>

	  <para>
	    A pointer to the TEB is stored in the %fs register and can
	    be accessed using <function>NtCurrentTeb()</function> from
	    within Wine code. %fs actually stores a selector, and
	    setting it therefore requires modifying the processes
	    local descriptor table (LDT) - the code to do this is in
	    <filename>lib/wine/ldt.c</filename>. 
	  </para>

	  <para>
	    The TEB is required by nearly all Win32 code run in the
	    Wine environment, as any wineserver RPC will use it, which
	    in turn implies that any code which could possibly block
	    (for instance by using a critical section) needs it. The
	    TEB also holds the SEH exception handler chain as the
	    first element, so if when disassembling you see code like
	    this:
	  </para>

	  <programlisting> movl %esp, %fs:0 </programlisting>

	  <para>
	    ... then you are seeing the program set up an SEH handler
	    frame. All threads must have at least one SEH entry, which
	    normally points to the backstop handler which is
	    ultimately responsible for popping up the all-too-familiar
	    "This program has performed an illegal operation and will
	    be terminated" message. On Wine we just drop straight into
	    the debugger. A full description of SEH is out of the
	    scope of this section, however there are some good
	    articles in MSJ if you are interested.
	  </para>

	  <para>
	    All Win32-aware threads must have a wineserver
	    connection. Many different APIs require the ability to
	    communicate with the wineserver. In turn, the wineserver
	    must be aware of Win32 threads in order to be able to
	    accurately report information to other parts of the program
	    and do things like route inter-thread messages, dispatch
	    APCs (asynchronous procedure calls) and so on. Therefore a
	    part of thread initialization is initializing the thread
	    serverside. The result is not only correct information in
	    the server, but a set of file descriptors the thread can use
	    to communicate with the server - the request fd, reply fd
	    and wait fd (used for blocking).
	  </para>
	</sect3>
      </sect2>
    </sect1>

    <sect1>
      <title>KERNEL Module</title>
      
      <para>
	FIXME: Needs some content...
      </para>
      <sect2 id="consoles">
	<title>Consoles in Wine</title>
	<para>
	  As described in the Wine User Guide's CUI section, Wine
	  manipulates three kinds of "consoles" in order to support
	  properly the Win32 CUI API.
	</para>
	<para>
	  The following table describes the main implementation
	  differences between the three approaches.
	  <table>
	    <title>Function consoles implementation comparison</title>
	    <tgroup cols="4" align="left">
	      <thead>
		<row>
		  <entry>Function</entry>
		  <entry>Bare streams</entry>
		  <entry>Wineconsole &amp; user backend</entry>
		  <entry>Wineconsole &amp; curses backend</entry>
		</row>
	      </thead>
	      <tbody>
		<row>
		  <entry>
		    Console as a Win32 Object (and associated
		    handles)
		  </entry> 
		  <entry>
		    No specific Win32 object is used in this
		    case. The handles manipulated for the standard
		    Win32 streams are in fact "bare handles" to
		    their corresponding Unix streams. The mode
		    manipulation functions
		    (<function>GetConsoleMode</function> /
		    <function>SetConsoleMode</function>) are not
		    supported.
		  </entry>
		  <entry>
		    Implemented in server, and a specific Winelib
		    program (wineconsole) is in charge of the
		    rendering and user input. The mode manipulation
		    functions behave as expected.
		  </entry>
		  <entry>
		    Implemented in server, and a specific Winelib
		    program (wineconsole) is in charge of the
		    rendering and user input. The mode manipulation
		    functions behave as expected.
		  </entry>
		</row>
		<row>
		  <entry>
		    Inheritance (including handling in
		    <function>CreateProcess</function> of
		    <constant>CREATE_DETACHED</constant>,
		    <constant>CREATE_NEW_CONSOLE</constant> flags).
		  </entry>
		  <entry>
		    Not supported. Every process child of a process
		    will inherit the Unix streams, so will also
		    inherit the Win32 standard streams.
		  </entry>
		  <entry>
		    Fully supported (each new console creation will
		    be handled by the creation of a new USER32
		    window)
		  </entry>
		  <entry>
		    Fully supported, except for the creation of a
		    new console, which will be rendered on the same
		    Unix terminal as the previous one, leading to
		    unpredictable results.
		  </entry>
		</row>
		<row>
		  <entry>
		    <function>ReadFile</function> /
		    <function>WriteFile</function>
		    operations
		  </entry> 
		  <entry>Fully supported</entry>
		  <entry>Fully supported</entry>
		  <entry>Fully supported</entry>
		</row>
		<row>
		  <entry>
		    Screen-buffer manipulation (creation, deletion,
		    resizing...)
		  </entry>
		  <entry>Not supported</entry>
		  <entry>Fully supported</entry>
		  <entry>
		    Partly supported (this won't work too well as we
		    don't control (so far) the size of underlying
		    Unix terminal
		  </entry>
		</row>
		<row>
		  <entry>
		    APIs for reading/writing screen-buffer content,
		    cursor position
		  </entry>
		  <entry>Not supported</entry>
		  <entry>Fully supported</entry>
		  <entry>Fully supported</entry>
		</row>
		<row>
		  <entry>
		    APIs for manipulating the rendering window size
		  </entry>
		  <entry>Not supported</entry>
		  <entry>Fully supported</entry>
		  <entry>
		    Partly supported (this won't work too well as we
		    don't control (so far) the size of underlying
		    Unix terminal
		  </entry>
		</row>
		<row>
		  <entry>
		    Signaling (in particular, Ctrl-C handling)
		  </entry>
		  <entry>
		    Nothing is done, which means that Ctrl-C will
		    generate (as usual) a
		    <constant>SIGINT</constant> which will terminate
		    the program.
		  </entry>
		  <entry>
		    Partly supported (Ctrl-C behaves as expected,
		    however the other Win32 CUI signaling isn't
		    properly implemented).
		  </entry>
		  <entry>
		    Partly supported (Ctrl-C behaves as expected,
		    however the other Win32 CUI signaling isn't
		    properly implemented).
		  </entry>
		</row>
	      </tbody>
	    </tgroup>
	  </table>
	</para>

	<para>
	  The Win32 objects behind a console can be created in
	  several occasions:
	  <itemizedlist>
	    <listitem>
	      <para>
		When the program is started from wineconsole, a new
		console object is created and will be used
		(inherited) by the process launched from
		wineconsole.
	      </para>
	    </listitem>
	    <listitem>
	      <para>
		When a program, which isn't attached to a console,
		calls <function>AllocConsole</function>, Wine then
		launches wineconsole, and attaches the current
		program to this console. In this mode, the USER32
		mode is always selected as Wine cannot tell the
		current state of the Unix console.
	      </para>
	    </listitem>
	  </itemizedlist>
	</para>
	<para>
	  Please also note, that starting a child process with the
	  <constant>CREATE_NEW_CONSOLE</constant> flag, will end-up
	  calling <function>AllocConsole</function> in the child
	  process, hence creating a wineconsole with the USER32
	  backend.
	</para>
      </sect2>
    </sect1>
    
    <sect1 id="initialization">

      <title> The Wine initialization process </title>

      <para>
	Wine has a rather complex startup procedure, so unlike many
	programs the best place to begin exploring the code-base is
	<emphasis>not</emphasis> in fact at the
	<function>main()</function> function but instead at some of the
	more straightforward DLLs that exist on the periphery such as
	MSI, the widget library (in USER and COMCTL32) etc. The purpose
	of this section is to document and explain how Wine starts up
	from the moment the user runs "wine myprogram.exe" to the point
	at which myprogram gets control.
      </para>

      <sect2>
	<title> First Steps </title>

	<para>
	  The actual wine binary that the user runs does not do very much, in fact it is only
	  responsible for checking the threading model in use (NPTL vs LinuxThreads) and then invoking
	  a new binary which performs the next stage in the startup sequence. See the threading chapter
	  for more information on this check and why it's necessary. You can find this code in
	  <filename>loader/glibc.c</filename>. The result of this check is an exec of either
	  wine-pthread or wine-kthread, potentially (on Linux) via
	  the <emphasis>preloader</emphasis>. We need to use separate binaries here because overriding
	  the native pthreads library requires us to exploit a property of ELF symbol fixup semantics:
	  it's not possible to do this without starting a new process.
	</para>

	<para>
	  The Wine preloader is found in <filename>loader/preloader.c</filename>, and is required in
	  order to impose a Win32 style address space layout upon the newly created Win32 process. The
	  details of what this does is covered in the address space layout chapter. The preloader is a
	  statically linked ELF binary which is passed the name of the actual Wine binary to run (either
	  wine-kthread or wine-pthread) along with the arguments the user passed in from the command
	  line. The preloader is an unusual program: it does not have a main() function. In standard ELF
	  applications, the entry point is actually at a symbol named _start: this is provided by the
	  standard gcc infrastructure and normally jumps to <function>__libc_start_main</function> which
	  initializes glibc before passing control to the main function as defined by the programmer.
	</para>

	<para>
	  The preloader takes control direct from the entry point for a few reasons. Firstly, it is
	  required that glibc is not initialized twice: the result of such behaviour is undefined and
	  subject to change without notice. Secondly, it's possible that as part of initializing glibc,
	  the address space layout could be changed - for instance, any call to malloc will initialize a
	  heap arena which modifies the VM mappings. Finally, glibc does not return to _start at any
	  point, so by reusing it we avoid the need to recreate the ELF bootstrap stack (env, argv,
	  auxiliary array etc).
	</para>

	<para>
	  The preloader is responsible for two things: protecting important regions of the address
	  space so the dynamic linker does not map shared libraries into them, and once that is done
	  loading the real Wine binary off disk, linking it and starting it up. Normally all this is
	  done automatically by glibc and the kernel but as we intercepted this process by using a
	  static binary it's up to us to restart the process. The bulk of the code in the preloader is
	  about loading wine-[pk]thread and ld-linux.so.2 off disk, linking them together, then
	  starting the dynamic linking process.
	</para>

	<para>
	  One of the last things the preloader does before jumping into the dynamic linker is scan the
	  symbol table of the loaded Wine binary and set the value of a global variable directly: this
	  is a more efficient way of passing information to the main Wine program than flattening the
	  data structures into an environment variable or command line parameter then unpacking it on
	  the other side, but it achieves pretty much the same thing. The global variable set points to
	  the preload descriptor table, which contains the VMA regions protected by the preloader. This
	  allows Wine to unmap them once the dynamic linker has been run, so leaving gaps we can
	  initialize properly later on.
	</para>

      </sect2>
    
      <sect2>
	<title> Starting the emulator </title>

	<para>
	  The process of starting up the emulator itself is mostly one of chaining through various
	  initializer functions defined in the core libraries and DLLs: libwine, then NTDLL, then kernel32.
	</para>

	<para>
	  Both the wine-pthread and wine-kthread binaries share a common <function>main</function>
	  function, defined in <filename>loader/main.c</filename>, so no matter which binary is selected
	  after the preloader has run we start here. This passes the information provided by the
	  preloader into libwine and then calls wine_init, defined
	  in <filename>libs/wine/loader.c</filename>. This is where the emulation really starts:
	  <function>wine_init</function> can, with the correct preparation,
	  be called from programs other than the wine loader itself.
	</para>

	<para>
	  <function>wine_init</function> does some very basic setup tasks such as initializing the
	  debugging infrastructure, yet more address space manipulation (see the information on the
	  4G/4G VM split in the address space chapter), before loading NTDLL - the core of both Wine and
	  the Windows NT series - and jumping to the <function>__wine_process_init</function> function defined
	  in <filename>dlls/ntdll/loader.c</filename>
	</para>

	<para>
	  This function is responsible for initializing the primary Win32 environment. In thread_init(),
	  it sets up the TEB, the wineserver connection for the main thread and the process heap. See
	  the threading chapter for more information on this.
	</para>

	<para>
	  Finally, it loads and jumps to <function>__wine_kernel_init</function> in kernel32.dll: this
	  is defined in <filename>dlls/kernel32/process.c</filename>. This is where the bulk of the work
	  is done. The kernel32 initialization code retrieves the startup info for the process from the
	  server, initializes the registry, sets up the drive mapping system and locale data, then
	  begins loading the requested application itself. Each process has a STARTUPINFO block that can
	  be passed into <function>CreateProcess</function> specifying various things like how the first
	  window should be displayed: this is sent to the new process via the wineserver.
	</para>

	<para>
	  After determining the type of file given to Wine by the user (a Win32 EXE file, a Win16 EXE, a
	  Winelib app etc), the program is loaded into memory (which may involve loading and
	  initializing other DLLs, the bulk of Wines startup code), before control reaches the end of
	  <function>__wine_kernel_init</function>. This function ends with the new process stack being
	  initialized, and start_process being called on the new stack. Nearly there!
	</para>

	<para>
	  The final element of initializing Wine is starting the newly loaded program
	  itself. <function>start_process</function> sets up the SEH backstop handler, calls
	  <function>LdrInitializeThunk</function> which performs the last part of the process
	  initialization (such as performing relocations and calling the DllMains with PROCESS_ATTACH),
	  grabs the entry point of the executable and then on this line:
	</para>

	<programlisting>
ExitProcess( entry( peb ) );
	</programlisting>

	<para>
	  ... jumps to the entry point of the program. At this point the users program is running and
	  the API provided by Wine is ready to be used. When entry returns,
	  the <function>ExitProcess</function> API will be used to initialize a graceful shutdown.
	</para>
      </sect2>
    </sect1>

    <sect1 id="seh">
      <title>Structured Exception Handling</title>
      
      <para>
        Structured Exception Handling (or SEH) is an implementation of
        exceptions inside the Windows core. It allows code written in
        different languages to throw exceptions across DLL boundaries, and
        Windows reports various errors like access violations by throwing
        them. This section looks at how it works, and how it's implemented
        in Wine.
      </para>

      <sect2>
        <title> How SEH works </title>

        <para>
          SEH is based on embedding EXCEPTION_REGISTRATION_RECORD
          structures in the stack. Together they form a linked list rooted
          at offset zero in the TEB (see the threading section if you
          don't know what this is). A registration record points to a
          handler function, and when an exception is thrown the handlers
          are executed in turn. Each handler returns a code, and they can
          elect to either continue through the handler chain or it can
          handle the exception and then restart the program. This is
          referred to as unwinding the stack. After each handler is called
          it's popped off the chain.
        </para>

        <para>
          Before the system begins unwinding the stack, it runs vectored
          handlers. This is an extension to SEH available in Windows XP,
          and allows registered functions to get a first chance to watch
          or deal with any exceptions thrown in the entire program, from
          any thread.
        </para>

        <para>
          A thrown exception is represented by an EXCEPTION_RECORD
          structure. It consists of a code, flags, an address and an
          arbitrary number of DWORD parameters. Language runtimes can use
          these parameters to associate language-specific information with
          the exception.
        </para>
        
        <para>
          Exceptions can be triggered by many things. They can be thrown
          explicitly by using the RaiseException API, or they can be
          triggered by a crash (ie, translated from a signal). They may be
          used internally by a language runtime to implement
          language-specific exceptions. They can also be thrown across
          DCOM connections.
        </para>

        <para>
          Visual C++ has various extensions to SEH which it uses to
          implement, eg, object destruction on stack unwind as well as the
          ability to throw arbitrary types. The code for this is in dlls/msvcrt/except.c
        </para>

      </sect2>
      
      <sect2>
        <title> Translating signals to exceptions </title>

        <para>
          In Windows, compilers are expected to use the system exception
          interface, and the kernel itself uses the same interface to
          dynamically insert exceptions into a running program. By contrast
          on Linux the exception ABI is implemented at the compiler level
          (inside GCC and the linker) and the kernel tells a thread of
          exceptional events by sending <emphasis>signals</emphasis>. The
          language runtime may or may not translate these signals into
          native exceptions, but whatever happens the kernel does not care.
        </para>

        <para>
          You may think that if an app crashes, it's game over and it
          really shouldn't matter how Wine handles this. It's what you might
          intuitively guess, but you'd be wrong. In fact some Windows
          programs expect to be able to crash themselves and recover later
          without the user noticing, some contain buggy binary-only
          components from third parties and use SEH to swallow crashes, and
          still others execute priviledged (kernel-level) instructions and
          expect it to work. In fact, at least one set of APIs (the
          IsBad*Ptr series) can only be implemented by performing an
          operation that may crash and returning TRUE if it does, and FALSE
          if it doesn't! So, Wine needs to not only implement the SEH
          infrastructure but also translate Unix signals into SEH
          exceptions.
        </para>

        <para>
          The code to translate signals into exceptions is a part of NTDLL,
          and can be found in dlls/ntdll/signal_i386.c. This file sets up
          handlers for various signals during Wine startup, and for the ones
          that indicate exceptional conditions translates them into
          exceptions. Some signals are used by Wine internally and have
          nothing to do with SEH.
        </para>

        <para>
          Signal handlers in Wine run on their own stack. Each thread has
          its own signal stack which resides 4k after the TEB. This is
          important for a couple of reasons. Firstly, because there's no
          guarantee that the app thread which triggered the signal has
          enough stack space for the Wine signal handling code. In
          Windows, if a thread hits the limits of its stack it triggers a
          fault on the stack guard page. The language runtime can use this
          to grow the stack if it wants to.

          <!-- fixme: is it really the language runtime that does this? i
               can't find any code in Wine to reallocate the stack on
               STATUS_GUARD_PAGE_VIOLATION -->

          However, because a guard page violation is just a regular
          segfault to the kernel, that would lead to a nested signal
          handler and that gets messy really quick so we disallow that in
          Wine. Secondly, setting up the exception to throw requires
          modifying the stack of the thread which triggered it, which is
          quite hard to do when you're still running on it.
        </para>

        <para>
          Windows exceptions typically contain more information than the
          Unix standard APIs provide. For instance, a
          STATUS_ACCESS_VIOLATION exception (0xC0000005) structure
          contains the faulting address, whereas a standard Unix SIGSEGV
          just tells the app that it crashed. Usually this information is
          passed as an extra parameter to the signal handler, however its
          location and contents vary between kernels (BSD, Solaris,
          etc). This data is provided in a SIGCONTEXT structure, and on
          entry to the signal handler it contains the register state of
          the CPU before the signal was sent. Modifying it will cause the
          kernel to adjust the context before restarting the thread.
        </para>
        
      </sect2>
      
    </sect1>

  </chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-devel.sgml" "set" "book" "part" "chapter" "")
End:
-->