Update comments. Modified: branches/win32k rewrite attempt/win32k/docs/refs.txt _____
Modified: branches/win32k rewrite attempt/win32k/docs/refs.txt --- branches/win32k rewrite attempt/win32k/docs/refs.txt 2005-08-04 16:32:18 UTC (rev 17044) +++ branches/win32k rewrite attempt/win32k/docs/refs.txt 2005-08-04 17:49:53 UTC (rev 17045) @@ -17,6 +17,11 @@
-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 thread sharing a queue is stored in the +message queue structure and can be considered a reference count. Also on +Windows systems the a global list of thread attachments is maintained. + Above references create following dependencies: -----------------------------------------------
@@ -28,33 +33,46 @@
process -> winsta -> session
- - NtUser/NtGdi/win32k syscalls ----------------------------
-A process automatically establishes a connection to a window station and desktop -when it first calls a USER32 or GDI32 function (other than the window station or -desktop functions). The process also get a Win32Proccess. +A process and/or thread automatically gets converted to a GUI thread 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 thread is automatically assigned a desktop when it first calls a USER32 or GDI32 -function (other than the window station or desktop functions). The thread also get -a Win32Thread, a message queue and a thread input. +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.
-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: --the process WinSta --the win32process --the win32thread --the thread message queue --the thread input --the thread desktop --the process desktop (if there is such a thing) +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.
-There is no need to validate any of these values, because they MUST EXIST! +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.
- !!!!!NOTE!!!! -Reactos is currently wrong on the thread desktop, process desktop and process WinSta, -since they can be NULL!! +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!