GCC 5.1 added a -Wsuggest-override option that reports missing `override`
keywords, which I used to prepare this commit. I'm not turning the option
on yet, though, because my Cygwin environment is still using GCC 4.9.
Initially, some of this code omitted a space between a closing
double-quotes and a macro, which broke with C++11:
m_output.write(CSI"0m"CSI"1;1H"CSI"2J");
To make it work with C++11, it changed to:
m_output.write(CSI"0m" CSI"1;1H" CSI"2J");
Now I'm fully separating them:
m_output.write(CSI "0m" CSI "1;1H" CSI "2J");
I don't expect C++ to change again, breaking my code, but it seems prudent
to avoid that possibility.
I searched the codebase for matches using this Sublime/Perl regex:
^([^"'\n]*("([^\\"\n]|\\.)*"|'([^\\'\n]|\\.)*'))*[^"'\n]*(?<!^)(?<!\bL)(?<=[A-Za-z0-9_])("([^\\"\n]|\\.)*"|'([^\\'\n]|\\.)*')
It determines:
- whether the program has a console
- whether that console has a window
- whether that window is on the current window station
It's motivated by the IntelliJ clipboard/winpty bug.
- Fix a typo in the 7-Zip default paths.
- Change env["Path"] to env["PATH"]. Python is case-sensitive, and "Path"
isn't working. Windows itself seems to prefer "Path". I'm guessing
Python is converting "Path" to "PATH" for platform interoperability.
This code path only occurs if the start-process reply packet has an
unexpected value in it, so it should never occur. If it somehow did,
though, it would be inconsistent (and poor behavior) to crash the process
using libwinpty.
TRACE() is like trace() but only evaluates its arguments when tracing is
enabled.
In various places on the default code path, where arguments are expensive
to evaluate, switch trace() to TRACE().
I'm not sure this actually *fixes* anything, but it arguably makes more
sense than using the current color, which is not guaranteed to match the
prevailing background color.
Aside: for scrolling output, console apps generally don't try to change
the background color, and it doesn't work well, even in Unix.
Fixes https://github.com/rprichard/winpty/issues/52
When resizing, ensure that the replacement sync marker does not become
visible if the buffer height is increased by more than the marker's margin
(currently 200 rows).
The wrapper enables the undocumented mode flag 0x200 on the CONIN handle,
which directs the Windows console to replace most KeyDown input records
with sequences of plain bytes, which are escape sequences for control and
navigation keys.
This particular solution reencodes escape sequences and looks roughly
similar to what the Windows console generates, with a few differences:
* For Alt-Backspace, winpty generates ^[ ^?, whereras Windows generates
^[ ^H.
* For Shift/Alt/Ctrl-modified sequences, winpty encodes the mask of
modifiers into the escape sequences.
* winpty generates ^[ Z for Shift-Tab, rather than ^I.
* winpty generates ^[ E for the NumPad "clear/5" key, rather than nothing.
I'm still not sure winpty *ought* to do this reencoding. I don't think
generating KeyUp events is necessary. In principle, it might be
needed/useful for dealing with various terminals. WSL bash.exe always
sets TERM to xterm, and even if changing it is correct w.r.t. input, it's
not necessarily correct for output -- the Windows console system is
expecting to see TERM=xterm output, which it uses to updates it screen
buffer. (I'm not sure that matters, much, though. I suppose
TERM=xterm-256color could be a problem?)
Fixes https://github.com/rprichard/winpty/issues/82
Discard bytes that don't decode as UTF-8.
Stop calling VkKeyScan on the two halves of a surrogate pair. It's
impossible for VkKeyScan to return a useful result.
Also: if we're on Win7 or earlier, skip this check. We'd like to skip
on Win8 and 8.1, too, but doing a version check for those versions is
complicated (e.g. requires a correct manifest or hacks).
On Windows 10 build 14342, with the new console, the Japanese system
locale, and the 437 code page, calling SetCurrentConsoleFontEx to set
the Consolas font breaks if FontFamily is 0, but it works if FontFamily
is 0x36.
See misc/Font-Report-June2016/Windows10SetFontBugginess.txt.
Additionally, if it is impossible to fit the entire screen buffer on the
current monitor, detect this condition uising the
GetLargestConsoleWindowSize API and make the console window as large as
possible. This is suboptimal for full-screen console programs (e.g. Far
Manager), but because the scrolling-mode scraper scrapes the screen buffer
rather than the visble window, the smaller-than-desired window frequently
has no noticeable effect.
Revert the use of MARK to freeze the new Windows 10 console. Use
SELECT_ALL again.
Fixes https://github.com/rprichard/winpty/issues/61
Fixes https://github.com/rprichard/winpty/issues/79
Breaks https://github.com/rprichard/winpty/issues/53 again
The reads were failing when running wmic.exe under winpty on Windows
10 build 14342. In that build, after running wmic.exe, the console
buffer was resized to (1500,300), but the window was not moved upward,
so it was hundreds to thousands of lines below the actual buffer.
This is obviously a Windows 10 bug, because even running wmic.exe in a
normal console demonstrates the issue. Simply fill the console with more
than 300 lines of junk, then try to run wmic.exe, and none of the
wmic.exe output is visible, even after hitting Return repeatedly.
Improve debugging for the case where SetConsoleMode fails. Apparently
on Windows 7, the call fails, but the 0x200 flag is still enabled. A
later GetConsoleMode call succeeds, but of course, further calls to
SetConsoleMode will still fail unless they unset 0x200.
Given that the 0x200 flag is undocumented and only respected in preview
releases, I'm hesistant to clear the flag when --escape-input isn't set.
Related to https://github.com/rprichard/winpty/issues/82
* 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.
