* Instead of reading the output line-by-line, figure out what lines we
need ahead-of-time and issue as few read calls as possible. On Windows
8 and up, we issue just one read call. On earlier versions, we avoid
reading more than a certain amount.
* This change reduces the CPU usage. e.g. In my Windows 10 VM, the idle
CPU usage of winpty-agent.exe+conhost.exe combined, with an empty
console, dropped from ~3.6% to ~1.4%. In a Windows 7 VM, I measured a
reduction of CPU from ~1.6% to 0.6%.
* Increase the MAX_CONSOLE_WIDTH from 500 to 2500. The limiting factor
now is that LargeConsoleRead reads at least one line at a line, but we
don't want to read more than 2500 characters in one call on old operating
systems.
* Fix the attribute handling in scanForDirtyLines. (The assignment to
newAttr was dead.)
The 2500 limit is arbitrary and could probably be increased. The actual
hard limit depends on the OS and is around 17000. My understanding is that
the limit is based upon the need to allocate I/O buffers within a shared
64KiB heap, and I'm worried about heap fragmentation. I know that 2500
is safe, because winpty has been issuing reads of almost 3000 characters
already to find the sync marker.
Fixes https://github.com/rprichard/winpty/issues/44
* 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.
* 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.
- In the agent, poll for the process exit at the same time we pull for
output. Once the child exits, record the exit code and close the data
pipe.
- In the unix-adapter, shut the program down once the input or output
handlers abort. Before exiting, query the agent for the exit code.
- Also: in the unix-adapter, apparently receiving the SIGWINCH signal can
interrupt both select and the InputHandler's read system call. I hope
it doesn't affect the blocking Win32 APIs, but I'm not really sure.
- Update the Agent to use separate control and data pipes and to receive
arbitrary-sized packets. Handle child process creation in the agent.
- Fix bugs in libpconsole:
- Insert a space between the pipe names on the agent command line.
- Don't close the desktop and window station until after connecting
to the agent's pipes.
- Change the format of the pconsole_start_process env parameter from an
array of wide-character-string pointers to a single contiguous block of
memory, like that accepted by CreateProcess.
