* Quoting is needed for empty arguments (i.e. put double-quotes in the
command line) and for arguments containing tabs because both spaces and
tabs can separate arguments.
* A double-quote in the argument doesn't by itself necessitate quoting.
* As of this change, argvToCommandLine quotes an argument in the same
cases as Python's subprocess module.
If I run a GUI program inside mintty using winpty, the GUI's window should
appear on the same desktop as mintty, not on the hidden desktop containing
the winpty console.
Even though STARTUPINFO.lpDesktop's type is LPTSTR (instead of LPCTSTR),
the documentation doesn't say anything about CreateProcess modifying the
lpDesktop string, so I didn't bother making a copy of desktop.c_str().
This lets libwinpty.dll read the WINPTYDBG environment variable that the
unix adapter sets using SetEnvironmentVariable. If DebugClient.cc calls
getenv, then it seems to read a copy of the Win32 environment that the
MSVCRT initializes at startup.
The latter doesn't work when:
* I'm using mintty.
* I invoke python.exe directly, passing it the path to the script.
This came up on Windows XP testing where I installed CPython, but
python.exe wasn't in my PATH, so I couldn't run the script directly.
* The intent of having the length variable was to avoid sending trailing
whitespace for each line, but the previous code never read the variable.
Instead, every line it sent was the width of the terminal window.
* There was a bug where running console.exe inside a TERM=cygwin terminal
resulted in excessive line feeds. This change mitigates that bug, but
doesn't fix it. The problem is that the agent assumes that after it
writes to the last column of a line, the cursor is still on the same
line, but this isn't true for the TERM=cygwin terminal.
* 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.
