Difference between revisions of "Win32k.sys"

From ReactOS Wiki
Jump to: navigation, search
m (Design)
Line 13: Line 13:
 
* Use shared desktop heap mapped into each User process. This makes perf. even better. The code interaction with the shared heap in user32.dll will only be one/two functions, so at first we may use a slow path to win32k and later when we impl. the shared heap we only change one/two funcs, like seen below:
 
* Use shared desktop heap mapped into each User process. This makes perf. even better. The code interaction with the shared heap in user32.dll will only be one/two functions, so at first we may use a slow path to win32k and later when we impl. the shared heap we only change one/two funcs, like seen below:
  
RECT GetWindowRect(hwnd)
+
  RECT GetWindowRect(hwnd)
{
+
  {
  Wnd = GetWnd(hwnd);
+
    Wnd = GetWnd(hwnd);
  return Wnd->Rect;
+
    return Wnd->Rect;
}
+
  }
  
/*initial*/
+
  /*initial*/
Wnd GetWnd(hwnd)
+
  Wnd GetWnd(hwnd)
{
+
  {
  return NtUserGetWindow(hwnd);
+
    return NtUserGetWindow(hwnd);
}
+
  }
  
/*final*/
+
  /*final*/
Wnd GetWnd(hwnd)
+
  Wnd GetWnd(hwnd)
{
+
  {
  e = LoockupHandleEntryInSharedHeap(hwnd);
+
    e = LoockupHandleEntryInSharedHeap(hwnd);
  return e->Wndptr;
+
    return e->Wndptr;
}
+
  }
  
 
* DONT use callbacks to umode! This makes programming win32k much easier since we dont have to worry about what has changed in win32k after returnig from a callback (and tons of other calls reentering win32k in the mean time).
 
* DONT use callbacks to umode! This makes programming win32k much easier since we dont have to worry about what has changed in win32k after returnig from a callback (and tons of other calls reentering win32k in the mean time).

Revision as of 08:47, 15 July 2005

Rewrite suggestions

  • A special heap manager for the objects to be stored on the (shared) desktop heaps.
  • Input processing (in progress due to i8042prt)
  • Text rendering
  • manage multiple user sessions (see terminal services)


Rewrite / reworking plan by hardon and w3seek:

  • Use one win32k.USER global read/write lock (ERESOURCE). No other lock should be used! This essentially makes win32k.USER singlethreaded. This is how Windows does it also, so the perf. should be ok.
  • Use shared desktop heap mapped into each User process. This makes perf. even better. The code interaction with the shared heap in user32.dll will only be one/two functions, so at first we may use a slow path to win32k and later when we impl. the shared heap we only change one/two funcs, like seen below:
 RECT GetWindowRect(hwnd)
 {
   Wnd = GetWnd(hwnd);
   return Wnd->Rect;
 }
 /*initial*/
 Wnd GetWnd(hwnd)
 {
   return NtUserGetWindow(hwnd);
 }
 /*final*/
 Wnd GetWnd(hwnd)
 {
    e = LoockupHandleEntryInSharedHeap(hwnd);
    return e->Wndptr;
 }
  • DONT use callbacks to umode! This makes programming win32k much easier since we dont have to worry about what has changed in win32k after returnig from a callback (and tons of other calls reentering win32k in the mean time).
  • Dont rely on Windows NtUserXxx names! Those names only pollutes our impl. and makes us think we should impl. stuff in win32k, just because a function NtUserXxx exist.
  • Move scrollbars to umode
  • <w3seek_> also one major waste of resources is that right now everytime you move the mouse or type something on your keyboard we wake _all_ waiting threads and only one gets through ;) the thread that gets through first checks who the message belongs to and moves it to the appropriate message queue and wakes that thread.