(MinGW-w64 works already -- only the old MinGW toolchain had trouble.)
* We need to build the test case with -std=g++11 to provide vsnprintf,
even though vsnprintf is in C99 and is provided by both MSVC and
MinGW-w64.
* The old MinGW provides a non-conforming swprintf.
* Remove the "version suffix" and BUILD_INFO.txt mechanisms, which I
believe no one uses except winpty itself. Instead, a suffix can be
added in the VERSION.txt file.
* Instead of passing the version and commit info as a preprocessor macro
when building every C++ file, write the info into a GenVersion.h
header that is only included by WinptyVersion.cc.
* Instead of writing a BUILD_INFO.txt in ship.py, pass COMMIT_HASH=<hash>
to make.
These changes accomplish two things:
* People who build a tag from source won't see a "<ver>-dev" suffix
anymore.
* Changing the version or the commit will correctly rebuild the version
object files (and only those object files). It will also relink every
binary.
Fixes https://github.com/rprichard/winpty/issues/72
These flags are used with WSL (Bash on Windows) and are commonly used.
(e.g. a pager status bar, man pages, etc.)
The most difficult part of this commit is figuring out when Windows
respects the flags versus ignores them. Apparently it deliberately
ignores them for backwards-compatibility with some programs.
If the terminal is placed in an alternate mode using DECCKM, then we
need to generate different input escape sequences for WSL (and other
programs using ENABLE_VIRTUAL_TERMINAL_INPUT). AFAIK, there is no way
for winpty to detect whether an alternate mode is enabled, but it only
seems to affect a small number of keys, so send those keys as window
messages.
We don't send *all* keys as window messages, because the console may try
to interpret some of them. It doesn't interpret the arrow keys and
Home/End, AFAICT, and those seem to be the only keys affected by DECCKM.
(The console's line-input mode *does* care about these navigation keys,
but in that case, WriteConsoleInput and window messages work equally well.)
DECCKM only seems to affect the keys when there is no modifier key.
I believe that by using SendMessage, winpty-agent will block until the
keys are appended to the console input buffer. I'm not sure how to verify
it. If this *weren't* the case, there could be a danger of key input
being transposed. It seems unlikely to be an issue.
Fixes https://github.com/rprichard/winpty/issues/90
* The compiler doesn't like implicit conversions to bool.
(it emits a "performance warning")
* It also doesn't like an unused argument in an exception catch block.
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.
