Moved command-line option handling out of the X11 driver.

[wine] / documentation / internals

KERNEL MODULE
=============

...

GDI MODULE
==========

1. X Windows System interface
-----------------------------

The X libraries used to implement X clients (such as Wine) do not work
properly if multiple threads access the same display concurrently. It is
possible to compile the X libraries to perform their own synchronization
(initiated by calling XInitThreads()). However, Wine does not use this
approach. Instead Wine performs its own synchronization py putting a
wrapper around every X call that is used. This wrapper protects library
access with a critical section, and also arranges things so that X
libraries compiled without -D_REENTRANT (eg. with global errno variable)
will work with Wine.

To make this scheme work, all calls to X must use the proper wrapper
functions (or do their own synchronization that is compatible with the
wrappers). The wrapper for a function X...() is calles TSX...() (for
"Thread Safe X ..."). So for example, instead of calling XOpenDisplay()
in the code, TSXOpenDisplay() must be used. Likewise, X include files
that contain function prototypes are wrapped, so that eg. "ts_xutil.h"
must be included rather than <X11/Xutil.h>. It is important that this
scheme is used everywhere to avoid the introduction of nondeterministic
and hard-to-find errors in Wine.

The code for the thread safe X wrappers is contained in the tsx11/
directory and in include/ts*.h. To use a new (ie. not previously used) X
function in Wine, a new wrapper must be created. The wrappers are
generated (semi-)automatically from the X11R6 includes using the
tools/make_X11wrappers perl script. In simple cases it should be enough
to add the name of the new function to the list in tsx11/X11_calls; if
this does not work the wrapper must be added manually to the
make_X11wrappers script. See comments in tsx11/X11_calls and
tools/make_X11wrappers for further details.


USER MODULE
===========

USER implements windowing and messaging subsystems. It also 
contains code for common controls and for other miscellaneous 
stuff (rectangles, clipboard, WNet, etc). Wine USER code is 
located in windows/, controls/, and misc/ directories.

