* MSYS is 32-bit only.
* MSYS2 and Cygwin are either 32-bit or 64-bit. On 64-bit MSYS2/Cygwin,
we use the same architecture for all generated binaries.
* Prefer mingw-w64 to mingw. mingw-w64 seems to be more up-to-date.
It is the only option for 64-bit Windows, so stop looking for
x86_64-pc-mingw32-g++.
* Also pass -static when linking binaries. Otherwise, a pthreads DLL
is linked dynamically.
* Add debug information.
* This change fixed a bug where the new winpty-agent.exe process
successfully started, but immediately exited without reaching main().
The bug occurred while SSH'ing into the Cygwin SSH server.
* Unfreeze the console while changing the buffer size. Changing the
buffer size hangs conhost.exe. See:
- https://github.com/rprichard/winpty/issues/31
- https://wpdev.uservoice.com/forums/266908-command-prompt/suggestions/9941292-conhost-exe-hangs-in-win10-if-setconsolescreenbuff
* Detect buffer size changes and switch to a "direct mode". Direct mode
makes no attempt to track incremental console changes. Instead, the
content of the current console window is printed. This mode is
intended for full-screen apps that resize the console.
* Reopen CONOUT$, which detects apps that change the active screen buffer.
Fixes https://github.com/rprichard/winpty/issues/34.
* In the scroll scraping (scrollingScrapeOutput), consider a line changed
if the new content is truncated relative to the content previously
output. Previously, we only compared against the line-buffer up to the
current console width. e.g.
If this:
|C:\Program|
turns into:
|C:\Prog|
|ram |
we previously left |C:\Program| in the line-buffer for the first line
and did not re-output the first line.
We *should* reoutput the first line at this point so that, if the line
scrolls upward, and the terminal is later expanded, we will have
output an "Erase in Line" CSI command to clear the obscured "ram" text.
We need to update the line-buffer for the sake of Windows 10 combined
with terminals like xterm and putty. On such a terminal, if the
terminal later widened, Windows 10 will restore the console to the
first state. At that point, we need to reoutput the line, because
xterm and putty do not save and restore truncated line content extending
past the current terminal width.
- Formatting a wchar_t* argument with %s does not work with MinGW's
swprintf. (Apparently it does with MSVC? Sigh.) AFAICT, %ls does
the right thing with both MinGW and MSVC. (I didn't test MSVC.)
Avoid zero-initializing the buffer to accommodate VMs that have
little RAM. Use a smaller buffer size (9000x9000 ==> 324MB
buffer) that still demonstrates the read-size limit on XP.
Try to use a TrueType font rather than a raster font. The strategy is:
- [NEW] Try to use 6pt Consolas, then
- [NEW] Try to use 6pt Lucida Console, then
- Try to use the smallest font using SetCurrentConsoleFontEx, then
- Try to use the smallest font using the undocumented SetConsoleFont
XP API.
When a raster font is active, the console turns most/all non-ASCII
characters into '?' characters. We need to select a TrueType font to
preserve these characters.
By calling `setlocale(LC_ALL, "");`, we give the user a chance to
override the ASCII-only default so that non-ASCII arguments are
converted into UTF-16 properly, which is required to pass them
correctly to the actual Win32 executable.
This is necessary because POSIX dictates that we start up with the C
locale, ignoring all environment variables, until that `setlocale()`
call.
This fixes https://github.com/git-for-windows/git/issues/412
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Apparently the non-w64 mingw32 does not have an swprintf function, though
it does have an snwprintf function. In any case, the function takes a
second argument which is a buffer size.
Also include cwchar and cctype.
Print a message when building the test.
* If a new window station can't be created, keep going anyway. I *think*
this is what IntelliJ's fork is doing. Perhaps the window should be
marked SW_HIDE in this case?
* Rename WINPYDBG to WINPTY_DEBUG.
* Add an environment variable WINPTY_SHOW_CONSOLE. If non-empty, the
console window is placed on the same window station and is visible.
It's intended for testing purposes.
If a process is running under control of winpty, the output of the process is decorated with ESC sequences to control a terminal to print the process output nicely. In some environments however, the client showing the output to the user is not a full terminal emulation, the Eclipse CDT debug console view in example, and the ESC sequences are printed as output additional to the real process output. This commit is adding an API function to switch into a mode where winpty is not decorating the process output with ESC sequences. The console mode is designated to pass on the process output to the client as is.
Added new agent message "GetProcessId" and a API "winpty_get_process_id"
to allow access to the process id of the started process. The process id
is needed to integrate "winpty" with Eclipse CDT to launch native Windows
console applications inside the Eclipse UI.
