11 ms·
> 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 fo
by linux2647 7y ago
> 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.
That’s unfortunate
- asveikau 7y agoKeep in mind this is describing windows 3.x. Win95 and NT had preemptive multitasking and did not rely on calling GetMessage to yield.
- fsfod 7y agoThe 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.
- asveikau 7y agoA 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.