-Xallow-non-tty: allow stdin/stdout to not be ttys
-Xconerr: test the new CONERR mode (connect it to STDERR_FILENO)
-Xplain: enter plain, unescaped, mode
-Xcolor: force generation of color escapes, even with -Xplain
Also: with "winpty.exe --showkey", stop trying to put stdout into raw
terminal mode, and ignore whether it is a tty.
If the WINPTY_FLAG_CONERR flag is specified when starting the agent, the
agent creates a separate, inactive console buffer to use for collecting
error output. The buffer is passed to children using
STARTUPINFO.hStdError. The agent scrapes from both the initial STDOUT
screen buffer and the new error buffer using two Scraper objects, two
Terminal objects, and two NamedPipe objects.
Clients connect to the CONERR pipe just as they would connect to the CONOUT
pipe. There is a winpty_conerr_name function for querying the CONERR
pipe's name.
Console frozenness is a property of the entire console, rather than a
screen buffer, so it is consolidated into the Win32Console class. During a
typical output poll, the console is frozen, then both buffers are scraped,
then the console is unfrozen.
Related: previously CONOUT$ was reopening at each poll timeout. Now, the
buffer is only open for the duration is is needed. (i.e. It is closed at
the end of the resizing/scraping operation.) This new behavior might be
more correct in scenarios where programs change the active screen buffer.
If a program activates its own screen buffer, then exits, the screen buffer
is destroyed because no program references it. When it is destroyed, a
different buffer is activated. By opening CONOUT$, winpty can accidentally
prevent a screen buffer from being destroyed, at least temporarily.
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.
So far, I've only tested it on Windows 7. The test passed on that OS:
creating a screen buffer isn't blocked by selection, but writing to an
inactive buffer *is* blocked, regardless of whether the buffer was created
before or after selection began. The use of Mark or SelectAll doesn't
affect behavior.
If we're only examining the table for debugging purposes, then read only
first 1000 fonts and dump them.
If we're reading the font table on XP, then use the undocumented
GetNumberOfConsoleFonts API. Avoid this API on Vista and up, because it's
undocumented. It ought to be stable enough on XP.
When ConEmu has adopted the agent console (e.g. there is a ConEmu tab for
the agent's console), then every font in the table will have the same size.
(For now, anyway. Obviously, the ConEmu author may decide to change the
behavior.)
When `WINPTY_SHOW_CONSOLE=1` is set, and when ConEmu's "Process 'start'"
flag is set, ConEmu will still adopt the winpty-agent console. It seems
that this case is still broken (on Vista and up), because winpty.dll
notices that its pipe clients have the wrong PID. I'm not sure what to do
about this. `WINPTY_SHOW_CONSOLE=1` is strictly intended for debugging
winpty, though, so there's no useful need for ConEmu to adopt the console.
There's no way for me to opt out. I could disable the security check when
I detect ConEmu, but that's hazardous, and I'm not a fan of the API hooking
anyway.
winpty prints a content-free error, "Error creating winpty." in the above
case. The error report could be improved to include the traced() error,
"Security check failed: pipe client pid (7492) does not match agent pid (7416)".
Second part of a fix for
https://github.com/rprichard/winpty/issues/70
The SW_HIDE change fixes part of a ConEmu<->winpty incompatibility. If
WINPTY_SHOW_CONSOLE=1 is set, and ConEmu's "start cmd" flag is on, then
readFontTable can still run forever.
Avoiding a background desktop would fix a ConEmu<->winpty incompatibility
if not for the previous fix. It fixes a clipboard issue and
thread-unsafety issue, but only on Win7 and up. (More work is needed for
XP/Vista.)
See https://github.com/rprichard/winpty/issues/58.
See https://github.com/rprichard/winpty/issues/70.
When I initially wrote this section, there was no `install` target at all,
and I just ran `build/console.exe` right out of my checkout. That's
actually very inconvenient, though, for day-to-day use.
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.
* Harmonize the subsystem of every binary to CONSOLE. It apparently
doesn't matter for DLLs, and it's easier if they're all the same. I
examined various DLLs on my system, and they're very inconsistent.
(e.g. kernel32.dll is CONSOLE, but shell32.dll is GUI.)
* When using a recent XP-targeting toolset (v120_xp or v140_xp), it's
necessary to explicitly specify the subsystem, so list it in
configurations.gypi.
* node.js changed its common.gypi to disable exception handling[1], so
explicitly turn it back on in winpty.gyp. Placing the setting in
winpty.gyp's 'target_defaults' block doesn't seem to override a setting
in an included file's 'target_defaults' block, so instead enable EH on
each target.
* For consistency with other gyp files I see, use quoted integers instead
of bare integers for settings. Affects the 'RuntimeLibrary' setting.
* Provide a documented way in configurations.gypi for setting the
XP-specific toolsets.
[1] da9eff80a3
MSVC complained that GetVersionEx was deprecated when the /SDL checks were
enabled.
Comment added to WindowsVersion.cc:
Allow use of deprecated functions (i.e. GetVersionEx). We need to use
GetVersionEx for the old MinGW toolchain and with MSVC when it targets XP.
Having two code paths makes code harder to test, and it's not obvious how
to detect the presence of a new enough SDK. (Including ntverp.h and
examining VER_PRODUCTBUILD apparently works, but even then, MinGW-w64 and
MSVC seem to use different version numbers.)
This change avoids the unnecessary round-trip to the ANSI (or OEM?) code
page, and it also allows removing the mbstowcs calls, which simplifies the
code and fixes MSVC /SDL compliance.
In certain situations (e.g. when it has the SeImpersonatePrivilege
privilege), a named pipe server can impersonate a named pipe client and
execute in its security context (e.g. open the client user's files).
There's no reason for a winpty debugserver to need this ability, so
restrict it in the client.
It seems unlikely to me that this commit fixes a genuine security issue,
but it also seems like a decent precaution to take. Clients using winpty
don't connect to the DebugServer named pipe unless the WINPTY_DEBUG
environment variable is set, and Windows restricts the ability to
impersonate named clients (at least as of XP SP2).
