Download: Stable · Snapshot | Docs | Changes | Wishlist
On Windows PuTTY, if you click on the terminal's scrollbar thumb and start dragging it interactively, then while you're performing that drag operation, PuTTY does not respond to various types of event:
HANDLE(e.g. a serial port or named pipe).
All of those types of event are handled by PuTTY's top-level
message loop, which is much more complicated than a simple loop on
GetMessage: instead, it calls
MsgWaitForMultipleObjects to watch file handles and event
objects as well as window messages, and it sets the timeout on that
call to handle timers.
But Windows's handling for an interactive drag of that scrollbar
works by running a subsidiary Windows message loop that lasts for the
duration of the drag. And that subsidiary message loop doesn't contain
any of that extra complexity: it does just loop round on
GetMessage, so all those other types of event are ignored
until the interactive drag has finished.
I list this bug at 'mayhem' difficulty because there's not really
any way to get round it, that I can see. The sub-message-loop (called
DefWindowProc's default handler for the
SC_VSCROLL message sent at the
start of the drag) is the only thing in the Windows GUI
implementation that knows the right way to translate mouse motion
events during the drag into the
SB_THUMBTRACK window messages that
tell you where to actually scroll to. So your choices are to let
Windows run its sub-message-loop, or else reimplement that whole piece
of GUI functionality completely by hand, and of course, you've got no
chance of getting it all right.
Another option would be to make PuTTY a fundamentally multithreaded program, so that the window message loop could run in one thread and the handlers for other kinds of event could run in another. But PuTTY has had 25 years of being an essentially single-threaded code base (it does have sub-threads but they do extremely small jobs carefully separated from the main code), and converting it into something concurrency-safe at this late date would be tantamount to a rewrite from scratch!