* Move the Cygwin/MSYS detection logic from config-*.mk into this new
script.
* Recognize either the 32-bit MinGW or the 32-bit MinGW-w64 compiler
driver for Cygwin.
* This avoids a name conflict with an existing unrelated project.
* I think winpty is a better name anyway. (i) It's more obviously
Windows-related. (ii) I think it more accurately describes what it
does. A "pseudo-console" ought to mirror the console API and allow
replacing the implementation built-in to Windows. This project is only
trying to provide functionality similar to using the master interface of
a Unix pty, but for native console programs.
* Work around UNICODE deficiencies:
- MSYS does not have wstring.
- mbstowcs(NULL, text, 0) returns 0 on MSYS instead of returning the
length of the converted string.
- printf("%ls") does not work on MSYS.
It doesn't work because it leaves in the Cygwin-style paths in variables
like PATH and TMP.
(Also, it doesn't build with MSYS because MSYS's old G++ toolchain lacks
std::wstring.)
I suspect that the library API (pconsole_open) should not be calling exit
if it can't start the agent process, but I don't want to deal with that
right now.
* Also propagate the UNIX environment to Win32. This code doesn't really
work because variables like PATH need path-translation, but I'd like to
save a record of it before killing it off.
* Suppress debug output unless the PCONSOLEDBG enviroment variable is
set.
* Rename Trace to trace to be consistent with the camelCaps naming
convention.
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.
