Give IUnknown its own ifstub to fix ref-counting and ipid storage

[wine] / documentation / winedev-kernel.sgml

  <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:
-->