Difference between revisions of "Win32k.sys"
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); | |
− | + | return Wnd->Rect; | |
− | } | + | } |
− | /*initial*/ | + | /*initial*/ |
− | Wnd GetWnd(hwnd) | + | Wnd GetWnd(hwnd) |
− | { | + | { |
− | + | return NtUserGetWindow(hwnd); | |
− | } | + | } |
− | /*final*/ | + | /*final*/ |
− | Wnd GetWnd(hwnd) | + | 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 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.