By default, winpty now puts a new console into QuickEdit mode. If the
agents detects that the console has disabled QuickEdit and enabled
ENABLE_MOUSE_INPUT, then it puts the terminal into mouse mode.
This convention doesn't work with all Windows programs -- it does work
with Far Manager and "winpty-agent.exe --show-input --with-mouse". The
practice is described in one of Raymond Chen's posts[1].
For other programs, winpty.exe still has a --mouse option, and I wrote a
script in misc/ConinMode.ps1 that controls the QuickEdit (and InsertMode)
flags from the command-line, which is useful, because the console
properties dialog is inaccessible from within winpty.
[1] https://blogs.msdn.microsoft.com/oldnewthing/20130506-00/?p=4453
Calling SetProcessWindowStation in winpty_open isn't thread-safe -- another
thread may be doing something with the window station. The call also
appears to interfere with the clipboard, which has affected IntelliJ.
A previous commit disabled the use of the background desktop for Windows 7
and up, where it seems unnecessary. This commit fixes the issue for XP
and Vista by spawning the agent twice in winpty_open:
1. winpty_open first spawns an agent with no attached console, which
creates the background desktop and sends its name back on the control
pipe.
2. Then it spawns the primary agent invocation as usual.
3. Once the primary agent's control pipe is connected, winty_open allows
the first agent to exit.
Fixes https://github.com/rprichard/winpty/issues/58
The new API improves upon the old API in a number of ways:
* The old API provided a single data pipe for input and output, and it
provided the pipe in the form of a HANDLE opened with
FILE_FLAG_OVERLAPPED. Using a bare HANDLE is difficult in higher-level
languages, and overlapped/asynchronous I/O is hard to get right.
winpty_close closed the data pipe, which also didn't help things, though
I think the handle could have been duplicated.
Using a single handle for input and output complicates shutdown. When
the child process exits, the agent scrapes the final output, then closes
the data pipe once its written. It's possible that a winpty client will
first detect the closed pipe when it's writing *input* rather than
reading output, which seems wrong. (On the other hand, the agent
doesn't implement "backpressure" for either input or output (yet), and
if it did, it's possible that post-exit shutdown should interrupt a
blocked write into the console input queue. I need to think about it
more.)
The new API splits the data pipe into CONIN and CONOUT pipes, which are
accessed by filename. After `winpty_open` returns, the client queries
pipe names using `winpty_conin_name` and `winpty_conout_name`, then
opens them using any mechanism, low-level or high-level, blocking or
overlapped.
* The old libwinpty handled errors by killing the process. The new
libwinpty uses C++ exceptions internally and translates exceptions at
API boundaries using:
- a boolean error result (e.g. BOOL, NULL-vs-non-NULL)
- a potentially heap-allocated winpty_error_t object returned via an
optional winpty_error_ptr_t parameter. That parameter can be NULL.
If it isn't, then an error code and message can be queried from the
error object. The winpty_error_t object must be freed with
winpty_error_free.
* winpty_start_process is renamed to winpty_spawn. winpty_open and
winpty_spawn accept a "config" object which holds parameters. New
configuration options can be added without disturbing the source or
binary API.
* The winpty_get_exit_code and winpty_get_process_id APIs are removed.
The winpty_spawn function has an out parameter providing the child's
process and thread HANDLEs (duplicated from the agent via
DuplicateHandle). The winpty client can call GetExitCodeProcess and
GetProcessId (as well as the WaitForXXX APIs to wait for child exit).
My motivation at the moment is that I'm trying to share a
git checkout between multiple VMs using VirtualBox's Shared
Folders feature. git in the guest VM isn't able to see the
executable bits from the host due to the VirtualBox/SMB/CIFS
layer. Instead, it thinks text files are non-executable,
unless they have a shebang line. That's a sensible way to
set the flags anyway, so set them like that.
With this commit, there's still one file that isn't handled:
src/shared/GetCommitHash.cmd. It's still marked executable,
but it lacks a shebang line, so the guest thinks it's
non-executable. I'm not sure it should be changed.
There are three reasons for this change:
* It's consistent with MSYS2, which already renamed console.exe to
winpty.exe.
* winpty.exe is less likely to clash with another program.
* winpty.exe is easier to search for online. If someone unfamiliar with
winpty is asked to run console.exe, they might have a hard time figuring
out where console.exe comes from.
The old behavior can be restored by passing UNIX_ADAPTER_EXE=console.exe
to `make`, or by simply renaming the binary after-the-fact, or with
`alias`, etc.
* ^[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.
