PuTTY bug scrollbar-sub-message-loop

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
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:

• Anything triggered on a timer within PuTTY, such as a flashing cursor, or sending pings to the server.
• Anything triggered by reading data from a Windows HANDLE (e.g. a serial port or named pipe).
• Anything for which PuTTY's implementation strategy involves scheduling a callback to be run from the top-level event loop (typically to avoid complicated re-entrancy bugs).

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 from DefWindowProc's default handler for the WM_SYSCOMMAND/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 WM_SCROLL/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!