* Rename QueryFont.exe to GetFont.exe -- it's shorted. Make font table
output shorter. Make the program work on XP.
* Add IsNewConsole.exe
* Add GetBufferInfo.exe
* Clear the executable bit on some .cc files
The immediate problem is that the implementation has a race condition. We
service the control pipe before the other pipes, so we can see the
winpty_spawn RPC request before noticing that the I/O pipes are connected.
(This situation actually happened and caused a pty4j test to fail.)
There are a few ways to fix this problem, such as by adding special calls
to service the I/O pipes in handleStartProcessPacket.
It occurred to me, though, that ensuring that pipes are connected before
calling winpty_spawn might be difficult in some environments that provide
high-level I/O systems. I'm specifically thinking of nodejs/libuv, where,
IIRC, it was difficult to guarantee that the CreateFile API would be called
synchronously.
It turns out to be easy to relax the restriction, anyway, so just do that.
I also think that CONIN and CONOUT/CONERR are sufficiently different that
perhaps CONIN should have been exempted.
With MSVC, converting an empty macro value with STRINGIFY doesn't seem to
work. (Maybe it's producing nothing rather than the blank literal, ""?)
Work around it by allowing __none__ as a substitute for blank.
e.g. replace
\\.\pipe\winpty-data-conin-7752-1-1d1bbc851f1b21e-03b22efd16c217582b421ec555292c69
with
\\.\pipe\winpty-conin-7752-1-1d1bbc851f1b21e-03b22efd16c217582b421ec555292c69
* Reorder ship targets to prefer MSYS, then MSYS2, then Cygwin
The MSYS build is much more likely to fail, both because its Cygwin
environment is poor (e.g. no C++11, no std::wstring) and because its
MinGW environment is poor (e.g. missing/broken SDDL APIs)
* Use PowerShell instead of the pefile module, because it's much faster,
even with the extra overhead of starting PowerShell.
* For MSYS, instead of disabling parallel make, use mingw32-make.exe.
Apparently, with this change, it's necessary to use forward slashes when
passing the PREFIX to make, so change that as well.
Previously, starting any Cygwin program (e.g. bash.exe, python2.7.exe)
would activate the terminal's mouse mode.
Move the ENABLE_EXTENDED_FLAGS note into a separate file.
There's really no reason to leave the mode ON, and disabling it makes
it easier to make mouse input work. WINPTY_MOUSE_MODE_NONE doesn't mean,
"stop mouse input"; it means, "the agent will not configure your
terminal's mouse output".
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
-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.
