The goal is to setup pipes between the libpconsole process and the new
agent process in a way that's secure and doesn't create an unnecessary
burden on the library's user. This is apparently hard.
I think this code is good enough.
If we couldn't create the new pipes, then perhaps some other process has
already created them. I think it's a security hole to start the agent if
the pipe creation failed.
- In the agent, poll for the process exit at the same time we pull for
output. Once the child exits, record the exit code and close the data
pipe.
- In the unix-adapter, shut the program down once the input or output
handlers abort. Before exiting, query the agent for the exit code.
- Also: in the unix-adapter, apparently receiving the SIGWINCH signal can
interrupt both select and the InputHandler's read system call. I hope
it doesn't affect the blocking Win32 APIs, but I'm not really sure.
- Update the Agent to use separate control and data pipes and to receive
arbitrary-sized packets. Handle child process creation in the agent.
- Fix bugs in libpconsole:
- Insert a space between the pipe names on the agent command line.
- Don't close the desktop and window station until after connecting
to the agent's pipes.
- Change the format of the pconsole_start_process env parameter from an
array of wide-character-string pointers to a single contiguous block of
memory, like that accepted by CreateProcess.
* Remove obsolete comments and APIs.
* In pconsole.exe, use two threads to handle pconsole<->pty communication.
I use blocking I/O for the pty. For the Win32 pipe to the pconsole
agent, I use overlapped I/O and emulate blocking I/O.
I'm not sure I *have* to open the pipe in overlapped mode. When I last
tried using non-overlapped I/O, I had a problem where a pending read
would block writes (or vice versa). Maybe setting the overlapped
parameter to {Read,Write}File would be sufficient.
My plan now is to integrate the PseudoConsole with Cygwin and MSYS ptys,
with initial focus on Cygwin. I think I'll keep the separate Agent and DLL
binaries, and they'll continue to be native Win32 binaries. I don't want
to have two build systems (qmake vs whatever MSYS/Cygwin uses), and since
I'd like to remove the Qt dependency anyway, I'm trying to switch to
makefiles.
