* Use the Bold(1) SGR parameter in only one case -- White-on-Black.
* Use the 0x9X and 0x10X SGR parameters to set intense/bright colors for
both foreground and background.
Detailed changes:
* DkGray background:
- Previously, this background was handled identically to the Black
background.
- Now it is treated like the non-grayscale colors, and the
foreground/background are set exactly.
* Black background:
- LtGray foreground is unchanged: default text colors
- White foreground is unchanged: text is bolded
- DkGray is fixed: instead of concealing the text, set the foreground
to DkGray, falling back to LtGray.
* LtGray background:
- Previously, this background was handled exactly the same way as the
White background.
- Now it is treated like any other non-grayscale color.
* White background:
- Black foreground is unchanged: only an Invert is output.
- LtGray: previously, the text was concealed. Now it is handled like
Black, and only an Invert is output.
- DkGray: previously only Invert was output. Now DkGray is also
output.
- White is effectively unchanged; it is still concealed if possible.
Also: set the console colors to LtGray-on-Black on startup. The
heuristic makes little sense with other colors.
Fixes https://github.com/rprichard/winpty/issues/39
The second cell can still have a different color than the first cell, and
*maybe* we want to output it. I'm unsure. It could perhaps matter for a
character appearing at the end of a line, but it seems unlikely to matter
in practice.
Fixes https://github.com/rprichard/winpty/issues/41
* Remove the old "Vista" code path in favor of two code paths:
- setSmallFontVista: sets a TrueType font to match the code page
- setSmallFontXP: uses SetConsoleFont to activate the smallest
viable font in the console's font table
* Selecting a CJK-specific TrueType font is important so that double-width
characters occupy two cells in the console, which is important for
maintaining consistency between the console and the Unix terminal.
(Perfect consistency here might be impossible, but using the appropriate
font improves things.) winpty currently duplicates double-width
characters, but that will be fixed soon.
* 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.
* 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.
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.
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.
* Some users might think they could run winpty-agent.exe.
* Right now, when I run winpty-agent.exe from a cmd.exe command prompt
window, it looks like winpty-agent.exe is segfaulting. It *ought* to
print an assertion failed dialog box.
* With this hack, it's impossible to add all the .cc files to an MSVC
project, because MSVC understandably thinks that
agent/AgentDebugClient.cc and shared/DebugClient.cc are two separate
C++ translation units. I could rename DebugClient.cc, but it's better
to just fix the problem with the Makefile.
If I run a GUI program inside mintty using winpty, the GUI's window should
appear on the same desktop as mintty, not on the hidden desktop containing
the winpty console.
Even though STARTUPINFO.lpDesktop's type is LPTSTR (instead of LPCTSTR),
the documentation doesn't say anything about CreateProcess modifying the
lpDesktop string, so I didn't bother making a copy of desktop.c_str().
* The intent of having the length variable was to avoid sending trailing
whitespace for each line, but the previous code never read the variable.
Instead, every line it sent was the width of the terminal window.
* There was a bug where running console.exe inside a TERM=cygwin terminal
resulted in excessive line feeds. This change mitigates that bug, but
doesn't fix it. The problem is that the agent assumes that after it
writes to the last column of a line, the cursor is still on the same
line, but this isn't true for the TERM=cygwin terminal.
* This avoids a name conflict with an existing unrelated project.
* I think winpty is a better name anyway. (i) It's more obviously
Windows-related. (ii) I think it more accurately describes what it
does. A "pseudo-console" ought to mirror the console API and allow
replacing the implementation built-in to Windows. This project is only
trying to provide functionality similar to using the master interface of
a Unix pty, but for native console programs.
I suspect that the library API (pconsole_open) should not be calling exit
if it can't start the agent process, but I don't want to deal with that
right now.
* Suppress debug output unless the PCONSOLEDBG enviroment variable is
set.
* Rename Trace to trace to be consistent with the camelCaps naming
convention.
The goal is to setup pipes between the libpconsole process and the new
agent process in a way that's secure and doesn't create an unnecessary
burden on the library's user. This is apparently hard.
I think this code is good enough.
* Remove most of the encoding table and instead generate the KeyDescriptor
entries dynamically at startup.
* I think I'm handling input tolerably well for TERM=xterm terminals, but
I removed the support I had for rxvt for now. I don't think it makes
sense to fill out the table, but the new code I have for TERM=xterm is
also bloated.
* If bytes are still queued after processing as many keypresses as
possible, send a DSR to the console. The console should respond with
a DSR reply, which will flush out the input buffer without having to
wait for a timeout.
* Add ah hoc code for ALT-<character> rather than listing every character
in the table.
* When keypresses have Alt/Ctrl/Shift modifiers, generate extra
INPUT_RECORDS to press and release each modifier. EDIT.COM seemed to
require these for some Ctrl-<key> keypresses I tried.
* Generate Ctrl-C events by calling GenerateConsoleCtrlEvent.
I noticed that calls to this routine don't behave exactly the same as
a real Ctrl-C keypress. In Python, pressing Ctrl-C immediately
displays a new "KeyboardInterrupt" line. Calling
GenerateConsoleCtrlEvent has no immediate effect, but after pressing
Enter, Python displays a stack trace where a KeyboardInterrupt was
raised. After some testing, I suspect the issue is that a real Ctrl-C
keypress interrupts a blocking console read, but
GenerateConsoleCtrlEvent does not.
I also tried synthesizing Ctrl-C using (a) PostMessage with
WM_{CHAR,KEYDOWN}, and (b) SendInput. I couldn't get either to work.
* Recognize ESC sequences. The set of recognized sequences is ad hoc.
* Recognize UTF-8-encoded characters and convert them to UTF-16.
* The code currently uses a timeout to differentiate between pressing ESC
and pressing a key that generates an ESC sequence. I have a theory that
I can use the "Device Status Report" ESC sequences to avoid this
timeout.
* Assume that either:
- The console has a white-on-black color scheme. This could be set
at agent startup.
- The remote terminal also has a white-on-black color scheme, OR...
- With a different color scheme, the white/black colors could be
reversed, but the console is still usable.
* The COMMON_LVB_REVERSE_VIDEO flag apparently has no effect in a Windows
console, so ignore it in the agent too.
* Start handling Unicode characters. I noticed that box drawing
characters (mc.exe / edit.com) are displayed correctly now. I'm calling
WideCharToMultiByte once per character, though, and I'm wondering if
this is inefficient.
