Bulgarian mirror 10 Gbps

PuTTY bug win-message-loop

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

Windows PuTTY launches many of its dialog boxes using modal Windows API functions (DialogBox, DialogBoxParam, GetSaveFileName, MessageBox and so on) which do not return until the dialog box has been closed by the user. Windows implements these functions by running its own message loop, since it can't return to the application's top-level message loop.

Unfortunately, PuTTY's top-level message loop does important things other than fetching and dispatching window messages. In particular, it calls enact_pending_netevent, which is what actually does the work of responding to incoming data on network connections. So it would be better not to delegate to a subsidiary message loop we don't control.

For the dialog box types we invented ourselves, such as the Change Settings and About boxes, this requires only a structural change to make the Windows front end slightly more event-driven than it already is: we should launch the dialog box using CreateDialog rather than DialogBox, return to the main PuTTY message loop, and when the user closes the dialog box we should enact whatever change they requested (if any). For example, the current handler for IDM_RECONF would stop at the point where it calls do_reconfig, and all the subsequent code would move out into a window message handler for whatever message indicates the closing of the reconfiguration box. This won't necessarily be easy in every case (and will also require some state-tracking to ensure we don't open an endless series of reconfiguration boxes in parallel if the user selects Change Settings a second time), but it's probably feasible.

For Windows standard dialogs such as the load and save file ones, however, there isn't a comparably easy solution that I know of. GetOpenFileName and GetSaveFileName don't have non-modal equivalents that I know of, and as far as I can see neither do the horrible modern replacements based on IFileDialog. So it might be difficult to use our top-level message loop while one of those dialog boxes is active. (Unless running modal dialog API functions in a separate thread does what you want, perhaps? I currently have no idea whether that would work, though.)