Sweden-Number/documentation/user_module

217 lines
11 KiB
Plaintext
Raw Normal View History

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 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 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
Release 960811 Sun Aug 11 13:00:20 1996 Alexandre Julliard <julliard@lrc.epfl.ch> * [configure.in] [include/acconfig.h] [tools/build.c] Added check for underscore on external symbols. * [memory/selector.c] [memory/global.c] Fixed FreeSelector() to free only one selector. Added SELECTOR_FreeBlock() to free an array of selectors. * [objects/color.c] Fixed a bug in COLOR_ToLogical() that caused GetPixel() to fail on hi-color displays. * [tools/build.c] [if1632/crtdll.spec] Added 'extern' type, used for external variables or functions. * [windows/winpos.c] Allow de-activating a window in WINPOS_ChangeActiveWindow(). * [windows/winproc.c] Added 32-to-16 translation for button messages. Fixed WINPROC_GetPtr() to avoid crashes on 32-bit procedures that happen to be valid SEGPTRs. Sat Aug 10 18:22:25 1996 Albrecht Kleine <kleine@ak.sax.de> * [windows/message.c] Removed a FIXME in MSG_PeekHardwareMsg(): produces correct data for the JOURNALRECORD-hook (using EVENTMSG16 structure). * [if1632/gdi.spec] [include/windows.h] [objects/metafile.c] Introduced undocumented API function IsValidMetaFile(), plus a minor fix in last patch of CopyMetaFile(). * [objects/gdiobj.c] Removed a FIXME in IsGDIObject(): added magic word check. Sun Aug 10 18:10:10 1996 Bruce Milner <Bruce.Milner@genetics.utah.edu> * [controls/statuswin.c] First pass at implementing the StatusWindow class. * [include/commctrl.h] Header file for common controls. * [controls/widgets.c] Added InitCommonControls(). * [if1632/comctl32.spec] Add DrawStatusTextA, CreateStatusWindowA, InitCommonControls. * [win32/findfile.c] [if1632/kernel32.spec] Add FindNextFile32A, FindClose. Modified FindFirstFile32A so it works with FindNextFile32A. * [include/winbase.h] Fixed WIN32_FIND_DATA structure member names. Sat Aug 10 09:00:00 1996 Alex Korobka <alex@phm30.pharm.sunysb.edu> * [windows/scroll.c] Changed scrolling routines to benefit from DCE code update. Thu Aug 8 18:05:09 1996 Marcus Meissner <msmeissn@cip.informatik.uni-erlangen.de> * [files/file.c] SearchPath* could get NULL for lastpart argument. * [if1632/build-spec.txt] [documentation/debugging] Varargs documentation added, debugging hints updated. * [if1632/crtdll.spec][misc/crtdll.c][misc/Makefile.in] Started to implement CRTDLL. * [if1632/wsock32.spec] Some thunks to standard libc functions (structures have the same elements, but perhaps wrong offset due to packing). * [include/kernel32.h][include/windows.h][win32/*.c][loader/main.c] Merged kernel32.h into windows.h. * [misc/lstr.c] Enhanced FormatMessage(). * [misc/main.c] [if1632/kernel.spec] [include/windows.h] GetVersion() updated to new naming standard. Changed language handling to support language ids. * [misc/shell.c] Enhanced FindExecutable, so it finds files in the search path too. * [win32/environment.c] GetCommandLine* updated. * [loader/resource.c] [loader/pe_resource.c] FindResourceEx32* added. Loading of messagetables added. Language handling now uses Wine default language id.
1996-08-11 17:49:51 +02:00
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.