| KERNEL MODULE | |
| ============= | |
| ... | |
| GDI MODULE | |
| ========== | |
| ... | |
| 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 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 | |
| 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. | |
| 2. Messaging subsystem | |
| 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. | |