Terminals output these codes under various circumstances:
* rxvt-unicode: numpad, hold down SHIFT
* rxvt: numpad, by default
* xterm: numpad, after enabling app-mode using DECPAM (`ESC =`). xterm
generates `ESC O <mod> <letter>` for modified numpad presses,
necessitating kBareMod.
* mintty: by combining Ctrl with various keys such as '1' or ','.
Handling those keys is difficult, because mintty is generating the
same sequence for Ctrl-1 and Ctrl-NumPadEnd -- should the virtualKey
be '1' or VK_HOME?
The intent is to make it easier to determine how Windows creates KEY_EVENT
records. The code lives in winpty-agent because (1) it's very small, and
(2) I can't test all the interesting keyboards/locales/etc, so if
someone hits a bug, placing it in winpty-agent.exe ensures that they'll
have access to the tools needed to debug it.
* I don't anticipate caring about this, but in principle, there's nothing
wrong with a NUL character in the input map, so fix this while the code
is fresh in my mind.
* Remove these characters from the input map and handle them via the
ordinary <Char> and Alt-<Char> code paths.
* Refactor lookupKey to remove the isEof parameter.
* Ctrl-2 (^@) is encoded as a NUL byte.
* Instead of looking for a NUL byte, we need to check the input size.
Places affected: scanKeyPress, matchDsr, lookupKey
* N.B.: putty and rxvt encode Ctrl-Alt-2 as `ESC NUL`.
Previously, after inputting a NUL using Ctrl-2, one could type an arbitrary
amount of input into the input buffer, and winpty wouldn't do anything
until 1-second inactivity timeout had expired. (i.e. It thought it was
seeing an incomplete DSR, so it kept waiting for the DSR to complete.)
* ^[O is Shift-Alt-O, not Alt-O. Alt-O is ^[o
* '[' is not a valid virtualkey. It's typically VK_OEM_4 on a US
keyboard, but it needs to be looked up dynamically.
* The unicodeChar fields should be 'O' and '[', not NUL.
* Add a --showkey argument to the unix adapter.
My Ubuntu machine has a nice showkey -a utility that dumps keys, but I
can't find something similar for Cygwin/MSYS. It's a very useful tool
for debugging UNIX terminal interoperability, so add it to the unix
adapter.
* Add WINPTY_DEBUG=input to log input bytes and console key events.
* Remove GIT_REVPARSE_WORKS, which is never used
* Rename the shell variables {UNIX,MINGW}_GPP to {UNIX,MINGW}_CXX to
match the config.mk variable names.
There is a "version suffix" that defaults to "-dev". A maintainer could
change the suffix (or remove it) by invoking make:
make BUILD_SUFFIX=-foo
make BUILD_SUFFIX=
It can also be changed in gyp builds:
gyp winpty.gyp --depth=1 -D BUILD_SUFFIX=-foo
gyp winpty.gyp --depth=1 -D BUILD_SUFFIX=
If git cannot be executed, the string "none" is used for the commit hash.
* This change reduces the total build time from about 14 seconds to about
9 seconds on my computer.
Also:
* Consolidate all the intermediate files into the build directory to
reduces clutter.
* Allow specifying UNIX_ADAPTER_EXE to make. Perhaps this will be helpful
to the MSYS2 fork, which renames console.exe to winpty.exe. (I like
the renaming, but I don't know about the other winpty users. Maybe
I'll make the change after I've put out another stable release...)
* Rename the WINPTY define to COMPILING_WINPTY_DLL define. The longer
name is clearer. I define the macro inside libwinpty/winpty.cc, so the
build system no longer needs to. (I removed the define from
winpty.gyp.)
* Consolidate config-unix.mk and config-mingw.mk into config.mk. The
separation was previously necessary because each file had a conflicting
definition of CXX.
* Rename the UNIX_LDFLAGS_STATIC_LIBSTDCXX macro to UNIX_LDFLAGS_STATIC,
because libstdc++ isn't the only thing I'm linking statically.
I think it might be possible for m_dirtyLineCount to be greater than the
windowRect.top() + windowRect.height(). If it is, then scanForDirtyLines
will perform an invalid read while trying to initialize prevLineAttr.
Also add agent/EventLoop.h. I don't know why it wasn't listed.
With these changes, gyp no longer complains about missing files.
Unfortunately I can't do more testing at the moment.
This commit might fix issue https://github.com/rprichard/winpty/issues/55.
Prior to Windows 7, the undocumented NtQuerySystemInformation API did
not return valid handle information when called by a WOW64 process. To
work around this problem, the 32-bit test program connects to a 64-bit
worker and uses the existing RPC mechanism, issuing LookupKernelObject
commands, which call NtQuerySystemInformation in a native 64-bit
environment.
Even on Windows 7, the NtQuerySystemInformation API returns truncated
kernel object pointers, so, AFAIK, we still need to do this work. Maybe
not, though, if the lower 32 bits are guaranteed to be unique.
On Windows 10, there is a CompareObjectHandles API that works in WOW64
mode.
It seems that this bug was fixed in WOW64 prior to its fixing in the
normal environment.
It makes no sense to run Test_CreateProcess_Duplicate_PseudoHandleBug_IL
on OS's that don't have inherit lists.
