The Windows Message Loop: How Applications Became Reactive

Back to the 80s. Windows and the Message Loop

One of the classic examples is the Windows message loop. As a Windows 3.0 developer in the early nineties, this became embedded in my psyche. A Windows GUI application did not simply draw a window and then continue through a predefined series of instructions. It had to remain alive while the operating system delivered messages such as mouse clicks, key presses, resize events, repaint requests, timers, and shutdown notifications.

The classic code looked roughly like this:

while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}

Your application waits for a message, Windows dispatches that message into the relevant application handler, the application does some work, and then control returns to the loop. Conceptually:

What changed here was not merely the presence of a while statement. The deeper change was that the program stopped owning the entire execution lifecycle. Windows owned the outer loop, while the application supplied behavior that ran inside it. The application was now long-lived, reactive, and dependent on events it could not predict in advance. That was a very different way of thinking about execution.

Why this matters if you are building agents

This is where event-driven programming enters the mainstream, and the inversion it introduced never left. Look at any modern agent SDK and you will find the same shape: you do not write the loop; you register tools, handlers and a system prompt, and a long-lived process owned by a runtime calls them. The vocabulary changed - DispatchMessage became execute_tool - but the inversion of control did not.

The unresolved question the message loop leaves behind is the one this series is heading toward: if the runtime owns the loop, what happens to the work in flight when the runtime dies?