Download: Stable · Snapshot | Docs | Changes | Wishlist
Windows Pageant's method of communicating with clients, using
WM_COPYDATA and a piece of shared memory, is absolutely
horrible. It dates from early in Win32's history, before more sensible
IPC systems were widespread.
It would be good to begin the process of replacing it with a sensible mechanism based on Windows named pipes, the same IPC mechanism that connection-sharing instances of PuTTY use to talk to each other.
Apart from the purely aesthetic 'not being disgusting' sorts of advantages, this IPC system would be an improvement on the current Pageant one in several ways:
Of course, we would have to continue supporting the old
WM_COPYDATA system in parallel for (at least) a long
time, because an unknown number of third-party clients use it. So any
new features that depend on the new IPC (as discussed above) would
have to be implemented in such a way that
clients would cope somehow.
Actually setting up the named pipe system itself should be reasonably
easy these days: named pipe IPC is fully implemented (including the
right security setup) for connection sharing, and the Pageant code has
already been restructured to involve a Plug data structure suitable
for passing straight to
of course we'd also have to endow Windows Pageant with the same kind
of main event loop PuTTY has). The client side shouldn't be any
The more interesting question would be how to support both IPC systems in one program, in the most helpful possible way. One thought I've been considering runs along the following lines:
winhandl.c, more or less exactly like PuTTY's event loop.
WM_COPYDATAclients will send their request messages to. This should (if I've correctly understood how message queues, windows and threads interact) cause the secondary thread to receive those agent requests, and the main thread to receive all other GUI activity.
WM_COPYDATArequest by opening a connection to the named pipe, just as if it was a client in a separate process. It waits for the response before replying to the message.
WM_COPYDATAclients, because the Windows message activity required to present the passphrase prompt would all happen in one thread, while the other thread was still blocked waiting to reply to the
But if that turns out not to work (e.g. perhaps there's a time limit
on how long you can delay responding to a
perhaps I've misunderstood how multiple threads' message queues
interact), then the fallback position would be to simply not present
any key to
WM_COPYDATA clients that isn't immediately
usable without user interaction.
2020-01: implemented, including moving
servicing into a subthread.