-References:\r
------------\r
-\r
-window -> desktop\r
-window -> class\r
-\r
-thread_input -> thread\r
-\r
-thread -> process\r
-process -> winsta\r
-thread -> desktop\r
-desktop -> winsta\r
-winsta -> session\r
-\r
-NOTE: Message queue has 1:1 relationship with (w32)thread and need no ref. count.\r
- -If the (w32)thread is destroyed, so is the message queue.\r
- -If the (w32)thread exist, so does the message queue.\r
- So if you want the queue to hang around, you reference the thread instead.\r
-\r
-^ This is wrong, one can attach message queue to different thread using\r
-AttachThreadInput. The number of threads sharing a queue is stored in the\r
-message queue structure and can be considered a reference count. Also on\r
-Windows systems there is maintained a global list of thread attachments.\r
-\r
-Above references create following dependencies:\r
------------------------------------------------\r
-\r
-window -> desktop -> winsta -> session\r
-window -> class\r
-\r
-thread -> process -> winsta -> session\r
-thread -> desktop -> winsta -> session\r
-\r
-process -> winsta -> session\r
-\r
-NtUser/NtGdi/win32k syscalls\r
-----------------------------\r
-\r
-A process and/or thread automatically gets converted to a GUI thread /\r
-process when the first syscall from the shadow service table is called (ie.\r
-any NtUser* or NtGdi* call). GUI threads have bigger kernel stack (FIXME:\r
-not the case on ReactOS yet) and have associated storage for the Win32\r
-structures. The conversion itself happens in the syscall handler and the\r
-win32k callbacks (registered with PsEstablishWin32Callouts) are called\r
-accordingly.\r
-\r
-A process automatically establishes a connection to a window station on the\r
-GUI thread conversion. The Win32 process initialization callback routine\r
-also creates and initializes the W32PROCESS structure and associates it with\r
-the process.\r
-\r
-Similary for thread the callback routine automatically assigns a desktop\r
-when the thread is converted to GUI thread. The thread also gets a W32THREAD\r
-structure, a message queue and a thread input structures.\r
-\r
-Beware that there is an exception to these rules and that's WinLogon. Since\r
-at the time the process starts no window stations or desktops exist, none\r
-are assigned to the the initial thread / process. The first Win32k calls\r
-the thread does are to create the window station and desktop and to associate\r
-them with itself.\r
-\r
-FIXME: At the time of this writing there's a second exception, a "primitive\r
-message queue" thread in CSRSS that is created before any window stations\r
-exist and is used to capture keyboard input in console mode. Eventually we\r
-should get rid of it and replace is with hidden window w/ focus or something\r
-similar.\r
-\r
-Generally this means that when you are in a Win32k syscall function (other\r
-than the window station or desktop functions) you can be 100% sure that the\r
-following exists:\r
-\r
-- Process window station\r
-- Win32 process structure\r
-- Win32 thread structure\r
-- Thread message queue\r
-- Thread input\r
-- Thread desktop\r
-\r
-There is no need to validate any of these values, because they MUST EXIST!\r
+References:
+-----------
+
+window -> desktop
+window -> class
+
+thread_input -> thread
+
+thread -> process
+process -> winsta
+thread -> desktop
+desktop -> winsta
+winsta -> session
+
+NOTE: Message queue has 1:1 relationship with (w32)thread and need no ref. count.
+ -If the (w32)thread is destroyed, so is the message queue.
+ -If the (w32)thread exist, so does the message queue.
+ So if you want the queue to hang around, you reference the thread instead.
+
+^ This is wrong, one can attach message queue to different thread using
+AttachThreadInput. The number of threads sharing a queue is stored in the
+message queue structure and can be considered a reference count. Also on
+Windows systems there is maintained a global list of thread attachments.
+
+Above references create following dependencies:
+-----------------------------------------------
+
+window -> desktop -> winsta -> session
+window -> class
+
+thread -> process -> winsta -> session
+thread -> desktop -> winsta -> session
+
+process -> winsta -> session
+
+NtUser/NtGdi/win32k syscalls
+----------------------------
+
+A process and/or thread automatically gets converted to a GUI thread /
+process when the first syscall from the shadow service table is called (ie.
+any NtUser* or NtGdi* call). GUI threads have bigger kernel stack (FIXME:
+not the case on ReactOS yet) and have associated storage for the Win32
+structures. The conversion itself happens in the syscall handler and the
+win32k callbacks (registered with PsEstablishWin32Callouts) are called
+accordingly.
+
+A process automatically establishes a connection to a window station on the
+GUI thread conversion. The Win32 process initialization callback routine
+also creates and initializes the W32PROCESS structure and associates it with
+the process.
+
+Similary for thread the callback routine automatically assigns a desktop
+when the thread is converted to GUI thread. The thread also gets a W32THREAD
+structure, a message queue and a thread input structures.
+
+Beware that there is an exception to these rules and that's WinLogon. Since
+at the time the process starts no window stations or desktops exist, none
+are assigned to the the initial thread / process. The first Win32k calls
+the thread does are to create the window station and desktop and to associate
+them with itself.
+
+FIXME: At the time of this writing there's a second exception, a "primitive
+message queue" thread in CSRSS that is created before any window stations
+exist and is used to capture keyboard input in console mode. Eventually we
+should get rid of it and replace is with hidden window w/ focus or something
+similar.
+
+Generally this means that when you are in a Win32k syscall function (other
+than the window station or desktop functions) you can be 100% sure that the
+following exists:
+
+- Process window station
+- Win32 process structure
+- Win32 thread structure
+- Thread message queue
+- Thread input
+- Thread desktop
+
+There is no need to validate any of these values, because they MUST EXIST!
projects / reactos.git / blobdiff