> A quirk in the messaging system rears its head when you try to write a Windows-hosted debugger (also called a "GUI debugger"). A GUI debugger is a debugger for Windows programs that itself uses the Windows display mechanisms. What's the problem with that? Well, imagine the following scenario: A GUI debugger places a breakpoint inside of a Window procedure. Eventually, the debuggee program hits the breakpoint, and stops--and cannot call GetMessage() to yield control to other tasks! That means no other tasks--including the GUI debugger--can get their messages. The debugger can't even respond the mouse clicks that tell the debuggee to run again.
The effect still exists in some way in later version windows like the Windows Volume Mixer will freeze up or won't open if you have an application stopped at a breakpoint. I think it gets stuck waiting for a reply from something like WM_GETICON that it would have to send to top-level windows.
A single application blocked on a reply is very different from all applications halting because someone won't yield in a cooperative multitasking environment.
I would also say that anyone who sends a message to all top-level windows should use SendMessageCallback or similar so they can handle a reply asynchronously.
That’s unfortunate