This is useful when winpty-agent is invoked from the Win32-OpenSSH server,
which uses a proper console for STDIN, but sockets(!) for STDOUT and
STDERR. The C++ runtime uses block buffering on the socket output, so
flush explicitly.
gyp tolerates all of:
'user32'
'user32.lib'
'-luser32'
'-luser32.lib'
With the --format=make generator, the exact string value is passed to gcc,
which only accepts the '-luser32' syntax. The MSVC generator is also
happy with this format, so that's what I'll use.
With this change, it's possible to use the gyp file to build the C++
components. I'm not sure if that's useful, but why not? The resulting
Makefile can be configured by passing settings like CXX and LDFLAGS on the
make command-line.
Also: document use of gyp a bit.
* Add a src/configurations.gypi file that can be included on the gyp
command-line to enable 32-bit and 64-bit builds in the generated project
files.
* Make winpty.gyp work if gyp is run with Cygwin python. It still works
with normal python.
* Explicitly call the Unicode versions of various APIs
* Add const in a couple of places
* Improve a few assert error messages
* Either initialize BackgroundDesktop fully or leave all its fields NULL
* winpty-agent: Respect the ENABLE_QUICK_EDIT_MODE flag. If it's set,
then mouse events are not generated (because they're supposed to control
selection).
* winpty-agent: Because of the above, turn ENABLE_QUICK_EDIT_MODE off at
startup.
* winpty-agent --show-input: Enable ENABLE_WINDOW_INPUT so we can see
buffer resize events.
* winpty-agent --show-input: Disable ENABLE_QUICK_EDIT_MODE with
--with-mouse. When Quick Edit mode is enabled, the mouse controls
selection and does not produce mouse events in the input queue.
Details:
* Rename --showkey to --show-input and dump everything *except* mouse
input.
* Add a mode, --show-input --with-mouse, that also dumps the mouse
input.
Now that the InputHandler thread blocks with select, in addition to the
main thread that also blocks with select, winpty has hit a bug in the
original MSYS where select returns EAGAIN. select is not supposed to fail
with that error (EAGAIN doesn't make much sense as a select error). Add
a workaround just for the original MSYS.
Explicitly shut down the I/O handling threads before restoring the terminal
state. Start calling winpty_close.
This change doesn't fix any bug, AFAIK. It's nice to test/demonstrate the
use of winpty_close.
The InputHandler now uses select to wait on both the blocking stdin tty and
a wakeup fd. This is the same behavior I saw in OpenSSH. OpenSSH sets
its select FDs to O_NONBLOCK *except* FDs for which isatty returns true.
It puts tty FDs into raw mode, but it does not set VMIN/VTIME to 0/0, so
the terminal driver blocks. (In any case, I tested the 0/0 values, and
IIRC they prevented blocking only with a Cygwin emulated pty -- console FDs
in Cygwin blocked; as did both consoles and emulated ptys in the original,
old MSYS. O_NONBLOCK prevented blocking in all cases, though.)
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.
