[navaraf] 17045: Update comments.

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!