Re: [ros-dev] [ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation

[James Tabor]

Hi!
BTW, I found my old notes again. 8^)

After some research over the years, I found out there are up to 8 or more
WndProc atom classes registered in win32k and not user32.

Integer Atoms:
#define POPUPMENU_CLASS_ATOM MAKEINTATOM(32768)  /* PopupMenu */ Reg in W32k
#define DESKTOP_CLASS_ATOM   MAKEINTATOM(32769)  /* Desktop */   Reg in W32k
#define DIALOG_CLASS_ATOM    MAKEINTATOM(32770)  /* Dialog */    Reg in User32
#define WINSWITCH_CLASS_ATOM MAKEINTATOM(32771)  /* WinSwitch */ Reg in W32k
#define ICONTITLE_CLASS_ATOM MAKEINTATOM(32772)  /* IconTitle */ Reg in W32k

#define TOOLTIP_CLASS_ATOM MAKEINTATOM(32774) Reg in W32k

String Atoms:
"ScrollBar", "Message", and something called "DDEMLEvent"
for WM_DDEMLEVENT.

The one that we are looking into fixing "ScrollBar", The controls are in
win32k and not in User32.

I noticed WndProc messages originate from win32k too. The window thread is
locked and then the message is sent out.

Example: Function call User32 -> Win32k -> send message.

Maybe we are doing double the work when we scroll on a bar. The rapid
blinking of the bar too. We maybe sending more than one message out.

Example: Win32k send message, then in the loop, user32 sends the same message
back into Win32k we go and loop again, wow!

We have scroll controls in user32 and we are controlling the scrolling from
win32k. It just look so messy!

So~

Once Gdi/Win32k is at a state of normality and acting like it should. We need
to setup a game plan for User/Win32k.

1. Map View the Wnd handle table and Wnd objects to user process space
   (readonly), like gdi.
    a. This will allow user space to read the table and read the WINDOW_OBJECT.
2. Migrate the above atom classes and controls to win32k.
3. Add more. .. ....
4. Fix bugs.
5. Get paid!

Thanks,
James

http://wiki.winprog.org/wiki/Windows_messages
http://msdn2.microsoft.com/en-us/library/ms997511.aspx