How windows OS processes input events?
The way i understand it right now is that whenever you move the mouse or hit a keyboard, that event passes through a raw input thread, then gets stored in a system message queue (where all messages, like WM_PAINT are stored), then passes through a message-specific chain of hook procedures before finally arriving at the window-specific message queue that winforms gets messages from.
Am i correct in this and where could i find more info on it?
17 Replies
im not sure what you mean by "passes through a raw input thread", theres not "global" raw input thread that processes input or anything
the driver notifies the kernel when it recieves input
theres the raw input api, which you register a window for which recieves WM_INPUT messages
it needs a window, not just a thread
but there are also the legacy/"standard" input messages like WM_KEYDOWN and the rest
there are plenty of docs on this on ms learn
I dont know why ur going around rather than asking the actual question... but I feel you're looking for this maybe? https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.control.wndproc?view=windowsdesktop-9.0
Control.WndProc(Message) Method (System.Windows.Forms)
Processes Windows messages.
WndProc more specifically
not exactly
thats just the windows procedure docs
not u, him
i know
yes my point is that given the vagueness of his message I feel he is looking for that override.
theyre looking for how windows the OS handles input, not "app windows" windows
$xy
Every window has its own message queue and Windows will turn events from the relevant device driver in kernel mode into messages that get posted to the the queue for the appropriate window (e.g., the one the mouse is currently interacting with.)
There is some info here that might help:
https://learn.microsoft.com/en-us/windows/win32/winmsg/about-messages-and-message-queues?utm_source=chatgpt.com
About Messages and Message Queues - Win32 apps
This section discusses Windows messages and message queues.
Your specific question seems likely addressed by this section:
The system can display any number of windows at a time. To route mouse and keyboard input to the appropriate window, the system uses message queues. The system maintains a single system message queue and one thread-specific message queue for each GUI thread. To avoid the overhead of creating a message queue for non–GUI threads, all threads are created initially without a message queue. The system creates a thread-specific message queue only when the thread makes its first call to one of the specific user functions; no GUI function calls result in the creation of a message queue. Whenever the user moves the mouse, clicks the mouse buttons, or types on the keyboard, the device driver for the mouse or keyboard converts the input into messages and places them in the system message queue. The system removes the messages, one at a time, from the system message queue, examines them to determine the destination window, and then posts them to the message queue of the thread that created the destination window. A thread's message queue receives all mouse and keyboard messages for the windows created by the thread. The thread removes messages from its queue and directs the system to send them to the appropriate window procedure for processing.
I'm sorry for the vagueness of my question, it's because i don't understand the topic clearly.
What i want to know is a general overview of the logical "path" a keyboard input takes all the way from the device to a specific window's message queue
right, there's a single system message queue and one thread specific message queue for each gui thread.
So I'm guessing between the system queue and a thread-specific queue stand the hook procedures, which act as a filter of input messages?
but then how does this filter work, will a slow, stuttery filter block EVERY message of the system queue?
Hooks are explained here.
https://learn.microsoft.com/en-us/windows/win32/winmsg/about-hooks
Hooks Overview - Win32 apps
This topic discusses how hooks should be used.
if i have a hook procedure with a Thread.Sleep(300); instruction on it, will the whole system fail to dispatch messages to every thread-specific message queue?
I would suggest reading this documentation in detail. Or maybe someone else can comment (I don't really do Win32 programming.)
As far as I know hooks are thread-specific, but if you pass 0 for the thread id you are going to affect all existing threads. Which would be terrible in the scenario you outlined I think.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa
SetWindowsHookExA function (winuser.h) - Win32 apps
Installs an application-defined hook procedure into a hook chain. (ANSI)
when registering an actual hook it can block or lag the flow of input to message queues. for raw input you can register without a window iirc but uses pretty much the same queue mechanism