shell-mirror 1.5.24 → 1.5.26

package/mac-agent/node_modules/node-pty/deps/winpty/misc/IdentifyConsoleWindow.ps1

@@ -0,0 +1,51 @@
+#
+# Usage: powershell <path>\IdentifyConsoleWindow.ps1
+#
+# This script determines whether the process has a console attached, whether
+# that console has a non-NULL window (e.g. HWND), and whether the window is on
+# the current window station.
+#
+
+$signature = @'
+[DllImport("kernel32.dll", SetLastError=true)]
+public static extern IntPtr GetConsoleWindow();
+
+[DllImport("kernel32.dll", CharSet=CharSet.Auto, SetLastError=true)]
+public static extern bool SetConsoleTitle(String title);
+
+[DllImport("user32.dll", CharSet=CharSet.Auto, SetLastError=true)]
+public static extern int GetWindowText(IntPtr hWnd,
+                                       System.Text.StringBuilder lpString,
+                                       int nMaxCount);
+'@
+
+$WinAPI = Add-Type -MemberDefinition $signature `
+    -Name WinAPI -Namespace IdentifyConsoleWindow -PassThru
+
+if (!$WinAPI::SetConsoleTitle("ConsoleWindowScript")) {
+    echo "error: could not change console title -- is a console attached?"
+    exit 1
+} else {
+    echo "note: successfully set console title to ""ConsoleWindowScript""."
+}
+
+$hwnd = $WinAPI::GetConsoleWindow()
+if ($hwnd -eq 0) {
+    echo "note: GetConsoleWindow returned NULL."
+} else {
+    echo "note: GetConsoleWindow returned 0x$($hwnd.ToString("X"))."
+    $sb = New-Object System.Text.StringBuilder -ArgumentList 4096
+    if ($WinAPI::GetWindowText($hwnd, $sb, $sb.Capacity)) {
+        $title = $sb.ToString()
+        echo "note: GetWindowText returned ""${title}""."
+        if ($title -eq "ConsoleWindowScript") {
+            echo "success!"
+        } else {
+            echo "error: expected to see ""ConsoleWindowScript""."
+            echo "  (Perhaps the console window is on a different window station?)"
+        }
+    } else {
+        echo "error: GetWindowText could not read the window title."
+        echo "  (Perhaps the console window is on a different window station?)"
+    }
+}

package/mac-agent/node_modules/node-pty/deps/winpty/misc/IsNewConsole.cc

@@ -0,0 +1,87 @@
+// Determines whether this is a new console by testing whether MARK moves the
+// cursor.
+//
+// WARNING: This test program may behave erratically if run under winpty.
+//
+
+#include <windows.h>
+
+#include <stdio.h>
+#include <string.h>
+
+#include "TestUtil.cc"
+
+const int SC_CONSOLE_MARK = 0xFFF2;
+const int SC_CONSOLE_SELECT_ALL = 0xFFF5;
+
+static COORD getWindowPos(HANDLE conout) {
+    CONSOLE_SCREEN_BUFFER_INFO info = {};
+    BOOL ret = GetConsoleScreenBufferInfo(conout, &info);
+    ASSERT(ret && "GetConsoleScreenBufferInfo failed");
+    return { info.srWindow.Left, info.srWindow.Top };
+}
+
+static COORD getWindowSize(HANDLE conout) {
+    CONSOLE_SCREEN_BUFFER_INFO info = {};
+    BOOL ret = GetConsoleScreenBufferInfo(conout, &info);
+    ASSERT(ret && "GetConsoleScreenBufferInfo failed");
+    return {
+        static_cast<short>(info.srWindow.Right - info.srWindow.Left + 1),
+        static_cast<short>(info.srWindow.Bottom - info.srWindow.Top + 1)
+    };
+}
+
+static COORD getCursorPos(HANDLE conout) {
+    CONSOLE_SCREEN_BUFFER_INFO info = {};
+    BOOL ret = GetConsoleScreenBufferInfo(conout, &info);
+    ASSERT(ret && "GetConsoleScreenBufferInfo failed");
+    return info.dwCursorPosition;
+}
+
+static void setCursorPos(HANDLE conout, COORD pos) {
+    BOOL ret = SetConsoleCursorPosition(conout, pos);
+    ASSERT(ret && "SetConsoleCursorPosition failed");
+}
+
+int main() {
+    const HANDLE conout = openConout();
+    const HWND hwnd = GetConsoleWindow();
+    ASSERT(hwnd != NULL && "GetConsoleWindow() returned NULL");
+
+    // With the legacy console, the Mark command moves the the cursor to the
+    // top-left cell of the visible console window.  Determine whether this
+    // is the new console by seeing if the cursor moves.
+
+    const auto windowSize = getWindowSize(conout);
+    if (windowSize.X <= 1) {
+        printf("Error: console window must be at least 2 columns wide\n");
+        trace("Error: console window must be at least 2 columns wide");
+        return 1;
+    }
+
+    bool cursorMoved = false;
+    const auto initialPos = getCursorPos(conout);
+
+    const auto windowPos = getWindowPos(conout);
+    setCursorPos(conout, { static_cast<short>(windowPos.X + 1), windowPos.Y });
+
+    {
+        const auto posA = getCursorPos(conout);
+        SendMessage(hwnd, WM_SYSCOMMAND, SC_CONSOLE_MARK, 0);
+        const auto posB = getCursorPos(conout);
+        cursorMoved = memcmp(&posA, &posB, sizeof(posA)) != 0;
+        SendMessage(hwnd, WM_CHAR, 27, 0x00010001); // Send ESCAPE
+    }
+
+    setCursorPos(conout, initialPos);
+
+    if (cursorMoved) {
+        printf("Legacy console (i.e. MARK moved cursor)\n");
+        trace("Legacy console (i.e. MARK moved cursor)");
+    } else {
+        printf("Windows 10 new console (i.e MARK did not move cursor)\n");
+        trace("Windows 10 new console (i.e MARK did not move cursor)");
+    }
+
+    return 0;
+}

package/mac-agent/node_modules/node-pty/deps/winpty/misc/MouseInputNotes.txt

@@ -0,0 +1,90 @@
+Introduction
+============
+
+The only specification I could find describing mouse input escape sequences
+was the /usr/share/doc/xterm/ctlseqs.txt.gz file installed on my Ubuntu
+machine.
+
+Here are the relevant escape sequences:
+
+ * [ON] CSI '?' M 'h'                   Enable mouse input mode M
+ * [OFF] CSI '?' M 'l'                  Disable mouse input mode M
+ * [EVT] CSI 'M' F X Y                  Mouse event (default or mode 1005)
+ * [EVT6] CSI '<' F ';' X ';' Y 'M'     Mouse event with mode 1006
+ * [EVT6] CSI '<' F ';' X ';' Y 'm'     Mouse event with mode 1006 (up)
+ * [EVT15] CSI F ';' X ';' Y 'M'        Mouse event with mode 1015
+
+The first batch of modes affect what events are reported:
+
+ * 9: Presses only (not as well-supported as the other modes)
+ * 1000: Presses and releases
+ * 1002: Presses, releases, and moves-while-pressed
+ * 1003: Presses, releases, and all moves
+
+The next batch of modes affect the encoding of the mouse events:
+
+ * 1005: The X and Y coordinates are UTF-8 codepoints rather than bytes.
+ * 1006: Use the EVT6 sequences instead of EVT
+ * 1015: Use the EVT15 sequence instead of EVT (aka URVXT-mode)
+
+Support for modes in existing terminals
+=======================================
+
+                                 |  9   1000 1002 1003 | 1004 | overflow     | defhi | 1005 1006 1015
+---------------------------------+---------------------+------+--------------+-------+----------------
+Eclipse TM Terminal (Neon)       |  _    _    _    _   |  _   | n/a          | n/a   |  _    _    _
+gnome-terminal 3.6.2             |  X    X    X    X   |  _   | suppressed*b | 0x07  |  _    X    X
+iTerm2 2.1.4                     |  _    X    X    X   |  OI  | wrap*z       | n/a   |  X    X    X
+jediterm/IntelliJ                |  _    X    X    X   |  _   | ch='?'       | 0xff  |  X    X    X
+Konsole 2.13.2                   |  _    X    X    *a  |  _   | suppressed   | 0xff  |  X    X    X
+mintty 2.2.2                     |  X    X    X    X   |  OI  | ch='\0'      | 0xff  |  X    X    X
+putty 0.66                       |  _    X    X    _   |  _   | suppressed   | 0xff  |  _    X    X
+rxvt 2.7.10                      |  X    X    _    _   |  _   | wrap*z       | n/a   |  _    _    _
+screen(under xterm)              |  X    X    X    X   |  _   | suppressed   | 0xff  |  _    _    _
+urxvt 9.21                       |  X    X    X    X   |  _   | wrap*z       | n/a   |  X    _    X
+xfce4-terminal 0.6.3 (GTK2 VTE)  |  X    X    X    X   |  _   | wrap         | n/a   |  _    _    _
+xterm                            |  X    X    X    X   |  OI  | ch='\0'      | 0xff  |  X    X    X
+
+*a: Mode 1003 is handled the same way as 1002.
+*b: The coordinate wraps from 0xff to 0x00, then maxs out at 0x07.  I'm
+    guessing this behavior is a bug?  I'm using the Xubuntu 14.04
+    gnome-terminal.
+*z: These terminals have a bug where column 224 (and row 224, presumably)
+    yields a truncated escape sequence.  224 + 32 is 0, so it would normally
+    yield `CSI 'M' F '\0' Y`, but the '\0' is interpreted as a NUL-terminator.
+
+Problem 1: How do these flags work?
+===================================
+
+Terminals accept the OFF sequence with any of the input modes.  This makes
+little sense--there are two multi-value settings, not seven independent flags!
+
+All the terminals handle Granularity the same way.  ON-Granularity sets
+Granularity to the specified value, and OFF-Granularity sets Granularity to
+OFF.
+
+Terminals vary in how they handle the Encoding modes.  For example:
+
+ * xterm.  ON-Encoding sets Encoding.  OFF-Encoding with a non-active Encoding
+   has no effect.  OFF-Encoding otherwise resets Encoding to Default.
+
+ * mintty (tested 2.2.2), iTerm2 2.1.4, and jediterm.  ON-Encoding sets
+   Encoding.  OFF-Encoding resets Encoding to Default.
+
+ * Konsole (tested 2.13.2) seems to configure each encoding method
+   independently.  The effective Encoding is the first enabled encoding in this
+   list:
+    - Mode 1006
+    - Mode 1015
+    - Mode 1005
+    - Default
+
+ * gnome-terminal (tested 3.6.2) also configures each encoding method
+   independently.  The effective Encoding is the first enabled encoding in
+   this list:
+    - Mode 1006
+    - Mode 1015
+    - Default
+   Mode 1005 is not supported.
+
+ * xfce4 terminal 0.6.3 (GTK2 VTE) always outputs the default encoding method.

package/mac-agent/node_modules/node-pty/deps/winpty/misc/MoveConsoleWindow.cc

@@ -0,0 +1,34 @@
+#include <windows.h>
+
+#include "TestUtil.cc"
+
+int main(int argc, char *argv[]) {
+    if (argc != 3 && argc != 5) {
+        printf("Usage: %s x y\n", argv[0]);
+        printf("Usage: %s x y width height\n", argv[0]);
+        return 1;
+    }
+
+    HWND hwnd = GetConsoleWindow();
+
+    const int x = atoi(argv[1]);
+    const int y = atoi(argv[2]);
+
+    int w = 0, h = 0;
+    if (argc == 3) {
+        RECT r = {};
+        BOOL ret = GetWindowRect(hwnd, &r);
+        ASSERT(ret && "GetWindowRect failed on console window");
+        w = r.right - r.left;
+        h = r.bottom - r.top;
+    } else {
+        w = atoi(argv[3]);
+        h = atoi(argv[4]);
+    }
+
+    BOOL ret = MoveWindow(hwnd, x, y, w, h, TRUE);
+    trace("MoveWindow: ret=%d", ret);
+    printf("MoveWindow: ret=%d\n", ret);
+
+    return 0;
+}

package/mac-agent/node_modules/node-pty/deps/winpty/misc/Notes.txt

@@ -0,0 +1,219 @@
+Test programs
+-------------
+
+Cygwin
+  emacs
+  vim
+  mc     (Midnight Commander)
+  lynx
+  links
+  less
+  more
+  wget
+
+Capturing the console output
+----------------------------
+
+Initial idea:
+
+In the agent, keep track of the remote terminal state for N lines of
+(window+history).  Also keep track of the terminal size.  Regularly poll for
+changes to the console screen buffer, then use some number of edits to bring
+the remote terminal into sync with the console.
+
+This idea seems to have trouble when a Unix terminal is resized.  When the
+server receives a resize notification, it can have a hard time figuring out
+what the terminal did.  Race conditions might also be a problem.
+
+The behavior of the terminal can be tricky:
+
+ - When the window is expanded by one line, does the terminal add a blank line
+   to the bottom or move a line from the history into the top?
+
+ - When the window is shrunk by one line, does the terminal delete the topmost
+   or the bottommost line?  Can it delete the line with the cursor?
+
+Some popular behaviors for expanding:
+ - [all] If there are no history lines, then add a line at the bottom.
+ - [konsole] Always add a line at the bottom.
+ - [putty,xterm,rxvt] Pull in a history line from the top.
+ - [g-t] I can't tell.  It seems to add a blank line, until the program writes
+   to stdout or until I click the scroll bar, then the output "snaps" back down,
+   pulling lines out of the history.  I thought I saw different behavior
+   between Ubuntu 10.10 and 11.10, so maybe GNOME 3 changed something.  Avoid
+   using "bash" to test this behavior because "bash" apparently always writes
+   the prompt after terminal resize.
+
+Some popular behaviors for shrinking:
+ - [konsole,putty,xterm,rxvt] If the line at the bottom is blank, then delete
+   it.  Otherwise, move the topmost line into history.
+ - [g-t] If the line at the bottom has not been touched, then delete it.
+   Otherwise, move the topmost line into history.
+
+(TODO: I need to test my theories about the terminal behavior better still.
+It's interesting to see how g-t handles clear differently than every other
+terminal.)
+
+There is an ANSI escape sequence (DSR) that sends the current cursor location
+to the terminal's input.  One idea I had was to use this code to figure out how
+the terminal had handled a resize.  I currently think this idea won't work due
+to race conditions.
+
+Newer idea:
+
+Keep track of the last N lines that have been sent to the remote terminal.
+Poll for changes to console output.  When the output changes, send just the
+changed content to the terminal.  In particular:
+ - Don't send a cursor position (CUP) code.  Instead, if the line that's 3
+   steps up from the latest line changes, send a relative cursor up (CUU)
+   code.  It's OK to send an absolute column number code (CHA).
+ - At least in general, don't try to send complete screenshots of the current
+   console window.
+
+The idea is that sending just the changes should have good behavior for streams
+of output, even when those streams modify the output (e.g. an archiver, or
+maybe a downloader/packager/wget).  I need to think about whether this works
+for full-screen programs (e.g. emacs, less, lynx, the above list of programs).
+
+I noticed that console programs don't typically modify the window or buffer
+coordinates.  edit.com is an exception.
+
+I tested the pager in native Python (more?), and I verified that ENTER and SPACE
+both paid no attention to the location of the console window within the screen
+buffer.  This makes sense -- why would they care?  The Cygwin less, on the other
+hand, does care.  If I scroll the window up, then Cygwin less will write to a
+position within the window.  I didn't really expect this behavior, but it
+doesn't seem to be a problem.
+
+Setting up a TestNetServer service
+----------------------------------
+
+First run the deploy.sh script to copy files into deploy.  Make sure
+TestNetServer.exe will run in a bare environment (no MinGW or Qt in the path).
+
+Install the Windows Server 2003 Resource Kit.  It will have two programs in it,
+instsrv and srvany.
+
+Run:
+
+  InstSrv TestNetServer <path-to-srvany>\srvany.exe
+
+This creates a service named "TestNetServer" that uses the Microsoft service
+wrapper.  To configure the new service to run TestNetServer, set a registry
+value:
+
+  [HKLM\SYSTEM\CurrentControlSet\Services\TestNetServer\Parameters]
+  Application=<full-path>\TestNetServer.exe
+
+Also see http://www.iopus.com/guides/srvany.htm.
+
+To remove the service, run:
+
+  InstSrv TestNetServer REMOVE
+
+TODO
+----
+
+Agent: When resizing the console, consider whether to add lines to the top
+or bottom.  I remember thinking the current behavior was wrong for some
+application, but I forgot which one.
+
+Make the font as small as possible.  The console window dimensions are limited by
+the screen size, so making the font small reduces an unnecessary limitation on the
+PseudoConsole size.  There's a documented Vista/Win7 API for this
+(SetCurrentConsoleFontEx), and apparently WinXP has an undocumented API
+(SetConsoleFont):
+    http://blogs.microsoft.co.il/blogs/pavely/archive/2009/07/23/changing-console-fonts.aspx
+
+Make the agent work with DOS programs like edit and qbasic.
+ - Detect that the terminal program has resized the window/buffer and enter a
+   simple just-scrape-and-dont-resize mode.  Track the client window size and
+   send the intersection of the console and the agent's client.
+ - I also need to generate keyboard scan codes.
+ - Solve the NTVDM.EXE console shutdown problem, probably by ignoring NTVDM.EXE
+   when it appears on the GetConsoleProcessList list.
+
+Rename the agent?  Is the term "proxy" more accurate?
+
+Optimize the polling.  e.g. Use a longer poll interval when the console is idle.
+Do a minimal poll that checks whether the sync marker or window has moved.
+
+Increase the console buffer size to ~9000 lines.  Beware making it so big that
+reading the sync column exhausts the 32KB conhost<->agent heap.
+
+Reduce the memory overhead of the agent.  The agent's m_bufferData array can
+be small (a few hundred lines?) relative to the console buffer size.
+
+Try to handle console background color better.
+    Unix terminal emulators have a user-configurable foreground and background
+color, and for best results, the agent really needs to avoid changing the colors,
+especially the background color.  It's undesirable/ugly to SSH into a machine
+and see the command prompt change the colors.  It's especially ugly that the
+terminal retains its original colors and only drawn cells get the new colors.
+(e.g. Resizing the window to the right uses the local terminal colors rather
+than the remote colors.)  It's especially ugly in gnome-terminal, which draws
+user-configurable black as black, but VT100 black as dark-gray.
+    If there were a way to query the terminal emulator's colors, then I could
+match the console's colors to the terminal and everything would just work.  As
+far as I know, that's not possible.
+    I thought of a kludge that might work.  Instead of translating console white
+and black to VT/100 white and black, I would translate them to "reset" and
+"invert".  I'd translate other colors normally.  This approach should produce
+ideal results for command-line work and tolerable results for full-screen
+programs without configuration.  Configuring the agent for black-on-white or
+white-on-black would produce ideal results in all situations.
+    This kludge only really applies to the SSH application.  For a Win32 Konsole
+application, it should be easy to get the colors right all the time.
+
+Try using the screen reader API:
+ - To eliminate polling.
+ - To detect when a line wraps.  When a line wraps, it'd be nice not to send a
+   CRLF to the terminal emulator so copy-and-paste works better.
+ - To detect hard tabs with Cygwin.
+
+Implement VT100/ANSI escape sequence recognition for input.  Decide where this
+functionality belongs.  PseudoConsole.dll?  Disambiguating ESC from an escape
+sequence might be tricky.  For the SSH server, I was thinking that when a small
+SSH payload ended with an ESC character, I could assume the character was really
+an ESC keypress, on the assumption that if it were an escape sequence, the
+payload would probably contain the whole sequence.  I'm not sure this works,
+especially if there's a lot of other traffic multiplexed on the SSH socket.
+
+Support Unicode.
+ - Some DOS programs draw using line/box characters.  Can these characters be
+   translated to the Unicode equivalents?
+
+Create automated tests.
+
+Experiment with the Terminator emulator, an emulator that doesn't wrap lines.
+How many columns does it report having?  What column does it report the cursor
+in as it's writing past the right end of the window?  Will Terminator be a
+problem if I implement line wrapping detection in the agent?
+
+BUG: After the unix-adapter/pconsole.exe program exits, the blinking cursor is
+replaced with a hidden cursor.
+
+Fix assert() in the agent.  If it fails, the failure message needs to be
+reported somewhere.  Pop up a dialog box?  Maybe switch the active desktop,
+then show a dialog box?
+
+TODO: There's already a pconsole project on GitHub.  Maybe rename this project
+to something else?  winpty?
+
+TODO: Can the DebugServer system be replaced with OutputDebugString?  How
+do we decide whose processes' output to collect?
+
+TODO: Three executables:
+  build/winpty-agent.exe
+  build/winpty.dll
+  build/console.exe
+
+BUG: Run the pconsole.exe inside another console.  As I type dir, I see this:
+      D:\rprichard\pconsole>
+      D:\rprichard\pconsole>d
+      D:\rprichard\pconsole>di
+      D:\rprichard\pconsole>dir
+    In the output of "dir", every other line is blank.
+    There was a bug in Terminal::sendLine that was causing this to happen
+    frequently.  Now that I fixed it, this bug should only manifest on lines
+    whose last column is not a space (i.e. a full line).

package/mac-agent/node_modules/node-pty/deps/winpty/misc/OSVersion.cc

@@ -0,0 +1,27 @@
+#include <windows.h>
+
+#include <assert.h>
+#include <locale.h>
+#include <stdio.h>
+
+#include <iostream>
+
+int main() {
+    setlocale(LC_ALL, "");
+
+    OSVERSIONINFOEXW info = {0};
+    info.dwOSVersionInfoSize = sizeof(info);
+    assert(GetVersionExW((OSVERSIONINFOW*)&info));
+
+    printf("dwMajorVersion      = %d\n", (int)info.dwMajorVersion);
+    printf("dwMinorVersion      = %d\n", (int)info.dwMinorVersion);
+    printf("dwBuildNumber       = %d\n", (int)info.dwBuildNumber);
+    printf("dwPlatformId        = %d\n", (int)info.dwPlatformId);
+    printf("szCSDVersion        = %ls\n", info.szCSDVersion);
+    printf("wServicePackMajor   = %d\n", info.wServicePackMajor);
+    printf("wServicePackMinor   = %d\n", info.wServicePackMinor);
+    printf("wSuiteMask          = 0x%x\n", (unsigned int)info.wSuiteMask);
+    printf("wProductType        = 0x%x\n", (unsigned int)info.wProductType);
+
+    return 0;
+}

package/mac-agent/node_modules/node-pty/deps/winpty/misc/ScreenBufferFreezeInactive.cc

@@ -0,0 +1,101 @@
+//
+// Verify that console selection blocks writes to an inactive console screen
+// buffer.  Writes TEST PASSED or TEST FAILED to the popup console window.
+//
+
+#include <windows.h>
+#include <stdio.h>
+
+#include <string>
+
+#include "TestUtil.cc"
+
+const int SC_CONSOLE_MARK = 0xFFF2;
+const int SC_CONSOLE_SELECT_ALL = 0xFFF5;
+
+bool g_useMark = false;
+
+CALLBACK DWORD pausingThread(LPVOID dummy)
+{
+    HWND hwnd = GetConsoleWindow();
+    trace("Sending selection to freeze");
+    SendMessage(hwnd, WM_SYSCOMMAND,
+        g_useMark ? SC_CONSOLE_MARK :
+                    SC_CONSOLE_SELECT_ALL,
+        0);
+    Sleep(1000);
+    trace("Sending escape WM_CHAR to unfreeze");
+    SendMessage(hwnd, WM_CHAR, 27, 0x00010001);
+    Sleep(1000);
+}
+
+static HANDLE createBuffer() {
+    HANDLE buf = CreateConsoleScreenBuffer(
+        GENERIC_READ | GENERIC_WRITE,
+        FILE_SHARE_READ | FILE_SHARE_WRITE,
+        NULL,
+        CONSOLE_TEXTMODE_BUFFER,
+        NULL);
+    ASSERT(buf != INVALID_HANDLE_VALUE);
+    return buf;
+}
+
+static void runTest(bool useMark, bool createEarly) {
+    trace("=======================================");
+    trace("useMark=%d createEarly=%d", useMark, createEarly);
+    g_useMark = useMark;
+    HANDLE buf = INVALID_HANDLE_VALUE;
+
+    if (createEarly) {
+        buf = createBuffer();
+    }
+
+    CreateThread(NULL, 0,
+         pausingThread, NULL,
+         0, NULL);
+    Sleep(500);
+
+    if (!createEarly) {
+        trace("Creating buffer");
+        TimeMeasurement tm1;
+        buf = createBuffer();
+        const double elapsed1 = tm1.elapsed();
+        if (elapsed1 >= 0.250) {
+            printf("!!! TEST FAILED !!!\n");
+            Sleep(2000);
+            return;
+        }
+    }
+
+    trace("Writing to aux buffer");
+    TimeMeasurement tm2;
+    DWORD actual = 0;
+    BOOL ret = WriteConsoleW(buf, L"HI", 2, &actual, NULL);
+    const double elapsed2 = tm2.elapsed();
+    trace("Writing to aux buffer: finished: ret=%d actual=%d (elapsed=%1.3f)", ret, actual, elapsed2);
+    if (elapsed2 < 0.250) {
+        printf("!!! TEST FAILED !!!\n");
+    } else {
+        printf("TEST PASSED\n");
+    }
+    Sleep(2000);
+}
+
+int main(int argc, char **argv) {
+    if (argc == 1) {
+        startChildProcess(L"child");
+        return 0;
+    }
+
+    std::string arg = argv[1];
+    if (arg == "child") {
+        for (int useMark = 0; useMark <= 1; useMark++) {
+            for (int createEarly = 0; createEarly <= 1; createEarly++) {
+                runTest(useMark, createEarly);
+            }
+        }
+        printf("done...\n");
+        Sleep(1000);
+    }
+    return 0;
+}