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!