- 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.
* Remove obsolete comments and APIs.
* In pconsole.exe, use two threads to handle pconsole<->pty communication.
I use blocking I/O for the pty. For the Win32 pipe to the pconsole
agent, I use overlapped I/O and emulate blocking I/O.
I'm not sure I *have* to open the pipe in overlapped mode. When I last
tried using non-overlapped I/O, I had a problem where a pending read
would block writes (or vice versa). Maybe setting the overlapped
parameter to {Read,Write}File would be sufficient.
My plan now is to integrate the PseudoConsole with Cygwin and MSYS ptys,
with initial focus on Cygwin. I think I'll keep the separate Agent and DLL
binaries, and they'll continue to be native Win32 binaries. I don't want
to have two build systems (qmake vs whatever MSYS/Cygwin uses), and since
I'd like to remove the Qt dependency anyway, I'm trying to switch to
makefiles.
size_t wouldn't really be a reasonable type for Windows I/O because
ReadFile and WriteFile use a DWORD for byte counts. A single I/O operation
of more than 2GB seems unreasonable anyway.
agent.
* The code is based on that from AgentClient.cc, but without the Qt
dependency.
* The API currently uses blocking I/O. The intent is for users to use
a separate read thread and write thread.
The intent is to avoid a problem on Windows XP. On that OS, sending
a "Select All" command to freeze one console window also interrupts any
"window activity" (e.g. moving/closing/scrolling/right-clicking/...) on
all other console windows.
My hope is that putting the console into a special window station will
isolate it enough to avoid this problem. I noticed that the problem didn't
happen when I ran the TestNetServer as a service, which ran both the
TestNetServer and Agent processes with a special window station.
Note that even though the Agent runs in a special window station, the shell
and its children run in the normal window station.
has started a shell.
I thought this change would fix a problem with the Windows 8 Preview where
the connection shut down immediately after starting. It did not fix the
problem, which I still don't have an explanation for, but in any case, I
think the change is necessary.
* Add a note on how to use instsrv and srvany.
* First look for Agent.exe in the same directory as TestNetServer.exe
before looking for the executable in the build directory that Qt
Creator uses.
* Write a script that copies MinGW/Qt DLLs to a single directory.
The Mark command moves the cursor to the top-left, which interferes with
lynx, a full-screen Cygwin web browser, and probably other programs.
The Select All command also puts the console into selection mode, blocking
console output.
upward.
This commit gets the CMD/PowerShell CLS command working with the Agent.
Previously, the CLS command was broken in the following test case:
- User opens a window of height N and types CLS. The window now looks
like:
line0)
line1) D:\rprichard\Scrape\TestNetServer-build-desktop>
- User generates a bunch of output -- enough to scroll the window but not
enough to create a sync marker.
- User types CLS again.
- The window scrolls back to the top and is cleared.
- The agent thinks that lines [1..(N-1]] of the window (and screen buffer)
have changed. It omits line 0 because line 0 is blank before and after
the CLS. Therefore, it sends N-1 lines. The first line is at line 1.
We've already output a "remote line" larger than N, though, so we first
try to CursorUp by >>N lines.
- After moving the cursor up, we're actually on line 0 of the terminal
instead of line 1.
I think the general rule is that it's safe to "reset the terminal," but we
want to avoid resetting because it breaks history. For typical
command-line sessions that don't involve full-screen programs, (but which
*could* involve window resizing), I would like the history to be perfect.
and avoid sending lines in the window that aren't dirty yet.
The idea is that the bottom of the console screen commonly has blank lines
that do not need to be sent to the client, because nothing has been written
there yet. For example, when the console first appears, there is typically
a command-line prompt at the top of the window. When a console is expanded
vertically, blank lines commonly appear at the bottom.
Other misc changes to the output:
- When we send one later, also send all following lines.
- When we save a line into m_bufferData, fill in the rest of the line with
spaces. This way, it's possible to expand the console horizontally
without the agent resending all the lines.
- If nothing on the console has changed, then leave the cursor alone.
Don't hide, show, or move it.
* If the client was unable to write any data, write would return -1 with
errno==EAGAIN, and the client would assert fail.
* Apparently I thought that continue would jump to the start of the
do-while(0) loop. Replace the continue/do-while(0) with a
did_something flag.
While I'm at it, replace a few hard-coded constants with constants.
- On each polling, identify a range of lines to scan. This range will
include lines in the history if output has scrolled.
- Line in scrapeOutput and the terminal output routines (e.g.
sendLineToTerminal) are numbered as if writing to an infinitely-sized
terminal.
- Once history is large enough, write a string to column 1 ~200 lines
up. This synchronizing marker lets us know how much the console output
has scrolled.
- Freeze the console output by putting the console into select/mark mode.
Unfreeze it by sending an ESC keypress.
* The TestNet protocol starts with a terminal resize escape sequence, so
the server discards all input until it sees the sequence, and it delays
starting the agent. Eventually, the goal is to implement an SSH server,
and the SSH message that creates a PTY also provides the terminal size.
handled.
Use the UnixSignalHandler to detect terminal resizing. The client doesn't
do anything with the terminal size yet. It should send the size to the
server.
* Use disconnected() instead of readChannelFinished().
* Cleanup. There are three bidirectional pipes conceptually:
console <-> agent
agent <-> server
server <-> client
If one end of a pipe dies, start closing the other end, then clean up.
If the console dies (e.g. because cmd.exe exits), we still want to
collect the final console output and send it to the client.
To help with this, in the Agent, I call GetConsoleProcessList, then
scrapeOutput, then (potentially) disconnectFromServer.
