Martin_Dráb wrote:
Windows driver is something like a dynamic link library – the kernel just calls one of its callbacks, the driver does its job and returns the control back to the kernel.
This, I think, is one of the fundamental architectural tenets of Windows
drivers, and it is not intuitively obvious to user-mode programmers. In
user-mode programming, flow comes in at main(), and until we exit out
the bottom of main(), there’s always at least one thread that has its
program counter in our code. This is even true in a GUI app; although
we may be waiting for events, we’re waiting because we called GetMessage
and DispatchMessage.
With drivers, that’s not the case. The “steady state” for a driver is
not to have any code active at all. A driver consists of a set of
callbacks. The callbacks get fired to respond to events, either in the
system or in our hardware. The callback runs, does its work, and
returns as quickly as possible. A driver shouldn’t wait; it should
remember its state, and return until some other event triggers a change
to the next state. That’s a very different way to think about programming.