I don't *think* this changes the semantics at all.
Also, move the INVALID_HANDLE_VALUE thing into a note at the bottom.
Improve intra-document bug linking.
* The NULL-to-new-handle conversion only happens when creating a new
console, not when attaching to the parent's console.
* Also, Windows reports that the handle value 0x7 is value, presumably
because it ignores the lowest 2 bits. It's better to just remove those
values from this test.
There's just one test, and it iterates over these combinations:
- CreationConsoleMode=NewConsole and CreationConsoleMode=Inherit
- bInheritHandles=FALSE and bInheritHandles=TRUE
It takes several seconds to run, but that's OK.
* CompareObjectHandles is a documented API, and presumably it could be
faster. The tests actually do run a little faster now on Win10,
dropping from 6.5sec to 3.6sec or so.
* Also make the NtQuerySystemInformation buffer static so we don't have to
repeat the double-buffer-in-a-loop process on every ntHandlePointer
call.
* The read end of a pipe is translated to NULL by the special
bInheritHandles=FALSE, no-STARTF_USESTDHANDLES inheritance mode. The
write end of the pipe works fine.
* Passing bInheritHandles=TRUE with an inheritable pipe handle fixes it.
Adding STARTF_USESTDHANDLES to this also works.
* To version detect 8.1, we need GetVersionEx to return something greater
than Windows 8, which requires creating an app manifest. For now at
least, put the manifest XML next to the EXE. It can be built into the
EXE, but this is good enough (at least for now).
* Add Test_CreateProcess_SpecialInherit
* Add traditional Test_HandleDuplication
* Make handle.dup() use a GetCurrentProcess() target while
handle.dup(handle.worker()) uses a non-pseudo handle.
* Allow creating a RemoteWorker object without spawning a new worker.
It can be used like so:
{
Worker w(Worker::DoNotSpawn);
if (...) {
w = ...;
} else {
w = ...;
}
}
* Remove the weird RemoteWorker(std::string) ctor. The computation of the
worker name should be inside the ctor.
* It now becomes possible to initialize a RemoteWorker using syntax like:
Worker w({ true, 0 });
However, these are still ambiguous:
Worker w({}) // could be move-init from a default-init Worker
Worker w({1}) // could be move-init from a Worker(SpawnParams{1})
* Make the Event ctor explicit. The SpawnParams ctor needs to be
non-explicit so it can be used with the braced initializer list.
* Add Test_Active_ScreenBuffer_Order
* Add Test_GetStdHandle_SetStdHandle
* Also test a STARTF_USESTDHANDLES process in
Test_Detach_Does_Not_Change_Standard_Handles.
* Test combos of CREATE_NEW_CONSOLE, DETACHED_PROCESS, CREATE_NO_WINDOW.
* Test use of PROC_THREAD_ATTRIBUTE_HANDLE_LIST. It cannot be used with
GetCurrentProcess(), but it also can't be used with traditional
console handles.
* Prefer nullptr over INVALID_HANDLE_VALUE. Change ntHandlePointer.
* Also add a public Worker::exit() for killing workers more conveniently.
* Previously, a Worker was either:
(1) fully initialized and running (m_valid==true), or
(2) moved out of (m_valid==false)
Now RemoteWorker::trySpawn() can return an invalid RemoteWorker object.
* TestCommon.h is a convenience header for the test cases. It aliases
Remote{Worker,Handle} back to {Worker,Handle}, and it includes many
basic C/C++ headers, as well as the parts of the harness suitable for
test cases.
* I'm still going to try to include what is used in each module.
* At some point, I should implement these in the main project. It will
need more testing on the various compilers. It really needs to be
on-by-default everywhere. If it's off, then at least pch.h should be
included everywhere, to minimize configuration differences between my
checkout and other people's checkouts.
* There should be some way to configure it off to check whether includes
are correct.
* The change reduces build times from 27.6s to 15.2s on a single-core VM.
* 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.
