Add a spec for an In-process ConPTY #17387
Conversation
This comment has been minimized.
This comment has been minimized.
| They should also always be below the current prompt line so that we don't need to perform a potentially lossy backup/restore operation. | ||
|
|
||
| The `--vtmode xterm-ascii` switch exists for the telnet client as it only supports ASCII as per RFC854 section "THE NVT PRINTER AND KEYBOARD". | ||
| However, telnet is the only user of this flag and it's trivial to do there (for instance by stripping high codepoints in `WriteOutputToClient` in `telnet/console.cpp`), so there's no reason for us to keep this logic in the new code. |
There was a problem hiding this comment.
what happens when an out-of-date telnet client connects to an updated win11 machine with the new conpty, with the high codepoints in the output?
There was a problem hiding this comment.
I'm not entirely sure if I understand how telnet on Windows in particular works, but if you check out VtConsole.cpp in the OS repo you can see how it explicitly CreateProcess'es conhost.exe --vtmode ascii ... and then connects its local pipes to it to then pump the contents somewhere else. This means we can definitely filter the output there, after reading from ConPTY and before sending it somewhere else.
There was a problem hiding this comment.
I guess that means VtConsole.cpp is effectively part of the telnet server? In that case it'll definitely work, because telnet and inbox conpty are updated effectively in lockstep, right?
| ### Discussion | ||
|
|
||
| The idea is that we can translate Console API calls directly to VT at least as well as the current VtEngine setup can. | ||
| For instance, a call to `SetConsoleCursorPosition` clearly translates directly to a `CUP` escape sequence. |
There was a problem hiding this comment.
Presumably, we're keeping the assumption that things running in ConPTY 2 still have the buffer size clamped to the viewport, correct?
There was a problem hiding this comment.
Initially yes (in this step), but later on we won't (goal 2 and beyond). The new low level layer ("in-process ConPTY") will allow the terminal to specify the area that constitutes the addressable buffer range. ConPTY would basically make it equal the VT viewport (VT == buffer), Windows Terminal would pretend it would equal the VT viewport (VT == buffer, but we also have scrollback), and conhost would allow the entire 120x9001 buffer to be addressed (VT viewport is just a part of the buffer).
👉 Preview: https://github.com/microsoft/terminal/blob/dev/lhecker/13000-spec/doc/specs/%2313000%20-%20In-process%20ConPTY.md
The spec has a tl;dr! The tl;dr^2 for the commit message: