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.
* Remove most of the encoding table and instead generate the KeyDescriptor
entries dynamically at startup.
* I think I'm handling input tolerably well for TERM=xterm terminals, but
I removed the support I had for rxvt for now. I don't think it makes
sense to fill out the table, but the new code I have for TERM=xterm is
also bloated.
* If bytes are still queued after processing as many keypresses as
possible, send a DSR to the console. The console should respond with
a DSR reply, which will flush out the input buffer without having to
wait for a timeout.
* Add ah hoc code for ALT-<character> rather than listing every character
in the table.
* When keypresses have Alt/Ctrl/Shift modifiers, generate extra
INPUT_RECORDS to press and release each modifier. EDIT.COM seemed to
require these for some Ctrl-<key> keypresses I tried.
* Generate Ctrl-C events by calling GenerateConsoleCtrlEvent.
I noticed that calls to this routine don't behave exactly the same as
a real Ctrl-C keypress. In Python, pressing Ctrl-C immediately
displays a new "KeyboardInterrupt" line. Calling
GenerateConsoleCtrlEvent has no immediate effect, but after pressing
Enter, Python displays a stack trace where a KeyboardInterrupt was
raised. After some testing, I suspect the issue is that a real Ctrl-C
keypress interrupts a blocking console read, but
GenerateConsoleCtrlEvent does not.
I also tried synthesizing Ctrl-C using (a) PostMessage with
WM_{CHAR,KEYDOWN}, and (b) SendInput. I couldn't get either to work.
* Recognize ESC sequences. The set of recognized sequences is ad hoc.
* Recognize UTF-8-encoded characters and convert them to UTF-16.
* The code currently uses a timeout to differentiate between pressing ESC
and pressing a key that generates an ESC sequence. I have a theory that
I can use the "Device Status Report" ESC sequences to avoid this
timeout.
* Assume that either:
- The console has a white-on-black color scheme. This could be set
at agent startup.
- The remote terminal also has a white-on-black color scheme, OR...
- With a different color scheme, the white/black colors could be
reversed, but the console is still usable.
* The COMMON_LVB_REVERSE_VIDEO flag apparently has no effect in a Windows
console, so ignore it in the agent too.
* Start handling Unicode characters. I noticed that box drawing
characters (mc.exe / edit.com) are displayed correctly now. I'm calling
WideCharToMultiByte once per character, though, and I'm wondering if
this is inefficient.
Before the Qt removal, Terminal::finishOutput accepted a QPoint object with
a 32-bit line number. Changing it to accept Coord introduced a bug because
the Coord line number is only 16-bits. The moveTerminalToLine and sendLine
methods still accepted a 32-bit line number, though.
The result was, after 32768 lines of output, the
Terminal::moveTerminalToLine function would be called alternately with
truncated and untruncated line numbers (e.g. -32000 and 33536), and the
function would generate massive amounts of "cursor up" and "newline"
output.
* Replace Buffer::isEof with Buffer::eof so I can use the agent-specific
ASSERT macro instead of the standard assert().
* If an API call in Win32Console fails, print a message using Trace.
* Add Coord::toString and SmallRect::toString functions.
* Replace QPoint and QSize with Coord, a C++ class derived from COORD.
* Replace QRect with SmallRect, a C++ class derived from SMALL_RECT.
* Turn Win32Console into a non-QObject class.
- In my MSYS environment, gcc/g++ are the MinGW compilers that target
Win32. We really need compilers that target the MSYS environment.
Add a config-unix.mk for building the unix-adapter.
- My MSYS environment lacks a pipe2 function, but I can get the same
effect using pipe and fcntl, so do that instead.
- 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.
size_t wouldn't really be a reasonable type for Windows I/O because
ReadFile and WriteFile use a DWORD for byte counts. A single I/O operation
of more than 2GB seems unreasonable anyway.
agent.
* The code is based on that from AgentClient.cc, but without the Qt
dependency.
* The API currently uses blocking I/O. The intent is for users to use
a separate read thread and write thread.