1. Windowing subsystem
----------------------

   windows/win.c
   windows/winpos.c

   Windows are arranged into parent/child hierarchy with one
   common ancestor for all windows (desktop window). Each window
   structure contains a pointer to the immediate ancestor (parent 
   window if WS_CHILD style bit is set), a pointer to the sibling 
   (returned by GetWindow(..., GW_NEXT)), a pointer to the owner 
   window (set only for popup window if it was created with valid 
   hwndParent parameter), and a pointer to the first child
   window (GetWindow(.., GW_CHILD)). All popup and non-child windows
   are therefore placed in the first level of this hierarchy and their
   ancestor link (wnd->parent) points to the desktop window.

   Desktop window                       - root window
    |     \      `-.
    |      \        `-.
   popup -> wnd1  ->  wnd2              - top level windows    
    |       \   `-.      `-.
    |        \     `-.      `-.
   child1  child2 -> child3  child4     - child windows
  
   Horizontal arrows denote sibling relationship, vertical lines
   - ancestor/child. To summarize, all windows with the same immediate 
   ancestor are sibling windows, all windows which do not have desktop 
   as their immediate ancestor are child windows. Popup windows behave
   as topmost top-level windows unless they are owned. In this case the
   only requirement is that they must precede their owners in the top-level 
   sibling list (they are not topmost). Child windows are confined to the
   client area of their parent windows (client area is where window gets
   to do its own drawing, non-client area consists of caption, menu, borders,
   intrinsic scrollbars, and minimize/maximize/close/help buttons). 
  
   Another fairly important concept is "z-order". It is derived from
   the ancestor/child hierarchy and is used to determine "above/below"
   relationship. For instance, in the example above, z-order is
   child1->popup->child2->child3->wnd1->child4->wnd2->desktop. Current 
   active window ("foreground window" in Win32) is moved to the front
   of z-order unless its top-level ancestor owns popup windows.

   All these issues are dealt with (or supposed to be) in windows/winpos.c 
   with SetWindowPos() being the primary interface to the window manager.

   Wine specifics: in default and managed mode each top-level window
   gets its own X counterpart with desktop window being basically a 
   fake stub. In desktop mode, however, only desktop window has an X
   window associated with it. Also, SetWindowPos() should eventually be
   implemented via Begin/End/DeferWindowPos() calls and not the other way
   around.

   1.1 Visible region, clipping region and update region

   windows/dce.c
   windows/winpos.c
   windows/painting.c

    ________________________
   |_________               |  A and B are child windows of C
   |    A    |______        | 
   |         |      |       |
   |---------'      |       |
   |   |      B     |       |
   |   |            |       |
   |   `------------'       |
   |                   C    |
   `------------------------'

   Visible region determines which part of the window is not obscured
   by other windows. If a window has the WS_CLIPCHILDREN style then all
   areas below its children are considered invisible. Similarily, if
   the WS_CLIPSIBLINGS bit is in effect then all areas obscured by its
   siblings are invisible. Child windows are always clipped by the 
   boundaries of their parent windows.

   B has a WS_CLIPSIBLINGS style:
   .          ______ 
   :         |      |
   |   ,-----'      |
   |   |      B     | - visible region of B
   |   |            |
   :   `------------'
    
   When the program requests a display context (DC) for a window it 
   can specify an optional clipping region that further restricts the 
   area where the graphics output can appear. This area is calculated 
   as an intersection of the visible region and a clipping region. 

   Program asked for a DC with a clipping region:
          ______
      ,--|--.   |     .    ,--. 
   ,--+--'  |   |     :   _:  |
   |  |   B |   |  => |  |    | - DC region where the painting will
   |  |     |   |     |  |    |   be visible
   `--|-----|---'     :  `----'
      `-----'

   When the window manager detects that some part of the window 
   became visible it adds this area to the update region of this
   window and then generates WM_ERASEBKGND and WM_PAINT messages. 
   In addition, WM_NCPAINT message is sent when the uncovered area 
   intersects a nonclient part of the window. Application must reply 
   to the WM_PAINT message by calling BeginPaint()/EndPaint() pair of
   functions. BeginPaint() returns a DC that uses accumulated update 
   region as a clipping region. This operation cleans up invalidated
   area and the window will not receive another WM_PAINT until the
   window manager creates a new update region.

   A was moved to the left:
    ________________________       ...          / C update region
   |______                  |     :      .___ /
   | A    |_________        |  => |   ...|___|..
   |      |         |       |     |   :  |   |
   |------'         |       |     |   :  '---' 
   |   |      B     |       |     |   :      \
   |   |            |       |     :            \
   |   `------------'       |                    B update region
   |                   C    |
   `------------------------'


   Windows maintains a display context cache consisting of entries that 
   include DC itself, window to which it belongs, and an optional clipping 
   region (visible region is stored in the DC itself). When an API call 
   changes the state of the window tree, window manager has to go through 
   the DC cache to recalculate visible regions for entries whose windows 
   were involved in the operation. DC entries (DCE) can be either private
   to the window, or private to the window class, or shared between all 
   windows (Windows 3.1 limits the number of shared DCEs to 5).

   1.2

2. Messaging subsystem
----------------------

   windows/queue.c
   windows/message.c

   Each Windows task/thread has its own message queue - this is where
   it gets messages from. Messages can be generated on the fly
   (WM_PAINT, WM_NCPAINT, WM_TIMER), they can be created by the system
   (hardware messages), they can be posted by other tasks/threads
   (PostMessage), or they can be sent by other tasks/threads (SendMessage).
   
   Message priority:

   First the system looks for sent messages, then for posted messages,
   then for hardware messages, then it checks if the queue has the
   "dirty window" bit set, and, finally, it checks for expired
   timers. See windows/message.c.

   From all these different types of messages, only posted messages go
   directly into the private message queue. System messages (even in
   Win95) are first collected in the system message queue and then
   they either sit there until Get/PeekMessage gets to process them
   or, as in Win95, if system queue is getting clobbered, a special
   thread ("raw input thread") assigns them to the private
   queues. Sent messages are queued separately and the sender sleeps
   until it gets a reply. Special messages are generated on the fly
   depending on the window/queue state. If the window update region is
   not empty, the system sets the QS_PAINT bit in the owning queue and
   eventually this window receives a WM_PAINT message (WM_NCPAINT too
   if the update region intersects with the non-client area). A timer
   event is raised when one of the queue timers expire. Depending on
   the timer parameters DispatchMessage either calls the callback
   function or the window procedure. If there are no messages pending
   the task/thread sleeps until messages appear.

   There are several tricky moments (open for discussion) - 

    a) System message order has to be honored and messages should be
       processed within correct task/thread context. Therefore when
       Get/PeekMessage encounters unassigned system message and this
       message appears not to be for the current task/thread it should
       either skip it (or get rid of it by moving it into the private
       message queue of the target task/thread - Win95, AFAIK) and
       look further or roll back and then yield until this message
       gets processed when system switches to the correct context
       (Win16). In the first case we lose correct message ordering, in
       the second case we have the infamous synchronous system message
       queue. Here is a post to one of the OS/2 newsgroup I found to
       be relevant:

        " Here's the problem in a nutshell, and there is no good solution.
        Every possible solution creates a different problem.

        With a windowing system, events can go to many different windows.
        Most are sent by applications or by the OS when things relating to
        that window happen (like repainting, timers, etc.)

        Mouse input events go to the window you click on (unless some window
        captures the mouse).

        So far, no problem.  Whenever an event happens, you put a message on
        the target window's message queue.  Every process has a message
        queue.  If the process queue fills up, the messages back up onto the
        system queue.

        This is the first cause of apps hanging the GUI.  If an app doesn't
        handle messages and they back up into the system queue, other apps
        can't get any more messages.  The reason is that the next message in
        line can't go anywhere, and the system won't skip over it.
        
        This can be fixed by making apps have bigger private message queues.
        The SIQ fix does this.  PMQSIZE does this for systems without the SIQ
        fix.  Applications can also request large queues on their own.

        Another source of the problem, however, happens when you include
        keyboard events.  When you press a key, there's no easy way to know
        what window the keystroke message should be delivered to.

        Most windowing systems use a concept known as "focus".  The window
        with focus gets all incoming keyboard messages.  Focus can be changed
        from window to window by apps or by users clicking on winodws.

        This is the second source of the problem.  Suppose window A has focus.
        You click on window B and start typing before the window gets focus.
        Where should the keystrokes go?  On the one hand, they should go to A
        until the focus actually changes to B.  On the other hand, you
        probably want the keystrokes to go to B, since you clicked there
        first.

        OS/2's solution is that when a focus-changing event happens (like
        clicking on a window), OS/2 holds all messages in the system queue
        until the focus change actually happens.  This way, subsequent
        keystrokes go to the window you clicked on, even if it takes a while
        for that window to get focus.

        The downside is that if the window takes a real long time to get focus
        (maybe it's not handling events, or maybe the window losing focus
        isn't handling events), everything backs up in the system queue and
        the system appears hung.

        There are a few solutions to this problem.

        One is to make focus policy asynchronous.  That is, focus changing has
        absolutely nothing to do with the keyboard.  If you click on a window
        and start typing before the focus actually changes, the keystrokes go
        to the first window until focus changes, then they go to the second.
        This is what X-windows does.

        Another is what NT does.  When focus changes, keyboard events are held
        in the system message queue, but other events are allowed through.
        This is "asynchronous" because the messages in the system queue are
        delivered to the application queues in a different order from that
        with which they were posted.  If a bad app won't handle the "lose
        focus" message, it's of no consequence - the app receiving focus will
        get its "gain focus" message, and the keystrokes will go to it.

        The NT solution also takes care of the application queue filling up
        problem.  Since the system delivers messages asynchronously, messages
        waiting in the system queue will just sit there and the rest of the
        messages will be delivered to their apps.

        The OS/2 SIQ solution is this:  When a focus-changing event happens,
        in addition to blocking further messages from the application queues,
        a timer is started.  When the timer goes off, if the focus change has
        not yet happened, the bad app has its focus taken away and all
        messages targetted at that window are skipped.  When the bad app
        finally handles the focus change message, OS/2 will detect this and
        stop skipping its messages.


        As for the pros and cons:

        The X-windows solution is probably the easiest.  The problem is that
        users generally don't like having to wait for the focus to change
        before they start typing.  On many occasions, you can type and the
        characters end up in the wrong window because something (usually heavy
        system load) is preventing the focus change from happening in a timely
        manner.
        
        The NT solution seems pretty nice, but making the system message queue
        asynchronous can cause similar problems to the X-windows problem.
        Since messages can be delivered out of order, programs must not assume
        that two messages posted in a particular order will be delivered in
        that same order.  This can break legacy apps, but since Win32 always
        had an asynchronous queue, it is fair to simply tell app designers
        "don't do that".  It's harder to tell app designers something like
        that on OS/2 - they'll complain "you changed the rules and our apps
        are breaking."
        
        The OS/2 solution's problem is that nothing happens until you try to
        change window focus, and then wait for the timeout.  Until then, the
        bad app is not detected and nothing is done." (by David Charlap)
        

    b) Intertask/interthread SendMessage. The system has to inform the
       target queue about the forthcoming message, then it has to carry 
       out the context switch and wait until the result is available.  
       Win16 stores necessary parameters in the queue structure and then 
       calls DirectedYield() function.  However, in Win32 there could be 
       several messages pending sent by preemptively executing threads, 
       and in this case SendMessage has to build some sort of message 
       queue for sent messages. Another issue is what to do with messages 
       sent to the sender when it is blocked inside its own SendMessage.