Implement standard controls and dialogs in win32k - #15
Conversation
Brovan runs the real user32, so supporting the standard controls means supplying what win32k owes it rather than writing the controls. Button, Edit, Static, ListBox, ComboBox and ScrollBar now create, answer their own messages and send real WM_COMMAND notifications to their parent. Most of that was client-side state user32 reads without a syscall, the system class atoms, the per-DPI character dimensions dialog units convert with, the system colours and their brushes, and the per-class message tables a control checks before running its worker. While those tables read zero every message went straight to DefWindowProc, which is why nothing ever initialized. Window procedures go through user32's kernel callback table now, so NtUserCreateWindowEx sends WM_NCCREATE and WM_CREATE and carries the creation on to WM_SIZE and WM_MOVE, and NtUserMessageCall delivers a real send to the window procedure instead of answering it as DefWindowProc. Painting picks up the DC viewport origin and shifts every primitive by the window's origin inside its top level ancestor, since they all land on one host surface. Also bounds cbWndExtra at class registration, recycles user handle indexes and releases the window object when a window is destroyed, and keeps the internal visible bit out of what GWL_EXSTYLE stores.
|
@claude review |
|
Claude encountered an error after 0s —— View job I'll analyze this and get back to you. |
|
@claude review |
|
Claude finished @AdvDebug's task in 4m 8s —— View job Review: Implement standard controls and dialogs in win32k
This is a large, well-organized piece of work — routing window procedures through the real kernel callback table, driving Findings32-bit guests silently lose the whole creation handshake —
Minor / nit-level observations
Not verifiedI didn't build/run the project (no build/test instructions were available in this environment), so this review is based on static reading of the diff against |
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
1 participant
Brovan runs the real user32, so supporting the standard controls means supplying what win32k owes it rather than writing the controls. Button, Edit, Static, ListBox, ComboBox and ScrollBar now create, answer their own messages and send real WM_COMMAND notifications to their parent. Most of that was client-side state user32 reads without a syscall, the system class atoms, the per-DPI character dimensions dialog units convert with, the system colours and their brushes, and the per-class message tables a control checks before running its worker. While those tables read zero every message went straight to DefWindowProc, which is why nothing ever initialized.
Window procedures go through user32's kernel callback table now, so NtUserCreateWindowEx sends WM_NCCREATE and WM_CREATE and carries the creation on to WM_SIZE and WM_MOVE, and NtUserMessageCall delivers a real send to the window procedure instead of answering it as DefWindowProc. Painting picks up the DC viewport origin and shifts every primitive by the window's origin inside its top level ancestor, since they all land on one host surface.
Also bounds cbWndExtra at class registration, recycles user handle indexes and releases the window object when a window is destroyed, and keeps the internal visible bit out of what GWL_EXSTYLE stores.