ConPTY Passthrough mode #1555

@DHowett-MSFT commented on GitHub (Jun 8, 2019):

And the reason one console might enter and exit passthrough mode multiple times is that you may run coolNewThing.exe from CMD, and perhaps it might launch a further process that needs legacy support.

Additional concerns: if you have a tree of four processes, each of which wants passthrough to be different, should the ones that are doing ReadConsoleOutput be able to read the buffers from the other legacy/non-passthrough ones?

It’s complicated when you get into compatibility discussions. 😄

@DHowett-MSFT commented on GitHub (Jun 8, 2019): And the reason one console might enter and exit passthrough mode multiple times is that you may run `coolNewThing.exe` from CMD, and perhaps it might launch a further process that needs legacy support. Additional concerns: if you have a tree of four processes, each of which wants passthrough to be different, should the ones that are doing `ReadConsoleOutput` be able to read the buffers from the other legacy/non-passthrough ones? It’s complicated when you get into compatibility discussions. :smile:

claunia commented

@zadjii-msft commented on GitHub (Jun 10, 2019):

Yea, I tried getting this working for like a day last year, but it's something I've wanted to work on for a while.

As Dustin mentioned, there'd be real weirdness moving between passthrough mode and non-passthrough mode. However, I think it might still be something good to investigate.

@zadjii-msft commented on GitHub (Jun 10, 2019): Yea, I tried getting this working for like a day last year, but it's something I've wanted to work on for a while. As Dustin mentioned, there'd be real weirdness moving between passthrough mode and non-passthrough mode. However, I think it might still be something good to investigate.

claunia commented

@zadjii-msft commented on GitHub (Jul 16, 2019):

From #1985:

I've discussed this a couple times on different threads before, but I think I never made a real issue for it.

The idea of conpty passthrough mode is that a commandline client application
that knows it's only going to use VT sequences (and not the API) to modify
the console could set a special mode, ENABLE_PASSTHROUGH_MODE. If conpty is
active, the console would then stop rendering itself over conpty, and anything
that was written to the console would go straight to the terminal.

This would work especially well for something like wsl, where it's only ever going to be talking VT.

It would not work for cmd.exe, because of cmd.exe's heavy reliance on the API.

Windows Powershell again needs the API pretty heavily, but maybe Powershell
Core, which is cross-platform, could make use of it.

This has some rough edges that need to be sorted out.

What happens when the app exits, and passthrough mode is turned off? The
terminal and conpty's buffers would not be equivalent anymore!

I've been toying with the idea of having conpty both pass the sequences
through, and also process them itself, so that the terminal and conpty stay
in sync.

What happens when someone tries to call Console API's in passthrough mode?

I'm thinking we just cause them to fail. All save for Get/SetConsoleMode and reading input / writing output.

We'll also probably need to be able to read resize events.

This needs a real spec written, but it probably needs prototyping done before that.

@zadjii-msft commented on GitHub (Jul 16, 2019): From #1985: > I've discussed this a couple times on different threads before, but I think I never made a real issue for it. > > The idea of conpty passthrough mode is that a commandline client application > that _knows_ it's only going to use VT sequences (and __not__ the API) to modify > the console could set a special mode, `ENABLE_PASSTHROUGH_MODE`. If conpty is > active, the console would then _stop_ rendering itself over conpty, and anything > that was written to the console would go straight to the terminal. > * This would work especially well for something like `wsl`, where it's only ever going to be talking VT. > * It would _not_ work for cmd.exe, because of cmd.exe's heavy reliance on the API. > * Windows Powershell again needs the API pretty heavily, but maybe Powershell > Core, which is cross-platform, could make use of it. > > This has some rough edges that need to be sorted out. > * [ ] What happens when the app exits, and passthrough mode is turned off? The > terminal and conpty's buffers would not be equivalent anymore! > - I've been toying with the idea of having conpty both pass the sequences > through, and also process them itself, so that the terminal and conpty stay > in sync. > * [ ] What happens when someone tries to call Console API's in passthrough mode? > - I'm thinking we just cause them to fail. All save for `Get/SetConsoleMode` and reading input / writing output. > - We'll also probably need to be able to read resize events. > > This needs a real spec written, but it probably needs prototyping done before that.

claunia commented

@oising commented on GitHub (Jul 17, 2019):

We need a SIGWINCH asynchronous signal for resizing somehow.

@oising commented on GitHub (Jul 17, 2019): We need a `SIGWINCH` asynchronous signal for resizing somehow.

claunia commented

@mintty commented on GitHub (Jul 19, 2019):

This is an essential feature for opening MS text-mode software (esp. WSL) to 3rd-party environments.
The current approach seems to tighly connect the Windows terminal implementation with ConPTY, however that limits applications unnecessarily and makes them highly dependent on Windows terminal progress (which may still take years, honestly).

It would not work for cmd.exe, because of cmd.exe's heavy reliance on the API.

It should be a combined mode: Whenever a console-API-based application is run, e.g. as started from a pure terminal-based application, the console API calls should be transformed into terminal escape sequences. Note as there are not so many features in the console API, this is a much easier approach than the reverse mapping, trying to squeeze terminal features through the conhost bottleneck.

@mintty commented on GitHub (Jul 19, 2019): This is an essential feature for opening MS text-mode software (esp. WSL) to 3rd-party environments. The current approach seems to tighly connect the Windows terminal implementation with ConPTY, however that limits applications unnecessarily and makes them highly dependent on Windows terminal progress (which may still take years, honestly). > It would not work for cmd.exe, because of cmd.exe's heavy reliance on the API. It should be a combined mode: Whenever a console-API-based application is run, e.g. as started from a pure terminal-based application, the console API calls should be transformed into terminal escape sequences. Note as there are not so many features in the console API, this is a much easier approach than the reverse mapping, trying to squeeze terminal features through the conhost bottleneck.

claunia commented

@therealkenc commented on GitHub (Jul 20, 2019):

Just realized #2035 is this ask framed differently.

however that limits applications unnecessarily and makes them highly dependent on Windows terminal progress

Not just progress. Behavior. This guy is writing a Tek4010 emulator. He is going to need a PTY if say his code were ever ported to native win32. And conhost sure as heck doesn't know what to do with the bytestream coming down that PTY. Never will. And need not care.

We need a SIGWINCH asynchronous signal for resizing somehow.

That too. Doesn't have to be a signal, mind, if there is some religious/philosophical reasons against. But if not it needs to be a separate (third rail) HANDLE on which I can WaitForMultipleObjects(), because no one said there is a ReadFile() byte coming, ever.

@therealkenc commented on GitHub (Jul 20, 2019): Just realized #2035 is this ask framed differently. > however that limits applications unnecessarily and makes them highly dependent on Windows terminal progress Not just progress. _Behavior_. This guy is writing a [Tek4010 emulator](https://github.com/rricharz/Tek4010). He is going to need a PTY if say his code were ever ported to native win32. And `conhost` sure as heck doesn't know what to do with the bytestream coming down that PTY. Never will. And need not care. > We need a SIGWINCH asynchronous signal for resizing somehow. That too. Doesn't have to be a signal, mind, if there is some religious/philosophical reasons against. But if not it needs to be a separate (third rail) `HANDLE` on which I can `WaitForMultipleObjects()`, because no one said there is a `ReadFile()` byte coming, ever.

claunia commented

@be5invis commented on GitHub (Jul 20, 2019):

@mintty
There are many absurd console API usages, like reading the screen. That's really a legacy that ... IBM PC has a video card while PDPs aren't.
One idea is that ConPTY can have a "sync" stuff to read back the screen from a console application if some console API applications want to something strange. Otherwise the console host could simply convert console API calls into VT sequence, and forward that to the terminal app.

@be5invis commented on GitHub (Jul 20, 2019): @mintty There are many absurd console API usages, like [reading the screen](https://docs.microsoft.com/en-us/windows/console/readconsoleoutput). That's really a legacy that ... IBM PC has a video card while PDPs aren't. One idea is that ConPTY can have a "sync" stuff to read back the screen from a console application if some console API applications want to something strange. Otherwise the console host could simply convert console API calls into VT sequence, and forward that to the terminal app.

claunia commented

@therealkenc commented on GitHub (Jul 21, 2019):

There are many absurd console API usages, like reading the screen.

Great. Invent a new CSI sequence for that. Send the PCHAR_INFO lpBuffer back as I dunno a base64 gzip. The feature is not supported by Mintty. Yet. No biggie. Not even unusual. Any 6502/Z80 assembler programmer working 1981 was free to add their own crazy vendor-specific sequence to their company's terminal if they were bored enough on a weekend too.

@therealkenc commented on GitHub (Jul 21, 2019): > There are many absurd console API usages, like reading the screen. Great. Invent a new CSI sequence for that. Send the `PCHAR_INFO lpBuffer` back as I dunno a base64 gzip. The feature is not supported by Mintty. Yet. No biggie. Not even unusual. Any 6502/Z80 assembler programmer working 1981 was free to add their own crazy vendor-specific sequence to their company's terminal if they were bored enough on a weekend too.

claunia commented

@mintty commented on GitHub (Jul 21, 2019):

There are many absurd console API usages, like reading the screen.

Great. Invent a new CSI sequence for that.

I assume this concern is more about the other direction of such adaptation, i.e. how would you serve a Windows console program that wants to use that "absurd" feature? You could run a second, hidden console in parallel, to maintain backwards compatibility.

@mintty commented on GitHub (Jul 21, 2019): > > There are many absurd console API usages, like reading the screen. > Great. Invent a new CSI sequence for that. I assume this concern is more about the other direction of such adaptation, i.e. how would you serve a Windows console program that wants to use that "absurd" feature? You could run a second, hidden console in parallel, to maintain backwards compatibility.

claunia commented

@DHowett-MSFT commented on GitHub (Jul 21, 2019):

run a second, hidden console in parallel

The people who hate how ConPTY is implemented today will absolutely hate how it's implemented if we do that. 😁

@DHowett-MSFT commented on GitHub (Jul 21, 2019): > run a second, hidden console in parallel The people who hate how ConPTY is implemented today will _absolutely_ hate how it's implemented if we do that. :grin:

claunia commented

@mintty commented on GitHub (Jul 21, 2019):

They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma.

@mintty commented on GitHub (Jul 21, 2019): They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma.

claunia commented

@therealkenc commented on GitHub (Jul 21, 2019):

run a second, hidden console in parallel

This solution makes no sense because there is no window in sshd.exe nor someoldprogram.exe. Both those programs are text only applications that wouldn't know a Consolas Font from a hole in the ground.

To the point of #2035, neither sshd.exe nor someoldprogram.exe are terminal emulators. Gnome Terminal is a terminal emulator. And gnome-terminal is the only thing that can give the correct answer as to the contents its screen buffer; ie what ReadConsoleOutput() should return. Similarly, the only thing that knows the contents of (VS Code) xterm.js's screen buffer is xterm.js. ConPTY doesn't have a clue what xterm.js internal screen buffer contains. At best it can only guess by scraping the data passing by.

I assume this concern is more about the other direction of such adaptation,

Yes. And as a practical matter I wouldn't expect the ESC[?GIVEMEBUFFERASIBM feature being added to vteterminal anytime soon. Unless someone can point out the killer app that calls ReadConsoleOutput().

[a hidden window] might be necessary to solve an otherwise unresolvable dilemma.

I think we are closer than that. If conhost wants to read-only scrape the data going by for the sole purpose of keeping a wild-ass-guess as what the actual terminal emulator's buffer looks like, sure, I can live with that. ReadConsoleOutput() is a red herring. If conhost (call it a urxvtd analogy) wants to maintain a shadow buffer, it can knock itself out.

...So long as it is quiet about it. There is no reason for a pass-through "mode", which is how this issue was framed. There is never a reason for ConPTY to inject a VT sequence into a WriteFile() on a PTY handle -- ever. Daniel over on the VS Code team can't possibly care; because he has his own terminal emulator. PTYs don't care about VT100 sequences. Never heard of them.

[Then we need SIGWINCH (or equivalent thereof). Which isn't related to VT100 sequences or screen buffers either.]

@therealkenc commented on GitHub (Jul 21, 2019): > > run a second, hidden console in parallel This solution makes no sense because there is no window in `sshd.exe` nor `someoldprogram.exe`. Both those programs are text only applications that wouldn't know a Consolas Font from a hole in the ground. To the point of #2035, neither `sshd.exe` nor `someoldprogram.exe` are terminal emulators. Gnome Terminal is a terminal emulator. And `gnome-terminal` is the only thing that can give the correct answer as to the contents its screen buffer; ie what `ReadConsoleOutput()` should return. Similarly, the only thing that knows the contents of (VS Code) [`xterm.js's`](https://github.com/xtermjs/xterm.js/) screen buffer is `xterm.js`. ConPTY doesn't have a clue what `xterm.js` internal screen buffer contains. At best it can only guess by scraping the data passing by. > I assume this concern is more about the other direction of such adaptation, Yes. And as a practical matter I wouldn't expect the `ESC[?GIVEMEBUFFERASIBM` feature being added to [vteterminal](https://developer.gnome.org/vte/unstable/VteTerminal.html) anytime soon. Unless someone can point out the killer app that calls `ReadConsoleOutput()`. > [a hidden window] might be necessary to solve an otherwise unresolvable dilemma. I think we are closer than that. If `conhost` wants to read-only scrape the data going by for the sole purpose of keeping a wild-ass-guess as what the _actual_ terminal emulator's buffer looks like, sure, I can live with that. `ReadConsoleOutput()` is a red herring. If `conhost` (call it a [`urxvtd`](https://manpages.debian.org/testing/rxvt-unicode/urxvtd.1.en.html) analogy) wants to maintain a shadow buffer, it can knock itself out. ...So long as it is quiet about it. There is no reason for a pass-through "mode", which is how this issue was framed. There is never a reason for ConPTY to inject a VT sequence into a `WriteFile()` on a PTY handle -- ever. Daniel over on the VS Code team can't possibly care; because _he has his own terminal emulator_. PTYs don't care about VT100 sequences. Never heard of them. [Then we need `SIGWINCH` (or equivalent thereof). Which isn't related to VT100 sequences or screen buffers either.]

claunia commented

@DHowett-MSFT commented on GitHub (Jul 21, 2019):

@therealkenc,

Like it or not, conhost is the API server that, regardless of whether it presents a window, makes all existing Win32 console applications work. It must continue to make those applications work, because organizations really ~~hate~~ love when Microsoft rolls through with a new standard and tells everybody to drop what they're doing and throw out thousands of lines of code.

I think you're looking to turn this request, and this project, into something it's not. You may be attempting to turn CreatePseudoConsole into something it's not, too. Things work the way they work because we need to maintain compatibility with the thirty years of applications written since the VGA text mode buffer became the "official" design inspiration for how consoles should work in DOS and Windows.

ConPTY exists to--narrowly-stated--allow an application that understands a number of sequences as specified by an xterm-256color terminfo to host a windows console application; to wit: an application that would otherwise run in conhost should be able to run in a "terminal emulator" of sufficient compatibility. It's not intended to support a TEK4010 application (those are not windows console subsystem applications), and it's not likely to want to support a TEK4010 terminal emulator that is expecting to receive a bytestream from a TEK4010 application. That guy will probably end up doing what everybody ELSE who doesn't want to write a windows console subsystem application does: use pipes, because they don't have the same compatibility requirements (neé guarantees) as the windows pseudoconsole infrastructure.

Through that lens, a "passthrough" mode is required. A console application by default, and this cannot be changed for compatibility reasons, starts up in a mode where it just has full access to all of the stupid Win32 console APIs that no terminal emulator developer wants to countenance. Nobody should be able to read back the contents of a terminal buffer, local or remote, that they wrote to. Nobody should be able to write into the offscreen section of the buffer, because there's no guarantee anywhere else that it actually exists. But, they do. Developers use this. Applications expect this, because they were written as windows console subsystem applications. A passthrough mode--mode!--is the only way we can offer an application a way to say "I promise I won't use the old ways" while still being a windows console subsystem application. That's the first step we can make towards ConPTY being the dumb pipe you want it to be.

If you'd like to debate whether the Windows Console was the right choice, or was well-designed, I'm happy to have you do it--but not here.

Two asides.

If you're looking for a better SIGWINCH, follow #281.
On machines where isatty(3) is a libc-provided fixture, you also have openpty(3). When somebody spawns a child application with a stdin/stdout hooked up to file descriptors they get back from openpty(3), isatty(3) suddenly returns 1. That application will, more often than not, decide that what that means is that it can send back VT100 escape sequences. That's what it means to most applications to be "on a tty." Sure, it's a terrible abstraction and a poor design and applications should be smarter than this, but they're not. The Windows Pseudoconsole fits right in, here, with the understanding that "I've allocated a PTY, which means I want VT".

@DHowett-MSFT commented on GitHub (Jul 21, 2019): @therealkenc, Like it or not, conhost is the _API server_ that, regardless of whether it presents a window, makes all existing Win32 console applications work. It must continue to make those applications work, because organizations really ~hate~ love when Microsoft rolls through with a new standard and tells everybody to drop what they're doing and throw out thousands of lines of code. I think you're looking to turn this request, and this project, into something it's not. You may be attempting to turn `CreatePseudoConsole` into something it's not, too. Things work the way they work because we need to maintain compatibility with the thirty years of applications written since the VGA text mode buffer became the "official" design inspiration for how consoles should work in DOS and Windows. ConPTY exists to--narrowly-stated--**allow an application that understands a number of sequences as specified by an xterm-256color terminfo to host a _windows console application_**; to wit: an application that would otherwise run in conhost should be able to run in a "terminal emulator" of sufficient compatibility. It's not intended to support a TEK4010 application (those are not windows console subsystem applications), and it's not likely to want to support a TEK4010 terminal emulator that is expecting to receive a bytestream from a TEK4010 application. That guy will probably end up doing what everybody ELSE who doesn't want to write a windows console subsystem application does: **use pipes**, because they don't have the same compatibility requirements (neé guarantees) as the windows pseudoconsole infrastructure. Through that lens, a "passthrough" mode is required. A console application _by default_, and this cannot be changed for compatibility reasons, starts up in a mode where it just has full access to all of the stupid Win32 console APIs that no terminal emulator developer wants to countenance. Nobody _should_ be able to read back the contents of a terminal buffer, local or remote, that they wrote to. Nobody _should_ be able to write into the offscreen section of the buffer, because there's no guarantee anywhere else that it actually exists. But, they do. Developers use this. Applications expect this, because they were written as windows console subsystem applications. A passthrough mode--mode!--is the only way we can offer an application a way to say "I promise I won't use the old ways" while still being a windows console subsystem application. That's the first step we can make towards ConPTY being the dumb pipe you want it to be. If you'd like to debate whether the Windows Console was the right choice, or was well-designed, I'm happy to have you do it--but not here. --- Two asides. 1. If you're looking for a better `SIGWINCH`, follow #281. 2. On machines where `isatty(3)` is a libc-provided fixture, you also have `openpty(3)`. When somebody spawns a child application with a stdin/stdout hooked up to file descriptors they get back from `openpty(3)`, `isatty(3)` suddenly returns **1**. That application will, more often than not, decide that what that means is that it can send back VT100 escape sequences. That's what it means to most applications to be "on a tty." Sure, it's a terrible abstraction and a poor design and applications should be smarter than this, but they're not. The Windows Pseudoconsole fits right in, here, with the understanding that "I've allocated a PTY, which means I want VT".

claunia commented

@therealkenc commented on GitHub (Jul 22, 2019):

I'm not intending to criticize the design or implementation -- at all. That was not the intent. I am trying (more slowly than intended) to find a solution to open-for-a-year issue WSL#3279. Of which Biswa96 has a very good start.

@therealkenc commented on GitHub (Jul 22, 2019): I'm not intending to criticize the design or implementation -- at all. That was not the intent. I am trying (more slowly than intended) to find a solution to open-for-a-year issue [WSL#3279](https://github.com/microsoft/WSL/issues/3279). Of which Biswa96 has a very good start.

claunia commented

@zadjii-msft commented on GitHub (Jul 22, 2019):

woah this thread got pretty out of hand over the weekend.

The stars aligned Friday, and I actually got a chance to play around with implementing a passthrough mode for conpty. I'm pretty happy with how it works so far, so I think it needs a spec and some polish, and maybe we can ship it one day. Here's the approach I've been taking:

I introduced a new ENABLE_PASSTHROUGH_MODE to the SetConsoleMode flags.
When a commandline application enables passthrough mode, and the console is currently attached to a terminal (it's in conpty mode), any text they write to the console is written straight to the terminal as well, with no munging by conhost.
In passthrough mode, conpty stops "rendering" any changes to its buffer.
If a commandline application knows it's not going to be doing anything with the console API, it can safely set passthrough mode to be able to talk directly to the terminal.
[NOT DONE YET] If a commandline app in passthrough mode tries to call any API's, we'll either:
- Convert the effects of that API call to VT, and pass that through to the terminal. We'll do this for API's where this is reasonable - SetConsoleTextAttribute is a good example.
- For some APIs where the terminal doesn't really matter, we'll just keep doing what we're currently doing (case in point GetConsoleProcessList).
- For APIs that don't make sense for conhost to be able to respond in passthrough mode, or we can't create a VT sequence to perform the requested operation, we'll return E_UNSUPPORTED_API (or a real error) indicating that API isn't supported in passthrough mode. Case in point: ReadConsoleOutput*, ScrollConsoleScreenBuffer, SetConsoleDisplayMode, etc.
  - Since the client app was updated to add support for passthrough mode, it should be able to be updated to handle this error case as well.
conhost also processes the strings that a commandline app emitted. This is to try and keep conpty's state in sync. This is important for the following.
When a client app exits passthrough mode, there's a chance that the terminal is in a torn state from the conpty. Case in point, if cmd.exe launched wsl.exe, and wsl enabled passthrough, did some stuff, then wsl exited, and cmd restored the console back to non-passthrough mode (as it needs to use the API). When passthrough mode is exited, conpty will redraw its screen, to re-sync the terminal to what conpty believes the buffer looks like.
- For things like just launching wsl.exe or ssh.exe directly, or for mintty, this won't be as important, as the client will always be in passthrough mode, and the conpty will never "exit" passthrough.

This provides a way where we can be sure that apps that weren't updated for running in a pty will still have access to the entire console API, but apps that want to live in the new world can say "I promise I know what I'm doing", and run even smoother in conpty. I believe there's going to be an incredibly small intersection of apps that want to use VT and also call things like ReadConsoleOutput. Most apps are wither going to be console-like, using the API heavily, and might not be as likely to be updated for such a mode. However, for *nix-like apps that aren't going to be using the API so much and are primarily speak VT, this is an excellent option. This flag creates a clear distinction between the two when running in a pty.

@zadjii-msft commented on GitHub (Jul 22, 2019): woah this thread got pretty out of hand over the weekend. The stars aligned Friday, and I actually got a chance to play around with implementing a passthrough mode for conpty. I'm pretty happy with how it works so far, so I think it needs a spec and some polish, and maybe we can ship it one day. Here's the approach I've been taking: * I introduced a new `ENABLE_PASSTHROUGH_MODE` to the `SetConsoleMode` flags. * When a commandline application enables passthrough mode, and the console is currently attached to a terminal (it's in conpty mode), any text they write to the console is written _straight_ to the terminal as well, with no munging by conhost. * In passthrough mode, conpty stops "rendering" any changes to its buffer. * If a commandline application knows it's not going to be doing anything with the console API, it can safely set passthrough mode to be able to talk directly to the terminal. * [NOT DONE YET] If a commandline app in passthrough mode tries to call any API's, we'll either: - Convert the effects of that API call to VT, and pass that through to the terminal. We'll do this for API's where this is reasonable - `SetConsoleTextAttribute` is a good example. - For some APIs where the terminal doesn't _really_ matter, we'll just keep doing what we're currently doing (case in point `GetConsoleProcessList`). - For APIs that don't make sense for conhost to be able to respond in passthrough mode, or we can't create a VT sequence to perform the requested operation, we'll return `E_UNSUPPORTED_API` (or a real error) indicating that API isn't supported in passthrough mode. Case in point: `ReadConsoleOutput*`, `ScrollConsoleScreenBuffer`, `SetConsoleDisplayMode`, etc. - Since the client app was updated to _add_ support for passthrough mode, it should be able to be updated to handle this error case as well. * conhost _also_ processes the strings that a commandline app emitted. This is to _try_ and keep conpty's state in sync. This is important for the following. * When a client app exits passthrough mode, there's a chance that the terminal is in a torn state from the conpty. Case in point, if `cmd.exe` launched `wsl.exe`, and `wsl` enabled passthrough, did some stuff, then `wsl` exited, and `cmd` restored the console back to non-passthrough mode (as it needs to use the API). When passthrough mode is exited, conpty will redraw its screen, to re-sync the terminal to what conpty believes the buffer looks like. - For things like just launching wsl.exe or ssh.exe directly, or for mintty, this won't be as important, as the client will always be in passthrough mode, and the conpty will never "exit" passthrough. This provides a way where we can be sure that apps that _weren't_ updated for running in a pty will still have access to the entire console API, but apps that want to live in the new world can say "I promise I know what I'm doing", and run even smoother in conpty. I believe there's going to be an _incredibly small_ intersection of apps that want to use VT and also call things like `ReadConsoleOutput`. Most apps are wither going to be console-like, using the API heavily, and might not be as likely to be updated for such a mode. However, for \*nix-like apps that _aren't_ going to be using the API so much and are primarily speak VT, this is an excellent option. This flag creates a clear distinction between the two when running in a pty.

claunia commented

@mintty commented on GitHub (Jul 22, 2019):

This sounds like an excellent plan, and thanks for caring about mintty.
From the description of the [not done yet] item, I guess even the following use case might work: A terminal runs wsl.exe through a pipe, and in the WSL session the user invokes cmd.exe...

@mintty commented on GitHub (Jul 22, 2019): This sounds like an excellent plan, and thanks for caring about mintty. From the description of the [not done yet] item, I guess even the following use case might work: A terminal runs wsl.exe through a pipe, and in the WSL session the user invokes cmd.exe...

claunia commented

@mcpiroman commented on GitHub (Jul 22, 2019):

Indeed sounds good. My points:

It seems like we can change the meaning of passthrough mode from "I won't use any of Console API" to "I won't use any of bizzare Console API functions that aren't convertible to VT or otherwise easliy handleable like GetConsoleProcessList". The list of such functions will go to docs.microsoft.com.
Actually the passthrough mode could be assumed by default and ConPTY can be lazily enabled. So if user runs a command line program and the program starts writting text/vt (or use sane API functions), conhost would then just pass them through and record changes, like @zadjii-msft described. But if it sudenly uses insane API function (e.g. it's shell and it launched a program that does so), then conhost would fallback to current behaviour with ConPTY, also like described above:

When passthrough mode is exited, conpty will redraw its screen, to re-sync the terminal to what conpty believes the buffer looks like.

This would make appropriate applications work with passthrough mode without any modifications.

In case of wsl or alike called directly, where they will always be in passthrough mode, then conhost wouldn't need to record the state. So if the terminal launches wsl and it says "I will ever use passthrough mode", then the terminal can say to system that he doesn't need ConPTY, becouse the app it launched will never use it. If on the other hand the terminal launches cmd which launches wsl it won't do that, becouse now wsl isn't the process that he [the terminal] launched, but some child process of it.
Conhost would then just read from one pipe and pass that to other, which could be further optimised, but it would probably need to sit there to handle signal pipe.

@mcpiroman commented on GitHub (Jul 22, 2019): Indeed sounds good. My points: - It seems like we can change the meaning of passthrough mode from "I won't use any of Console API" to "I won't use any of bizzare Console API functions that aren't convertible to VT or otherwise easliy handleable like `GetConsoleProcessList`". The list of such functions will go to docs.microsoft.com. - Actually the passthrough mode could be assumed by default and ConPTY can be lazily enabled. So if user runs a command line program and the program starts writting text/vt (or use `sane` API functions), conhost would then just pass them through and record changes, like @zadjii-msft described. But if it sudenly uses `insane` API function (e.g. it's shell and it launched a program that does so), then conhost would fallback to current behaviour with ConPTY, also like described above: > When passthrough mode is exited, conpty will redraw its screen, to re-sync the terminal to what conpty believes the buffer looks like. This would make appropriate applications work with passthrough mode without any modifications. - In case of `wsl` or alike called directly, where they will always be in passthrough mode, then conhost wouldn't need to record the state. So if the terminal launches `wsl` and it says "I will ever use passthrough mode", then the terminal can say to system that he doesn't need ConPTY, becouse the app it launched will never use it. If on the other hand the terminal launches `cmd` which launches `wsl` it won't do that, becouse now `wsl` isn't the process that he [the terminal] launched, but some child process of it. Conhost would then just read from one pipe and pass that to other, which could be further optimised, but it would probably need to sit there to handle signal pipe.

claunia commented

@mintty commented on GitHub (Sep 1, 2019):

I'd like to ask about progress in this issue.
Recent "WSL 2" mode (currently under evaluation in the Windows Insider program) appears to be incompatible with previous workarounds to run WSL properly from terminal environments. This makes the need for conpty passthrough mode more urgent and it would be highly appreciable to have it available before the release of WSL 2 mode into the main Windows branch.

@mintty commented on GitHub (Sep 1, 2019): I'd like to ask about progress in this issue. Recent "WSL 2" mode (currently under evaluation in the Windows Insider program) appears to be incompatible with previous workarounds to run WSL properly from terminal environments. This makes the need for conpty passthrough mode more urgent and it would be highly appreciable to have it available before the release of WSL 2 mode into the main Windows branch.

claunia commented

@DHowett-MSFT commented on GitHub (Sep 2, 2019):

@mintty WSL 2 doesn’t change anything about how WSL instances are hosted in consoles, so it’s very unlikely that passthrough mode would help. What specific issue are you seeing?

@DHowett-MSFT commented on GitHub (Sep 2, 2019): @mintty WSL 2 doesn’t change anything about how WSL instances are hosted in consoles, so it’s very unlikely that passthrough mode would help. What specific issue are you seeing?

claunia commented

@mintty commented on GitHub (Sep 2, 2019):

Without conpty, bash.exe or wsl.exe do not work well if connected directly to a pty or pipe. Previous wrappers like winpty or wslbridge work around that by running their backend in a hidden virtual console from which they grab output, poke input, mediate signal handling etc. This does not seem to work with WSL 2.
Conpty has the capability to replace this wrapping function, but it enforces its own terminal model which is not desirable in this scenario.

@mintty commented on GitHub (Sep 2, 2019): Without conpty, `bash.exe` or `wsl.exe` do not work well if connected directly to a pty or pipe. Previous wrappers like `winpty` or `wslbridge` work around that by running their backend in a hidden virtual console from which they grab output, poke input, mediate signal handling etc. This does not seem to work with WSL 2. Conpty has the capability to replace this wrapping function, but it enforces its own terminal model which is not desirable in this scenario.

claunia commented

@DHowett-MSFT commented on GitHub (Sep 3, 2019):

Previous wrappers ... work around that by running their backend in a hidden virtual console from which they ...

That 100% should still work today. Those are powered by the ReadConsoleOutput API, which we cannot break.

WSL2 doesn't change anything about how WSL instances are hosted in consoles. Any change in behavior there is absolutely a bug that we should fix before 20H1, but this feature request isn't the appropriate place to discuss that.

Since nobody here can reproduce this particular failure, can you please file a detailed bug report on what you're seeing? What wrapper, what version of Windows, what is happening and what should be happening?

@DHowett-MSFT commented on GitHub (Sep 3, 2019): > Previous wrappers ... work around that by running their backend in a hidden virtual console from which they ... That 100% should still work today. Those are powered by the `ReadConsoleOutput` API, which we cannot break. WSL2 doesn't change anything about how WSL instances are hosted in consoles. Any change in behavior there is absolutely a bug that we should fix before 20H1, but this feature request isn't the appropriate place to discuss that. Since nobody here can reproduce this particular failure, can you please file a detailed bug report on what you're seeing? What wrapper, what version of Windows, _what is happening_ and _what should be happening_?

claunia commented

@mintty commented on GitHub (Sep 3, 2019):

The wrapper does not actually use ReadConsoleOutput, so maybe it's proper to still discuss that here;
it's https://github.com/rprichard/wslbridge/, called from a cygwin terminal.
Its connection to WSL seems to be based on CreatePipe.

@mintty commented on GitHub (Sep 3, 2019): The wrapper does not actually use `ReadConsoleOutput`, so maybe it's proper to still discuss that here; it's https://github.com/rprichard/wslbridge/, called from a cygwin terminal. Its connection to WSL seems to be based on `CreatePipe`.

claunia commented

@zadjii-msft commented on GitHub (Sep 3, 2019):

For the record, I prototyped passthrough mode about a month ago. I had quite a fair amount of success with it, and I felt pretty happy with the prototype. You can check out the prototype on this branch (fair warning - it's quite a bit out-of-date).

What are the next steps here?

A full spec needs to be written to formalize what passthough mode means. I mostly want to address what happens when applications call APIs other than just read/write on the console - which APIs will we be translating straight to VT, or will we just fail all of them? This is likely going to be the longest part of the process.
We'll need to review and approve the spec. Because this is affecting conhost and the Console API surface, we'll probably need slightly more formality to this than our typical spec reviews.
We'll then need to polish the implementation to match the spec and add tests. Again, because this is part of an inbox API, we'll probably need to sync this to the Windows dev cycle to get it checked it. This we on the console team will have very little control over.

To be 100% transparent, it's not being looked at for the 20H1 release.

Because passthrough mode is not going to be a timely solution to the WSL2 issue that @mintty mentions, we should fork a thread for that discussion, to debug and understand what's wrong.

@zadjii-msft commented on GitHub (Sep 3, 2019): For the record, I prototyped passthrough mode about a month ago. I had quite a fair amount of success with it, and I felt pretty happy with the prototype. You can check out the prototype on [this branch](https://github.com/microsoft/terminal/tree/dev/migrie/f/passthrough-2019) (fair warning - it's quite a bit out-of-date). What are the next steps here? * A full spec needs to be written to formalize what passthough mode means. I mostly want to address what happens when applications call APIs other than just read/write on the console - which APIs will we be translating straight to VT, or will we just fail all of them? This is likely going to be the longest part of the process. * We'll need to review and approve the spec. Because this is affecting conhost and the Console API surface, we'll probably need slightly more formality to this than our typical spec reviews. * We'll then need to polish the implementation to match the spec and add tests. Again, because this is part of an inbox API, we'll probably need to sync this to the Windows dev cycle to get it checked it. This _we on the console team_ will have very little control over. To be 100% transparent, it's not being looked at for the 20H1 release. <hr> Because passthrough mode is _not_ going to be a timely solution to the WSL2 issue that @mintty mentions, we should fork a thread for that discussion, to debug and understand what's wrong.

claunia commented

@be5invis commented on GitHub (Sep 14, 2019):

conhost also processes the strings that a commandline app emitted. This is to try and keep conpty's state in sync. This is important for the following.

I think we should ask the CONPTY consumer to implement this -- so CONHOST could completely get rid of the character matrix in the passthrough mode.
If the consumer doesn’t implement this then CONHOST should reject entering passthrough mode.

@be5invis commented on GitHub (Sep 14, 2019): > conhost also processes the strings that a commandline app emitted. This is to try and keep conpty's state in sync. This is important for the following. I think we should ask the CONPTY consumer to implement this -- so CONHOST could completely get rid of the character matrix in the passthrough mode. If the consumer doesn’t implement this then CONHOST should reject entering passthrough mode.

claunia commented

@DHowett-MSFT commented on GitHub (Sep 14, 2019):

There is no standard provision for a VT application to read back the buffer. Asking a terminal emulator to handle it is asking a lot of Terminal developers.
Consider that you wouldn’t be able to ssh to windows unless you were using a terminal emulator that supported readback.

@DHowett-MSFT commented on GitHub (Sep 14, 2019): There is no standard provision for a VT application to read back the buffer. Asking a terminal emulator to handle it is asking a lot of Terminal developers. Consider that you wouldn’t be able to _ssh to windows_ unless you were using a terminal emulator that supported readback.

claunia commented

@DHowett-MSFT commented on GitHub (Sep 14, 2019):

(@be5invis: you are basically asking us to create a new API that will force all terminal developers to support legacy windows console behaviors. That’s just not likely to happen, and nobody would be willing to support it.)

@DHowett-MSFT commented on GitHub (Sep 14, 2019): (@be5invis: you are basically asking us to create a _new API_ that will _force all terminal developers_ to support legacy windows console behaviors. That’s just not likely to happen, and nobody would be willing to support it.)

claunia commented

@be5invis commented on GitHub (Sep 14, 2019):

@DHowett-MSFT
Well the “new API” is one-shot: only when CONHOST switch back to traditional mode, this API would be called once to read what the current application renders.
A terminal developer can choose not to implement this — and CONHOST would disable passthrough mode in this case.

@be5invis commented on GitHub (Sep 14, 2019): @DHowett-MSFT Well the “new API” is one-shot: only when CONHOST switch back to traditional mode, this API would be called once to read what the current application renders. A terminal developer can choose not to implement this — and CONHOST would disable passthrough mode in this case.

claunia commented

@mcpiroman commented on GitHub (Sep 14, 2019):

@be5invis @DHowett-MSFT
I understand it this way so that conhost starts in passthrough mode by default and doesn't record changes that passes through it. If app starts to use the insane, inconvertible-to-vt API functions, then conhost asks the terminal to get its current state (like buffer) and exits passthrough mode.
If a terminal doesn't support the get current state function, then conhost has to record the changes that passes through it, so when it eventually exits passthrough mode it is in the same state as terminal.

@mcpiroman commented on GitHub (Sep 14, 2019): @be5invis @DHowett-MSFT I understand it this way so that conhost starts in passthrough mode by default and doesn't record changes that passes through it. If app starts to use the insane, inconvertible-to-vt API functions, then conhost asks the terminal to get its current state (like buffer) and exits passthrough mode. If a terminal doesn't support the `get current state` function, then conhost has to record the changes that passes through it, so when it eventually exits passthrough mode it is in the same state as terminal.

claunia commented

@mintty commented on GitHub (Sep 14, 2019):

@be5invis : Ah, now I understand the proposal. What, for comparison, about my previous proposal to run a hidden/dummy console in parallel, so you're always prepared for this case and don't need to disable passthrough?

@mintty commented on GitHub (Sep 14, 2019): @be5invis : Ah, now I understand the proposal. What, for comparison, about my previous proposal to run a hidden/dummy console in parallel, so you're always prepared for this case and don't need to disable passthrough?

claunia commented

@christianparpart commented on GitHub (Sep 15, 2019):

Hey ConPTY devs,

First, many thanks for this API, this is a huge step forward. I actually came here because I am developing my own terminal emulator, and mainly while being on my windows machine - until I realized that it was eating my VT sequences.

So I am very happy to read that there is indeed a strong motivation to implement a pass through mode.

What is actually needed for me to get my hands dirty early with this mode? As all this eating makes it basically impossible to debug my own code via ConPTY. I am not really a Win32-dev, so please go easy on me. ;)

Thanks you.

@christianparpart commented on GitHub (Sep 15, 2019): Hey ConPTY devs, First, many thanks for this API, this is a huge step forward. I actually came here because I am developing my own terminal emulator, and mainly while being on my windows machine - until I realized that it was eating my VT sequences. So I am very happy to read that there is indeed a strong motivation to implement a pass through mode. What is actually needed for me to get my hands dirty early with this mode? As all this eating makes it basically impossible to debug my own code via ConPTY. I am not really a Win32-dev, so please go easy on me. ;) Thanks you.

claunia commented

@davidhewitt commented on GitHub (Dec 3, 2019):

Thanks to everyone working on this! I've been hoping to see this for some time, so very excited to see progress!

Actually the passthrough mode could be assumed by default and ConPTY can be lazily enabled.

I just wanted to weigh in that passthrough-by-default seems highly desirable to me.

If I'm reading right, passthrough will result in faster and better rendering (e.g. resolves #405) more or less universally. The only downside is that it would break compatibility with some console APIs (which cross-platform VT-based apps will not need).

So it seems to me that a good balance would be:

By default apps run in passthrough. If an app uses an incompatible console API then switch to conpty mode.
Apps could ensure better performance / rendering by calling SetConsoleMode to explicitly enable passthrough mode. In this state, calling unsupported APIs will result in an unsupported error.
Apps could also call SetConsoleMode to explicitly disable passthrough mode. They might want to do this on startup so they can safely use incompatible APIs without causing a mode switch & redraw during program operation.

Also some interesting questions which just struck me:

what happens if a child process which inherits the parent's console attempts to enable passthrough mode, but the parent depends on incompatible APIs?
if a child process disables/enables passthrough mode and then exits, should the previous mode be restored once the child process exits?

@davidhewitt commented on GitHub (Dec 3, 2019): Thanks to everyone working on this! I've been hoping to see this for some time, so very excited to see progress! > Actually the passthrough mode could be assumed by default and ConPTY can be lazily enabled. I just wanted to weigh in that passthrough-by-default seems highly desirable to me. If I'm reading right, passthrough will result in faster and better rendering (e.g. resolves #405) more or less universally. The only downside is that it would break compatibility with some console APIs (which cross-platform VT-based apps will not need). So it seems to me that a good balance would be: - By default apps run in passthrough. If an app uses an incompatible console API then switch to conpty mode. - Apps could ensure better performance / rendering by calling `SetConsoleMode` to explicitly enable passthrough mode. In this state, calling unsupported APIs will result in an unsupported error. - Apps could also call `SetConsoleMode` to explicitly disable passthrough mode. They might want to do this on startup so they can safely use incompatible APIs without causing a mode switch & redraw during program operation. Also some interesting questions which just struck me: - what happens if a child process which inherits the parent's console attempts to enable passthrough mode, but the parent depends on incompatible APIs? - if a child process disables/enables passthrough mode and then exits, should the previous mode be restored once the child process exits?

claunia commented

@davidhewitt commented on GitHub (Dec 9, 2019):

A further thought: will the hosting terminal emulators be able to query if the pseudoconsole is in passthrough mode? This might be needed, for example when the window resizes:

If it is in passthrough, then the terminal emulator should perform text reflow when the window resizes
If it is not in passthrough, then ConPTY will perfom text reflow (so the terminal emulator should not)

@davidhewitt commented on GitHub (Dec 9, 2019): A further thought: will the hosting terminal emulators be able to query if the pseudoconsole is in passthrough mode? This might be needed, for example when the window resizes: - If it is in passthrough, then the terminal emulator should perform text reflow when the window resizes - If it is not in passthrough, then ConPTY will perfom text reflow (so the terminal emulator should not)

claunia commented

@christianparpart commented on GitHub (Dec 9, 2019):

I think if the terminal emulators request a ConPTY and state whether or not
to to get pass through mode, then the terminal emulator already knows what
to do in such circumstances.

On Mon, 9 Dec 2019, 06:51 David Hewitt notifications@github.com wrote:

A further thought: will the hosting terminal emulators be able to query if
the pseudoconsole is in passthrough mode? This might be needed, for example
when the window resizes:

If it is in passthrough, then the terminal emulator should perform
text reflow when the window resizes

If it is not in passthrough, then ConPTY will perfom text reflow (so
the terminal emulator should not)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/1173?email_source=notifications&email_token=AAAN3O2FBNHB5LIVP5O22FDQXXMHZA5CNFSM4HWHDMHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGH5QDA#issuecomment-563075084,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAN3OYWW4ENVN5F3DALG4TQXXMHZANCNFSM4HWHDMHA
.

@christianparpart commented on GitHub (Dec 9, 2019): I think if the terminal emulators request a ConPTY and state whether or not to to get pass through mode, then the terminal emulator already knows what to do in such circumstances. On Mon, 9 Dec 2019, 06:51 David Hewitt <notifications@github.com> wrote: > A further thought: will the hosting terminal emulators be able to query if > the pseudoconsole is in passthrough mode? This might be needed, for example > when the window resizes: > > - If it is in passthrough, then the terminal emulator should perform > text reflow when the window resizes > - If it is not in passthrough, then ConPTY will perfom text reflow (so > the terminal emulator should not) > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/1173?email_source=notifications&email_token=AAAN3O2FBNHB5LIVP5O22FDQXXMHZA5CNFSM4HWHDMHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGH5QDA#issuecomment-563075084>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAN3OYWW4ENVN5F3DALG4TQXXMHZANCNFSM4HWHDMHA> > . >

claunia commented

@davidhewitt commented on GitHub (Dec 9, 2019):

I think if the terminal emulators request a ConPTY and state whether or not
to to get pass through mode, then the terminal emulator already knows what
to do in such circumstances.

Sure; however it sounded to me like for the solution proposed here the commandline app would request passthrough mode, rather than the terminal emulator. So the terminal emulator would have no knowledge of whether passthrough mode is enabled.

@davidhewitt commented on GitHub (Dec 9, 2019): >I think if the terminal emulators request a ConPTY and state whether or not to to get pass through mode, then the terminal emulator already knows what to do in such circumstances. Sure; however it sounded to me like for the solution proposed here the commandline app would request passthrough mode, rather than the terminal emulator. So the terminal emulator would have no knowledge of whether passthrough mode is enabled.

claunia commented

@christianparpart commented on GitHub (Dec 9, 2019):

IMHO it doesn't make sense for the app (running inside a terminal emulator)
to request passthrough mode but the terminal emulator, the one to interpret
the VT sequences, must see the VT sequences as equivalent as possible to
what the app produced. ?The problem with ConPTY is, that it is going to
reimplement every single VT sequence out there, and it lags behind. Hence,
terminal emulator writers where reporting bugs (or missing features), and
the best way to work around that is to "just pass all VT sequences through
"as-is"", eliminating a whole range of issues within ConPTY, and thus,
giving the terminal emulator the chance to actually see what the apps
produce, and render that.

The app inside any terminal emulator, while it should know when it is going
to be resized, should not care about what terminal emulator of
man-in-the-middle (conpty) it is running in. Do you agree?

Am Mo., 9. Dez. 2019 um 08:51 Uhr schrieb David Hewitt <
notifications@github.com>:

I think if the terminal emulators request a ConPTY and state whether or not
to to get pass through mode, then the terminal emulator already knows what
to do in such circumstances.

Sure; however it sounded to me like for the solution proposed here the
commandline app would request passthrough mode, rather than the terminal
emulator. So the terminal emulator would have no knowledge of whether
passthrough mode is enabled.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/1173?email_source=notifications&email_token=AAAN3OYOEQS5Q5RM5ORTTG3QXX2G7A5CNFSM4HWHDMHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGIF25I#issuecomment-563109237,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAN3O4XF6KLNQELYXBXMJLQXX2G7ANCNFSM4HWHDMHA
.

@christianparpart commented on GitHub (Dec 9, 2019): IMHO it doesn't make sense for the app (running inside a terminal emulator) to request passthrough mode but the terminal emulator, the one to interpret the VT sequences, must see the VT sequences as equivalent as possible to what the app produced. ?The problem with ConPTY is, that it is going to reimplement every single VT sequence out there, and it lags behind. Hence, terminal emulator writers where reporting bugs (or missing features), and the best way to work around that is to "just pass all VT sequences through \"as-is\"", eliminating a whole range of issues within ConPTY, and thus, giving the terminal emulator the chance to actually see what the apps produce, and render that. The app inside any terminal emulator, while it should know when it is going to be resized, should not care about what terminal emulator of man-in-the-middle (conpty) it is running in. Do you agree? Am Mo., 9. Dez. 2019 um 08:51 Uhr schrieb David Hewitt < notifications@github.com>: > I think if the terminal emulators request a ConPTY and state whether or not > to to get pass through mode, then the terminal emulator already knows what > to do in such circumstances. > > Sure; however it sounded to me like for the solution proposed here the > commandline app would request passthrough mode, rather than the terminal > emulator. So the terminal emulator would have no knowledge of whether > passthrough mode is enabled. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/1173?email_source=notifications&email_token=AAAN3OYOEQS5Q5RM5ORTTG3QXX2G7A5CNFSM4HWHDMHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGIF25I#issuecomment-563109237>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAN3O4XF6KLNQELYXBXMJLQXX2G7ANCNFSM4HWHDMHA> > . >

claunia commented

@DHowett-MSFT commented on GitHub (Dec 9, 2019):

@christianparpart sometimes, there are no VT sequences coming out of an application. The Windows Console APIs are not implemented using VT sequences.
The application must request passthrough mode to tell the console that it will not use one of the APIs that cannot be translated into VT sequences.

The terminal cannot set passthrough mode because it cannot force legacy applications to become compatible with VT sequences.

This is why ConPTY exists.

@DHowett-MSFT commented on GitHub (Dec 9, 2019): @christianparpart sometimes, there _are_ no VT sequences coming out of an application. The Windows Console APIs are not implemented using VT sequences. The application must request passthrough mode to tell the console that it will not use one of the APIs that cannot be translated into VT sequences. The terminal cannot set passthrough mode because it cannot force legacy applications to become compatible with VT sequences. This is why ConPTY exists.

claunia commented

2026-01-30 22:30:23 +00:00

@ExE-Boss commented on GitHub (Dec 9, 2019):

For a terminal, whether conhost is in ConPTY or passthrough mode should be irrelevant, because the terminal application will just receive VT sequences through the PTY pipe.

@ExE-Boss commented on GitHub (Dec 9, 2019): For a terminal, whether conhost is in ConPTY or passthrough mode should be irrelevant, because the terminal application will just receive VT sequences through the PTY pipe.

claunia commented

@davidhewitt commented on GitHub (Dec 9, 2019):

For a terminal, whether conhost is in ConPTY or passthrough mode should be irrelevant, because the terminal application will just receive VT sequences through the PTY pipe.

That's my point; it's not irrelevant in certain edge cases. For example when the window resizes: at the moment ConPTY reflows its buffer and sends the terminal emulator instructions to redraw everything. In passthrough mode this won't happen, so the terminal emulator will have to do reflow itself.

@davidhewitt commented on GitHub (Dec 9, 2019): > > > For a terminal, whether conhost is in ConPTY or passthrough mode should be irrelevant, because the terminal application will just receive VT sequences through the PTY pipe. That's my point; it's not irrelevant in certain edge cases. For example when the window resizes: at the moment ConPTY reflows its buffer and sends the terminal emulator instructions to redraw everything. In passthrough mode this won't happen, so the terminal emulator will have to do reflow itself.

claunia commented

2026-01-30 22:30:23 +00:00

@davidhewitt commented on GitHub (Dec 9, 2019):

Idea: Perhaps an OSC escape sequence could be sent by conhost to inform the terminal emulator that conhost is entering / exiting passthrough mode?

@davidhewitt commented on GitHub (Dec 9, 2019): Idea: Perhaps an `OSC` escape sequence could be sent by conhost to inform the terminal emulator that conhost is entering / exiting passthrough mode?

claunia commented

2026-01-30 22:30:23 +00:00

@mintty commented on GitHub (Dec 9, 2019):

The terminal cannot set passthrough mode because it cannot force legacy applications to become compatible with VT sequences.

No, the use case is a terminal running a specific backend, particularly WSL, so it knows the client will use VT mode and passthrough is needed to give it full functionality.

... when the window resizes: at the moment ConPTY reflows its buffer and sends the terminal emulator instructions to redraw everything. In passthrough mode this won't happen, so the terminal emulator will have to do reflow itself.

The terminal would "normally" notify the pty about changed terminal size. The pty would then send a SIGWINCH signal to the client application. ConPTY should handle this signal forwarding somehow. Then the client application can redraw itself.

@mintty commented on GitHub (Dec 9, 2019): > The terminal cannot set passthrough mode because it cannot force legacy applications to become compatible with VT sequences. No, the use case is a terminal running a specific backend, particularly WSL, so it knows the client will use VT mode and passthrough is needed to give it full functionality. > ... when the window resizes: at the moment ConPTY reflows its buffer and sends the terminal emulator instructions to redraw everything. In passthrough mode this won't happen, so the terminal emulator will have to do reflow itself. The terminal would "normally" notify the pty about changed terminal size. The pty would then send a SIGWINCH signal to the client application. ConPTY should handle this signal forwarding somehow. Then the client application can redraw itself.

claunia commented

2026-01-30 22:30:24 +00:00

@davidhewitt commented on GitHub (Dec 9, 2019):

No, the use case is a terminal running a specific backend, particularly WSL, so it knows the client will use VT mode and passthrough is needed to give it full functionality.

I disagree. Knowledge that passthrough is needed for full functionality would be better written once in the client app (e.g. wsl.exe) than in every terminal emulator which wants to host WSL.

The terminal would "normally" notify the pty about changed terminal size. The pty would then send a SIGWINCH signal to the client application. ConPTY should handle this signal forwarding somehow. Then the client application can redraw itself.

Agreed (I think it might already send this signal?). But I'm not talking about SIGWINCH here. I'm talking about the terminal emulator's own text layout & redraw, such as wrapping overflowing lines. At the moment ConPTY does line wrapping on its internal buffer and sends VT output to the emulator on how to draw the wrapped text. In passthrough mode the emulator will get unwrapped text and need to wrap it itself.

@davidhewitt commented on GitHub (Dec 9, 2019): > No, the use case is a terminal running a specific backend, particularly WSL, so it knows the client will use VT mode and passthrough is needed to give it full functionality. I disagree. Knowledge that passthrough is needed for full functionality would be better written once in the client app (e.g. `wsl.exe`) than in every terminal emulator which wants to host WSL. > The terminal would "normally" notify the pty about changed terminal size. The pty would then send a SIGWINCH signal to the client application. ConPTY should handle this signal forwarding somehow. Then the client application can redraw itself. Agreed (I think it might already send this signal?). But I'm not talking about SIGWINCH here. I'm talking about the terminal emulator's own text layout & redraw, such as wrapping overflowing lines. At the moment ConPTY does line wrapping on its internal buffer and sends VT output to the emulator on how to draw the wrapped text. In passthrough mode the emulator will get unwrapped text and need to wrap it itself.

claunia commented

2026-01-30 22:30:24 +00:00

@miniksa commented on GitHub (Aug 12, 2021):

I started on a prototype of a flavor of passthrough mode for Fix-Hack-Learn week approximately a week or two ago.

In this prototype... I did not have the clients elect in or out. If they used VT straight on Write/ReadConsole/File... it was just plain old VT straight through to Terminal. If they used the classic APIs... I did best-effort at quick-translating them without simulating the world.

It's an attempt to be a compromise of performance and compatibility. I basically wrote thin translation layers for each of the classic Console APIs into the nearest VT sequences possible and made up answers for those that didn't have translations. It works pretty OK for CMD.exe and WSL.exe at the end of the hack. Powershell less well because it has a readline thing I need to debug out of it. But it showed promise.

I had it configured as a thing that we could let a user specify from the top in their Terminal profile so we could have it experimental to refine it over time and learn what all the edge cases are through usage.

One big thing of note is that it doesn't have wrong-way support (readback from output buffer or write to input buffer), but @zadjii-msft had an idea for at least the readback one.

I hope to put this behind a feature key and an experimental Terminal profile setting and bring it into at least the Terminal Preview and Terminal Dev branches in the next few weeks so everyone can try it and get a better idea of what it can and cannot do. Then we should be more informed on whether my idea was good... whether we need a different approach... or at least how far away we are from implementing a passthrough.

@miniksa commented on GitHub (Aug 12, 2021): I started on a prototype of a flavor of passthrough mode for Fix-Hack-Learn week approximately a week or two ago. In this prototype... I did not have the clients elect in or out. If they used VT straight on Write/ReadConsole/File... it was just plain old VT straight through to Terminal. If they used the classic APIs... I did best-effort at quick-translating them without simulating the world. It's an attempt to be a compromise of performance and compatibility. I basically wrote thin translation layers for each of the classic Console APIs into the nearest VT sequences possible and made up answers for those that didn't have translations. It works pretty OK for CMD.exe and WSL.exe at the end of the hack. Powershell less well because it has a readline thing I need to debug out of it. But it showed promise. I had it configured as a thing that we could let a user specify from the top in their Terminal profile so we could have it experimental to refine it over time and learn what all the edge cases are through usage. One big thing of note is that it doesn't have wrong-way support (readback from output buffer or write to input buffer), but @zadjii-msft had an idea for at least the readback one. I hope to put this behind a feature key and an experimental Terminal profile setting and bring it into at least the Terminal Preview and Terminal Dev branches in the next few weeks so everyone can try it and get a better idea of what it can and cannot do. Then we should be more informed on whether my idea was good... whether we need a different approach... or at least how far away we are from implementing a passthrough.

claunia commented

2026-01-30 22:30:25 +00:00

@zadjii-msft commented on GitHub (Aug 12, 2021):

One big thing of note is that it doesn't have wrong-way support (readback from output buffer or write to input buffer), but @zadjii-msft had an idea for at least the readback one.

In short: even in passthrough mode, we maintain the buffer internally in ConPTY. We write write's out to the terminal immediately, but also queue them up to write to the internal buffer. We could process that queue on another thread or something. This would unblock the IO thread immediately, allowing for more writes, but if someone wants to read back the buffer, then we can just flush those queued writes, then reply back with the actual contents of the buffer.

@zadjii-msft commented on GitHub (Aug 12, 2021): > One big thing of note is that it doesn't have wrong-way support (readback from output buffer or write to input buffer), but @zadjii-msft had an idea for at least the readback one. In short: even in passthrough mode, we maintain the buffer internally in ConPTY. We write write's out to the terminal immediately, but also queue them up to write to the internal buffer. We could process that queue on another thread or something. This would unblock the IO thread immediately, allowing for more writes, but if someone wants to read back the buffer, then we can just flush those queued writes, then reply back with _the actual contents of the buffer_.

claunia commented

2026-01-30 22:30:25 +00:00

@oising commented on GitHub (Aug 14, 2021):

Nice! So I might be able to reanimate my half-baked project to write a screen/tmux app in pure dotnet :) I had started writing it a couple of years ago before I fully understood conpty model.

@oising commented on GitHub (Aug 14, 2021): Nice! So I might be able to reanimate my half-baked project to write a screen/tmux app in pure dotnet :) I had started writing it a couple of years ago before I fully understood conpty model.

claunia commented

2026-01-30 22:30:26 +00:00

@mintty commented on GitHub (Aug 15, 2021):

I hope to put this behind a feature key and an experimental Terminal profile setting

Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications.

@mintty commented on GitHub (Aug 15, 2021): > I hope to put this behind a feature key and an experimental Terminal profile setting Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications.

claunia commented

2026-01-30 22:30:26 +00:00

@zadjii-msft commented on GitHub (Aug 16, 2021):

Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications.

We're actually hoping to make it more magic than that. Right now, the plan is to throw it behind the experimental setting in the Terminal, and have it apply automatically to whatever client application is connected. Hopefully, if we can get all the kinks worked out, we'll probably just get rid of the experimental setting entirely, and just have it enabled by default. Client apps won't ever need to even know that this is functionality that exists, it should just work.

@zadjii-msft commented on GitHub (Aug 16, 2021): > Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications. We're actually hoping to make it more magic than that. Right now, the plan is to throw it behind the experimental setting _in the Terminal_, and have it apply automatically to whatever client application is connected. Hopefully, if we can get all the kinks worked out, we'll probably just get rid of the experimental setting entirely, and just have it enabled by default. Client apps won't ever need to even know that this is functionality that exists, it should _just work_.

claunia commented

2026-01-30 22:30:26 +00:00

@davidhewitt commented on GitHub (Aug 16, 2021):

That's really cool! I'd love to understand the steps required for alternative terminal implementations such as alacritty to try this out and give feedback once the initial implementation becomes available.

@davidhewitt commented on GitHub (Aug 16, 2021): That's really cool! I'd love to understand the steps required for alternative terminal implementations such as alacritty to try this out and give feedback once the initial implementation becomes available.

claunia commented

@DHowett commented on GitHub (Aug 16, 2021):

I hope to put this behind a feature key and an experimental Terminal profile setting

Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications.

Terminal is a great place for us to test things that impact the console infrastructure before rolling them out to a place where they will impact the billions of daily conhost sessions. Putting something behind an experimental opt-in for Terminal isn't a statement, implicit or explicit, that it's always going to be ~~there~~ WT-exclusive (NOTE: edited for clarity) or that it's going to be quasi-proprietary.

We aren't fighting progress by locking people into Windows Terminal. We're not that Microsoft.

@DHowett commented on GitHub (Aug 16, 2021): > > I hope to put this behind a feature key and an experimental Terminal profile setting > > > > Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications. Terminal is a great place for us to test things that impact the console infrastructure before rolling them out to a place where they will impact the billions of daily conhost sessions. Putting something behind an experimental opt-in for Terminal isn't a statement, implicit or explicit, that it's always going to be ~there~ WT-exclusive (NOTE: edited for clarity) or that it's going to be quasi-proprietary. We aren't fighting progress by locking people into Windows Terminal. We're not _that_ Microsoft.

claunia commented

@miniksa commented on GitHub (Aug 17, 2021):

I hope to put this behind a feature key and an experimental Terminal profile setting

Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications.

This option is still on the table depending on the outcome of the experiment. It was Fix Hack Learn week. I still don't fully understand the ramifications of all the decisions I made in this hack, so we could very well decide to make it an opt-in toggle at the end of this road.

I hope to put this behind a feature key and an experimental Terminal profile setting

Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications.

Terminal is a great place for us to test things that impact the console infrastructure before rolling them out to a place where they will impact the billions of daily conhost sessions. Putting something behind an experimental opt-in for Terminal isn't a statement, implicit or explicit, that it's always going to be ~~there~~ WT-exclusive (NOTE: edited for clarity) or that it's going to be quasi-proprietary.

We aren't fighting progress by locking people into Windows Terminal. We're not that Microsoft.

Agree. I'm using Terminal Experiments as a safe space to put a change that folks can opt into, receive in a convenient GitHub or Store delivered mechanism, and provide ample feedback before we lock a full plan and ingest into Windows. We have several orders of magnitude more freedom to add/remove and deliver in the Terminal package (especially the Dev branch) than we do in Windows. There is also no set timeline for this to happen, so we're not going to rush it.

I just decided to use this to have fun on the open hack week. I want to be open and clear with everyone about what it is so they can try it out and prove me fortunately correct or terribly wrong... then go from there.

@miniksa commented on GitHub (Aug 17, 2021): > > I hope to put this behind a feature key and an experimental Terminal profile setting > > Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications. This option is still on the table depending on the outcome of the experiment. It was Fix Hack Learn week. I still don't fully understand the ramifications of all the decisions I made in this hack, so we could very well decide to make it an opt-in toggle at the end of this road. > > > I hope to put this behind a feature key and an experimental Terminal profile setting > > > > > > Please don't do that magic kind of stuff. A simple API call (like the one to enable ConPTY) should be sufficient in order to faciliate seamless feature usage for applications. > > Terminal is a great place for us to test things that impact the console infrastructure before rolling them out to a place where they will impact the billions of daily conhost sessions. Putting something behind an experimental opt-in for Terminal isn't a statement, implicit or explicit, that it's always going to be ~there~ WT-exclusive (NOTE: edited for clarity) or that it's going to be quasi-proprietary. > > We aren't fighting progress by locking people into Windows Terminal. We're not _that_ Microsoft. Agree. I'm using Terminal Experiments as a safe space to put a change that folks can opt into, receive in a convenient GitHub or Store delivered mechanism, and provide ample feedback before we lock a full plan and ingest into Windows. We have several orders of magnitude more freedom to add/remove and deliver in the Terminal package (especially the Dev branch) than we do in Windows. There is also no set timeline for this to happen, so we're not going to rush it. I just decided to use this to have fun on the open hack week. I want to be open and clear with everyone about what it is so they can try it out and prove me fortunately correct or terribly wrong... then go from there.

claunia commented

@BrianInglis commented on GitHub (Aug 20, 2021):

They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma.

Just as an FYI mintty is a port of putty to Cygwin using Windows API, which has added VT graphics and xterm extensions including Tek4010 and DEC ReGis sixel support and probably others.

@BrianInglis commented on GitHub (Aug 20, 2021): > They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma. Just as an FYI mintty is a port of putty to Cygwin using Windows API, which has added VT graphics and xterm extensions including Tek4010 and DEC ReGis sixel support and probably others.

claunia commented

@christianparpart commented on GitHub (Aug 20, 2021):

They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma.

Just as an FYI mintty is a port of putty to Cygwin using Windows API, which has added VT graphics and xterm extensions including Tek4010 and DEC ReGis sixel support and probably others.

What does this FYI add to the topic of ConPTY passthrough? Putty (and forks) work as ssh(/telnet/other-lines) clients and do not handle local processes, unless something has changed since I last used these. As such application you have 100% control over the communication line and it's easy to add things to hat ConPTY does not support. This is incomparable.

@christianparpart commented on GitHub (Aug 20, 2021): > > They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma. > > Just as an FYI mintty is a port of putty to Cygwin using Windows API, which has added VT graphics and xterm extensions including Tek4010 and DEC ReGis sixel support and probably others. What does this FYI add to the topic of ConPTY passthrough? Putty (and forks) work as ssh(/telnet/other-lines) clients and do not handle local processes, unless something has changed since I last used these. As such application you have 100% control over the communication line and it's easy to add things to hat ConPTY does not support. This is incomparable.

claunia commented

@BrianInglis commented on GitHub (Aug 21, 2021):

They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma.

Just as an FYI mintty is a port of putty to Cygwin using Windows API, which has added VT graphics and xterm extensions including Tek4010 and DEC ReGis sixel support and probably others.

What does this FYI add to the topic of ConPTY passthrough? Putty (and forks) work as ssh(/telnet/other-lines) clients and do not handle local processes, unless something has changed since I last used these. As such application you have 100% control over the communication line and it's easy to add things to hat ConPTY does not support. This is incomparable.

The mintty port talks to the conhost via Cygwin pty and Cygwin console drivers, or WSL console interfaces using wslbridge-{cygwin-frontend,linux-backend}, and uses Windows text/graphics rendering APIs with charset conversion where required, so transparent passthru supporting alternative non-"ANSI"/xterm-compatible graphic terminal modes are desirable.
Screen/Tmux/SSH/X/Windows console (including cmd /c commands and batch/cmd and PowerShell scripts) and GUI apps may also be run (launched for Windows GUI and locally or remotely for X) from the console(s) in the mintty terminal window(s).

@BrianInglis commented on GitHub (Aug 21, 2021): > > > They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma. > > > > > > Just as an FYI mintty is a port of putty to Cygwin using Windows API, which has added VT graphics and xterm extensions including Tek4010 and DEC ReGis sixel support and probably others. > > What does this FYI add to the topic of ConPTY passthrough? Putty (and forks) work as ssh(/telnet/other-lines) clients and do not handle local processes, unless something has changed since I last used these. As such application you have 100% control over the communication line and it's easy to add things to hat ConPTY does not support. This is incomparable. The mintty port talks to the conhost via Cygwin pty and Cygwin console drivers, or WSL console interfaces using wslbridge-{cygwin-frontend,linux-backend}, and uses Windows text/graphics rendering APIs with charset conversion where required, so transparent passthru supporting alternative non-"ANSI"/xterm-compatible graphic terminal modes are desirable. Screen/Tmux/SSH/X/Windows console (including cmd /c commands and batch/cmd and PowerShell scripts) and GUI apps may also be run (launched for Windows GUI and locally or remotely for X) from the console(s) in the mintty terminal window(s).

claunia commented

@christianparpart commented on GitHub (Aug 21, 2021):

Thanks, @BrianInglis :)

@christianparpart commented on GitHub (Aug 21, 2021): Thanks, @BrianInglis :)

claunia commented

@csdvrx commented on GitHub (Sep 27, 2021):

They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma.

Just as an FYI mintty is a port of putty to Cygwin using Windows API, which has added VT graphics and xterm extensions including Tek4010 and DEC ReGis sixel support and probably others.

mintty is no longer just a simple port of putty: in practice, these various additions make it better than xterm for most common day uses

@csdvrx commented on GitHub (Sep 27, 2021): > > They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma. > > Just as an FYI mintty is a port of putty to Cygwin using Windows API, which has added VT graphics and xterm extensions including Tek4010 and DEC ReGis sixel support and probably others. mintty is no longer just a simple port of putty: in practice, these various additions make it better than xterm for most common day uses

claunia commented

@zadjii-msft commented on GitHub (Nov 4, 2022):

Note to self: Although this was experimentally added a while ago, I think Niksa's intention was to keep both this thread and #10001 open in parallel. There's a LONG way to go before experimental.connection.passthroughMode is ready for daily driving, and I'm not sure if we've got a good mental framework for figuring out if that will be the satisfactory conclusion to this thread (#1173)

@zadjii-msft commented on GitHub (Nov 4, 2022): Note to self: Although this was experimentally added a while ago, I think Niksa's intention was to keep both this thread and #10001 open in parallel. There's a LONG way to go before `experimental.connection.passthroughMode` is ready for daily driving, and I'm not sure if we've got a good mental framework for figuring out if that will be the satisfactory conclusion to this thread (#1173)

claunia commented

@mintty commented on GitHub (Nov 4, 2022):

I have just submitted microsoft/WSL#9117 as I felt for the main use case of "passthrough mode", Windows Terminal is the wrong domain in the first place. There should be a decoupled WSL launcher, like wsl.exe but without any bundled Windows Terminal functionality, in order to support full VT-like connectivity.

@mintty commented on GitHub (Nov 4, 2022): I have just submitted microsoft/WSL#9117 as I felt for the main use case of "passthrough mode", Windows Terminal is the wrong domain in the first place. There should be a decoupled WSL launcher, like wsl.exe but without any bundled Windows Terminal functionality, in order to support full VT-like connectivity.

claunia commented

@DHowett commented on GitHub (Nov 4, 2022):

This is also the repository for the Windows Console Subsystem, and given the breadth of applications that want to run on Windows and emit/receive plain VT it is entirely within our charter.

@DHowett commented on GitHub (Nov 4, 2022): This is also the repository for the Windows Console Subsystem, and given the breadth of applications that want to run on Windows and emit/receive plain VT it is _entirely_ within our charter.

claunia commented

@palves commented on GitHub (Jun 21, 2023):

Hi! I got here because I've been working on running the GDB (GNU Debugger) testsuite on Windows. The GDB testsuite uses DejaGnu, which is based on Expect. My plan is to have DejaGnu ssh into the Windows machine, and run GDB there. This is something that has been working fine on Linux for decades. On Windows, with the new Virtual Console support, it sounds like exactly what we'd need to make it work on Windows as well, and be able to auto test GDB in an environment that behaves like a regular console environment. However, the fact that ConPTY is not passthrough makes it still unworkable, unfortunately. Let me explain a little.

For example, this is the output DejaGnu sees when connected to GDB on Linux (with TERM=dumb):

...
For help, type "help".\r\n
Type "apropos word" to search for commands related to "word".\r\n
(gdb) set height 0\r\n
(gdb)

And this is what DejaGnu sees when connected to GDB on Windows (via Windows 10's built-in SSH)

 ...
 $ c:/gdb/build-windows/gdb/.libs/gdb.exe -q\r\n
 (gdb) s\r(gdb) set height 0\r\n
 (gdb) \x1b[12X

The odd line redraw in the first "(gdb)" line, and the extra escape sequences after the second prompt make this totally unworkable, because the testsuite is built on matching GDB output, and it isn't expecting any redraws or escape sequences (unless GDB sent them, e.g., for color, in which case the test will match them).

I am hoping that a passthrough mode would make the Windows output more like Linux one.

Can someone let me know what is the current status of passthrough mode, and how would one enable it? Is there some undocumented flag I can make GDB pass to SetConsoleMode, perhaps?

@palves commented on GitHub (Jun 21, 2023): Hi! I got here because I've been working on running the GDB (GNU Debugger) testsuite on Windows. The GDB testsuite uses DejaGnu, which is based on Expect. My plan is to have DejaGnu ssh into the Windows machine, and run GDB there. This is something that has been working fine on Linux for decades. On Windows, with the new Virtual Console support, it sounds like exactly what we'd need to make it work on Windows as well, and be able to auto test GDB in an environment that behaves like a regular console environment. However, the fact that ConPTY is not passthrough makes it still unworkable, unfortunately. Let me explain a little. For example, this is the output DejaGnu sees when connected to GDB on Linux (with TERM=dumb): ``` ... For help, type "help".\r\n Type "apropos word" to search for commands related to "word".\r\n (gdb) set height 0\r\n (gdb) ``` And this is what DejaGnu sees when connected to GDB on Windows (via Windows 10's built-in SSH) ``` ... $ c:/gdb/build-windows/gdb/.libs/gdb.exe -q\r\n (gdb) s\r(gdb) set height 0\r\n (gdb) \x1b[12X ``` The odd line redraw in the first "(gdb)" line, and the extra escape sequences after the second prompt make this totally unworkable, because the testsuite is built on matching GDB output, and it isn't expecting any redraws or escape sequences (unless GDB sent them, e.g., for color, in which case the test will match them). I am hoping that a passthrough mode would make the Windows output more like Linux one. Can someone let me know what is the current status of passthrough mode, and how would one enable it? Is there some undocumented flag I can make GDB pass to SetConsoleMode, perhaps?

claunia commented

@lhecker commented on GitHub (Jun 21, 2023):

Windows Terminal Preview has a hidden setting for this. If you open the settings.json file via the "Open JSON file" button in the settings tab, you can add this:

"experimental.connection.passthroughMode": true,

to any of your profiles including the "defaults". Afterwards you'll have to create a new instance/tab of that profile. If you use PowerShell you'll notice fairly quickly that it works, because output will be severely broken.

Passthrough mode is something that must be done at some point or another (the "rendering" that ConPTY does is effectively a hack and would require constant maintenance forever if we kept it), but right now it's not anywhere near useable yet. Its implementation is simply incomplete, and its current approach might not even be the right one. I personally hope that we could tackle that issue soon, but realistically (and frankly) speaking we're not staffed enough to do that in the near term. There's a significant interest in other features like session restore, Unicode, image support, "sudo", font fallback, tmux, and many many more and it's not quite clear what issue deserves attention the most. Put differently, while I'm personally interested in solving this, the reality is that this issue and any of those that would be fixed by it don't even show up in the first 2 pages sorted by 👍.
To summarize: I'm sure we'll get to it, but just not right now. Sorry for the ramblings... 🙁

@lhecker commented on GitHub (Jun 21, 2023): Windows Terminal Preview has a hidden setting for this. If you open the settings.json file via the "Open JSON file" button in the settings tab, you can add this: ```json "experimental.connection.passthroughMode": true, ``` to any of your profiles including the "defaults". Afterwards you'll have to create a new instance/tab of that profile. If you use PowerShell you'll notice fairly quickly that it works, because output will be severely broken. Passthrough mode is something that must be done at some point or another (the "rendering" that ConPTY does is effectively a hack and would require constant maintenance forever if we kept it), but right now it's not anywhere near useable yet. Its implementation is simply incomplete, and its current approach might not even be the right one. I personally hope that we could tackle that issue soon, but realistically (and frankly) speaking we're not staffed enough to do that in the near term. There's a significant interest in other features like session restore, Unicode, image support, "sudo", font fallback, tmux, and many many more and it's not quite clear what issue deserves attention the most. Put differently, while I'm personally interested in solving this, the reality is that this issue and any of those that would be fixed by it don't even show up in the first 2 pages sorted by 👍. To summarize: I'm sure we'll get to it, but just not right now. Sorry for the ramblings... 🙁

claunia commented

@BrianInglis commented on GitHub (Jun 21, 2023):

You could consider Cygwin project mintty/wsltty originally derived from putty with serial support converted to Cygwin pty interfacing with Windows ConHost/ConPTY (or WSL over wslbridge/wslbridge2) running Cygwin and most Windows terminal shells.
Its adaptations and many configuration settings plus support for Cygwin screen/tmux and ssh may allow you to do what you need.
The current developer @mintty is responsive and helpful.

@BrianInglis commented on GitHub (Jun 21, 2023): You could consider *Cygwin* project [`mintty`/`wsltty`](https://en.wikipedia.org/wiki/Mintty) originally derived from `putty` with serial support converted to *Cygwin* `pty` interfacing with *Windows* `ConHost`/`ConPTY` (or *WSL* over `wslbridge`/`wslbridge2`) running *Cygwin* and most *Windows* terminal shells. Its adaptations and many configuration settings plus support for *Cygwin* `screen`/`tmux` and `ssh` may allow you to do what you need. The current developer @mintty is responsive and helpful.

claunia commented

2026-01-30 22:30:30 +00:00

@DHowett commented on GitHub (Jun 21, 2023):

I am hoping that a passthrough mode would make the Windows output more like Linux one.

At the core of this issue is a misunderstanding--on the part of the Win32-OpenSSH folks--of what it means to request a tty.

Even on Linux (supersets and derivatives), spawning GDB or any other application with a controlling terminal runs the risk of that application deciding that it should emit control sequences. This often happens even when TERM is set to dumb. A bunch of applications just check isatty(3) rather than consulting TERM!

On Windows, the equivalent of spawning a controlling terminal is establishing a pseudoconsole/console hosting session. sshd on Windows requests a console hosting session even where one would not be appropriate.

sshd on Windows should not be allocating a pty to host things for which sshd on Linux/BSD would not allocate a pty¹. That would get ConPTY and its rendering logic entirely out of the loop, and give you stdin/stdout from the spawned process directly and unmodified.

such as when ssh is used in a pipeline or not itself connected to a tty/pty :) ↩︎

@DHowett commented on GitHub (Jun 21, 2023): > I am hoping that a passthrough mode would make the Windows output more like Linux one. At the core of this issue is a misunderstanding--on the part of the Win32-OpenSSH folks--of what it means to request a tty. Even on Linux (supersets and derivatives), spawning GDB or any other application with a controlling terminal runs the risk of that application deciding that it should emit control sequences. This often happens even when `TERM` is set to `dumb`. A bunch of applications just check `isatty(3)` rather than consulting `TERM`! On Windows, the equivalent of spawning a controlling terminal is establishing a pseudoconsole/console hosting session. `sshd` on Windows requests a console hosting session _even where one would not be appropriate_. `sshd` on Windows should not be allocating a pty to host things for which `sshd` on Linux/BSD would not allocate a pty[^1]. That would get ConPTY and its rendering logic _entirely_ out of the loop, and give you stdin/stdout from the spawned process directly and unmodified. [^1]: such as when ssh is used in a pipeline or not _itself_ connected to a tty/pty :)

claunia commented

@palves commented on GitHub (Jun 21, 2023):

sshd on Windows should not be allocating a pty to host things for which sshd on Linux/BSD would not allocate a pty.
That would get ConPTY and its rendering logic entirely out of the loop, and give you stdin/stdout from the spawned
process directly and unmodified.

That is essentially what you get with "ssh -T", but it's not what I need -- I really need for GDB to be connected to a pty, not just a plain pipe, so that input works as if on a terminal, like cursor keys, and sending ctrl-c.

@palves commented on GitHub (Jun 21, 2023): > sshd on Windows should not be allocating a pty to host things for which sshd on Linux/BSD would not allocate a pty. > That would get ConPTY and its rendering logic entirely out of the loop, and give you stdin/stdout from the spawned > process directly and unmodified. That is essentially what you get with "ssh -T", but it's not what I need -- I really need for GDB to be connected to a pty, not just a plain pipe, so that input works as if on a terminal, like cursor keys, and sending ctrl-c.

claunia commented

2026-01-30 22:30:30 +00:00

@DHowett commented on GitHub (Jun 21, 2023):

Interesting. That makes sense; thanks for explaining it :)

@DHowett commented on GitHub (Jun 21, 2023): _Interesting._ That makes sense; thanks for explaining it :)

claunia commented

2026-01-30 22:30:30 +00:00

@palves commented on GitHub (Jun 21, 2023):

Windows Terminal Preview has a hidden setting for this. If you open the settings.json file via the "Open JSON file"
button in the settings tab, you can add this:

"experimental.connection.passthroughMode": true,

Ah, thanks. I read https://github.com/microsoft/terminal/pull/11264/files and saw that that is plumbed down to a PSEUDOCONSOLE_PASSTHROUGH_MODE flag passed to the Virtual Console creation. Since I need it with ssh, I guess sshd would have to have its own way to enable this.

So it is not possible to activate the passthrough mode from the command line application itself, like how you pass ENABLE_VIRTUAL_TERMINAL_PROCESSING to SetConsoleMode ? I.e., something like a ENABLE_VIRTUAL_TERMINAL_PASSTHROUGH flag GDB itself could enable in SetConsoleMode? Is that something that you envision would be possible if/when this work is eventually completed?

@palves commented on GitHub (Jun 21, 2023): > Windows Terminal Preview has a hidden setting for this. If you open the settings.json file via the "Open JSON file" > button in the settings tab, you can add this: > > "experimental.connection.passthroughMode": true, Ah, thanks. I read https://github.com/microsoft/terminal/pull/11264/files and saw that that is plumbed down to a PSEUDOCONSOLE_PASSTHROUGH_MODE flag passed to the Virtual Console creation. Since I need it with ssh, I guess sshd would have to have its own way to enable this. So it is not possible to activate the passthrough mode from the command line application itself, like how you pass ENABLE_VIRTUAL_TERMINAL_PROCESSING to SetConsoleMode ? I.e., something like a ENABLE_VIRTUAL_TERMINAL_PASSTHROUGH flag GDB itself could enable in SetConsoleMode? Is that something that you envision would be possible if/when this work is eventually completed?

claunia commented

@BatmanAoD commented on GitHub (Jun 22, 2023):

Other terminals, such as Wezterm, also need a way to enable this option.

@BatmanAoD commented on GitHub (Jun 22, 2023): Other terminals, [such as Wezterm](https://github.com/wez/wezterm/issues/1673#issuecomment-1054311400), also need a way to enable this option.

claunia commented

@mintty commented on GitHub (Jun 22, 2023):

Other terminals also need a way to enable this option.

Yes, and that makes me repeat that this is actually not a Microsoft Terminal issue but a feature needed for the WSL launcher, wsl.exe, which should have a decoupled mode to not capture any terminal interaction; see https://github.com/microsoft/WSL/issues/9117

@mintty commented on GitHub (Jun 22, 2023): > Other terminals also need a way to enable this option. Yes, and that makes me repeat that this is actually not a Microsoft Terminal issue but a feature needed for the WSL launcher, wsl.exe, which should have a decoupled mode to not capture any terminal interaction; see https://github.com/microsoft/WSL/issues/9117

claunia commented

@j4james commented on GitHub (Jun 22, 2023):

@mintty As has already been mentioned above, this is also the repository for the console subsystem, which underlies all console applications - that includes both Windows applications and WSL applications. And the whole point of conpty is to translate the Windows console APIs into VT sequences. WSL has got nothing to do with that. Windows Terminal has got nothing to do with that either, but it happens to share the same repository.

@BatmanAoD It's worth noting that any terminals that want to use this option would likely need to work on their VT support first. To translate Windows console APIs into equivalent VT sequences without a local buffer (which is a requirement for pass-through mode), we'll likely need VT features like rectangular area operations, which aren't that widely supported.

@j4james commented on GitHub (Jun 22, 2023): @mintty As has already been mentioned above, this is also the repository for the console subsystem, which underlies _all_ console applications - that includes both Windows applications and WSL applications. And the whole point of conpty is to translate the Windows console APIs into VT sequences. WSL has got nothing to do with that. Windows Terminal has got nothing to do with that either, but it happens to share the same repository. @BatmanAoD It's worth noting that any terminals that want to use this option would likely need to work on their VT support first. To translate Windows console APIs into equivalent VT sequences without a local buffer (which is a requirement for pass-through mode), we'll likely need VT features like rectangular area operations, which aren't that widely supported.

claunia commented

@mintty commented on GitHub (Jun 22, 2023):

the whole point of conpty is to translate the Windows console APIs into VT sequences.
WSL has got nothing to do with that.

Yes, but wsl.exe does, unfortunately, as it intercepts and filters terminal interaction. It shouldn't, in a passthrough mode, that's my point, not really caring about the underlying architecture.

@mintty commented on GitHub (Jun 22, 2023): > the whole point of conpty is to translate the Windows console APIs into VT sequences. > WSL has got nothing to do with that. Yes, but wsl.exe does, unfortunately, as it intercepts and filters terminal interaction. It shouldn't, in a passthrough mode, that's my point, not really caring about the underlying architecture.

claunia commented

@ferdinandyb commented on GitHub (Jul 6, 2023):

Put differently, while I'm personally interested in solving this, the reality is that this issue and any of those that would be fixed by it don't even show up in the first 2 pages sorted by 👍. To summarize: I'm sure we'll get to it, but just not right now.

I've been browsing issues and wanted to point out, that sorted by 👍, the third issue is sixels where @j4james said, that

We either need the full passthrough mode working, or for the conpty renderer to be capable of regenerating the sixel on the fly so it can repaint areas of the screen that have been invalidated. Of the two, passthrough mode seems more feasible.

so it seems to me that there's at least one high profile issue that would be solved by this, and I wouldn't be surprised if there were more highly voted issues where this would be the solution (I'm guessing a lot of people are like me: not knowing much about terminal internals, just wanting a WSL terminal to feel like they are on a linux box).

@ferdinandyb commented on GitHub (Jul 6, 2023): > Put differently, while I'm personally interested in solving this, the reality is that this issue and any of those that would be fixed by it don't even show up in the first 2 pages sorted by 👍. To summarize: I'm sure we'll get to it, but just not right now. I've been browsing issues and wanted to point out, that sorted by 👍, the third issue is sixels where @j4james [said](https://github.com/microsoft/terminal/issues/448#issuecomment-1116601091), that > We either need the full passthrough mode working, or for the conpty renderer to be capable of regenerating the sixel on the fly so it can repaint areas of the screen that have been invalidated. Of the two, passthrough mode seems more feasible. so it seems to me that there's at least one high profile issue that would be solved by this, and I wouldn't be surprised if there were more highly voted issues where this would be the solution (I'm guessing a lot of people are like me: not knowing much about terminal internals, just wanting a WSL terminal to feel like they are on a linux box).

claunia commented

@BrianInglis commented on GitHub (Jul 6, 2023):

xterm implements almost all of the 700+ documented ECMA, VT, ANSI, and X control sequences, and is available under MIT/X permissive licences: so just "Use the Source Luke!"

@BrianInglis commented on GitHub (Jul 6, 2023): [`xterm`](https://invisible-island.net/archives/xterm/?C=M;O=D) implements [almost all of the 700+](https://invisible-island.net/xterm/xterm.faq.html#compare_versions) documented ECMA, VT, ANSI, and X control sequences, and is available under MIT/X permissive licences: so just "Use the Source Luke!"

claunia commented

@jerch commented on GitHub (Jul 24, 2023):

We either need the full passthrough mode working, or for the conpty renderer to be capable of regenerating the sixel on the fly so it can repaint areas of the screen that have been invalidated. Of the two, passthrough mode seems more feasible.

I also think that the sixel-regenerating is a dead-end in the long run creating lots of maintenance burden (you'd basically need an "image recorder" with decoding and encodings clipping viewport areas, geez) while only solving this particular sixel issue. What about other image sequences later on? What about other sequences in general? They will still fail at the "not implemented here in ConPty" trap.
On a sidenote - recently had a similar image forth and back encoding/decoding need for state serialization within xtermjs, and did not vote for sixel, but QOI (reasonably fast in wasm with good enough compression - much better than any PNG handling offered by the browser engines).

This prolly got stressed several times already - to me it seems that ConPty "puts the cart before the horse" with its interim terminal emulation to stay compatible to the far less capable WIN-console API. Wouldn't it be better to do it the other way around and to abstract the console caps into rectangular VT sequences? Yes, support is quite lousy for those across TEs, but even with scroll margins only one can simulate many aspects. I also think that TE devs would happily implement better rect support, if there is a serious need for those.

@jerch commented on GitHub (Jul 24, 2023): > We either need the full passthrough mode working, or for the conpty renderer to be capable of regenerating the sixel on the fly so it can repaint areas of the screen that have been invalidated. Of the two, passthrough mode seems more feasible. I also think that the sixel-regenerating is a dead-end in the long run creating lots of maintenance burden (you'd basically need an "image recorder" with decoding and encodings clipping viewport areas, geez) while only solving this particular sixel issue. What about other image sequences later on? What about other sequences in general? They will still fail at the "not implemented here in ConPty" trap. On a sidenote - recently had a similar image forth and back encoding/decoding need for state serialization within xtermjs, and did not vote for sixel, but QOI (reasonably fast in wasm with good enough compression - much better than any PNG handling offered by the browser engines). This prolly got stressed several times already - to me it seems that ConPty "puts the cart before the horse" with its interim terminal emulation to stay compatible to the far less capable WIN-console API. Wouldn't it be better to do it the other way around and to abstract the console caps into rectangular VT sequences? Yes, support is quite lousy for those across TEs, but even with scroll margins only one can simulate many aspects. I also think that TE devs would happily implement better rect support, if there is a serious need for those.

claunia commented

@j4james commented on GitHub (Jul 24, 2023):

it seems that ConPty "puts the cart before the horse" with its interim terminal emulation to stay compatible to the far less capable WIN-console API. Wouldn't it be better to do it the other way around and to abstract the console caps into rectangular VT sequences?

@jerch I've been pushing for this for a while, and I think it's probably the right long term solution, but the current conpty approach was most definitely the correct decision at the time, and it may well remain the most practical solution for a long time.

The Windows console API has a lot more functionality than your average VT terminal, and even with the most advanced VT capabilities there will likely be things we just can't reproduce. To be honest, the more time I spend looking at this, the less convinced I am that it's worth the effort.

@j4james commented on GitHub (Jul 24, 2023): > it seems that ConPty "puts the cart before the horse" with its interim terminal emulation to stay compatible to the far less capable WIN-console API. Wouldn't it be better to do it the other way around and to abstract the console caps into rectangular VT sequences? @jerch I've been pushing for this for a while, and I think it's probably the right long term solution, but the current conpty approach was most definitely the correct decision at the time, and it may well remain the most practical solution for a long time. The Windows console API has a lot more functionality than your average VT terminal, and even with the most advanced VT capabilities there will likely be things we just can't reproduce. To be honest, the more time I spend looking at this, the less convinced I am that it's worth the effort.

claunia commented

@mintty commented on GitHub (Jul 25, 2023):

Windows console API has a lot more functionality

You mean like reading back the screen contents? An exotic feature rarely useful and certainly not relevant in the WSL domain.

less convinced I am that it's worth the effort

That's why I had tried to drag this discussion over to a WSL issue. For the Windows Terminal application, it may be dispensible to provide terminal transparency as it's a terminal itself. For WSL however, there is serious need for transparent terminal access, both local and remote, so passthrough mode without any Windows console legacy burden is essential for the WSL launcher.

@mintty commented on GitHub (Jul 25, 2023): > Windows console API has a lot more functionality You mean like reading back the screen contents? An exotic feature rarely useful and certainly not relevant in the WSL domain. > less convinced I am that it's worth the effort That's why I had tried to drag this discussion over to a WSL issue. For the Windows Terminal application, it may be dispensible to provide terminal transparency as it's a terminal itself. For WSL however, there is serious need for transparent terminal access, both local and remote, so passthrough mode without any Windows console legacy burden is essential for the WSL launcher.

claunia commented

@christianparpart commented on GitHub (Jul 25, 2023):

The Windows console API has a lot more functionality than your average VT terminal, and even with the most advanced VT capabilities there will likely be things we just can't reproduce

@j4james hey, I am curious to know what Windows console API offers that doesn't exist as VT sequence or extension just yet. OTOH, I think if one can count the number of features that are available on the conhost side but not on the VT side, it might make sense to introduce VT sequence extensions for those few and still put conhost on top of VT. I do not want to mandate here anything, I am just curious to know what conhost is more advanced in. :)

On the "your average VT terminal" argument, I'd love to bring some of my main features of contour to Windows, which I can't until either ConPTY supports them, or a passthrough mode is available. currently my windows version of Contour will always be inferior than on other platforms, sadly. Not sure how to solve this without ConPTY passthrough in the future :)

@christianparpart commented on GitHub (Jul 25, 2023): > The Windows console API has a lot more functionality than your average VT terminal, and even with the most advanced VT capabilities there will likely be things we just can't reproduce @j4james hey, I am curious to know what Windows console API offers that doesn't exist as VT sequence or extension just yet. OTOH, I think if one can count the number of features that are available on the conhost side but not on the VT side, it might make sense to introduce VT sequence extensions for those few and still put conhost on top of VT. I do not want to mandate here anything, I am just curious to know what conhost is more advanced in. :) On the "your average VT terminal" argument, I'd love to bring some of my main features of contour to Windows, which I can't until either ConPTY supports them, or a passthrough mode is available. currently my windows version of Contour will always be inferior than on other platforms, sadly. Not sure how to solve this without ConPTY passthrough in the future :)

claunia commented

@jerch commented on GitHub (Jul 25, 2023):

@christianparpart I think the buffer read caps are on the annoying side of things - as far as I remember console API allows complete buffer access (in the sense, that the console app "owns" the console and thus the buffer state). Thats almost impossible with non rect-based VT mechanics or at least will be limited to active cursor area only prolly on all TEs. I still think that most buffer access primitives could be mimicked in VT.
The hard unsolvable problem might be the exclusiveness, that console API kinda provides to apps with a quite strict process IO coupling/isolation - a thing that many ppl also wish for terminals in linux/macos, but it is just not possible there with the current TTY/PTY abstraction (though its not a matter of VT mechanics but POSIX terminal API).

@jerch commented on GitHub (Jul 25, 2023): @christianparpart I think the buffer read caps are on the annoying side of things - as far as I remember console API allows complete buffer access (in the sense, that the console app "owns" the console and thus the buffer state). Thats almost impossible with non rect-based VT mechanics or at least will be limited to active cursor area only prolly on all TEs. I still think that most buffer access primitives could be mimicked in VT. The hard unsolvable problem might be the exclusiveness, that console API kinda provides to apps with a quite strict process IO coupling/isolation - a thing that many ppl also wish for terminals in linux/macos, but it is just not possible there with the current TTY/PTY abstraction (though its not a matter of VT mechanics but POSIX terminal API).

claunia commented

@j4james commented on GitHub (Jul 25, 2023):

@j4james hey, I am curious to know what Windows console API offers that doesn't exist as VT sequence or extension just yet.

You can find a list of the console APIs here:
https://learn.microsoft.com/en-us/windows/console/console-functions

If you click through each of them, you should see a "Tip" section which explains which of them do or don't have a VT equivalent. If you think you can convert all of them into VT sequences, please do feel free to contribute PRs. A lot of the framework is already in place to do this.

it might make sense to introduce VT sequence extensions for those few

We aren't even at the point where most conpty terminals are supporting the standard VT sequences we would need. The chances of everyone agreeing to a bunch of Windows-specific extensions on top of that doesn't seem very likely.

I think what some of you really want is just a pass through mode for WSL. If that's the case, you can assumedly build your terminal as a Linux GUI app running on WSL. But ConPTY is specially for Windows console application support. If you aren't interested in that, this isn't the issue for you.

@j4james commented on GitHub (Jul 25, 2023): > @j4james hey, I am curious to know what Windows console API offers that doesn't exist as VT sequence or extension just yet. You can find a list of the console APIs here: https://learn.microsoft.com/en-us/windows/console/console-functions If you click through each of them, you should see a "Tip" section which explains which of them do or don't have a VT equivalent. If you think you can convert all of them into VT sequences, please do feel free to contribute PRs. A lot of the framework is already in place to do this. > it might make sense to introduce VT sequence extensions for those few We aren't even at the point where most conpty terminals are supporting the _standard_ VT sequences we would need. The chances of everyone agreeing to a bunch of Windows-specific extensions on top of that doesn't seem very likely. I think what some of you really want is just a pass through mode for WSL. If that's the case, you can assumedly build your terminal as a [Linux GUI app running on WSL](https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps). But ConPTY is specially for Windows console application support. If you aren't interested in that, this isn't the issue for you.

claunia commented

@palves commented on GitHub (Jul 25, 2023):

There is a set of Windows console applications that want the feature (in my case, GDB (GNU Debugger) testing), which don't need anything from the console API that the supported subset of standard VT sequences doesn't already provide. IMO, there could be a console API that such applications could call to enable some restrictive/subset of the API, only. Call it "passthrough mode", or "no intermediate buffer mode" or some such, and when that mode is active, the problematic console APIs (like complete buffer access) would just fail with an error.

@palves commented on GitHub (Jul 25, 2023): There is a set of Windows console applications that want the feature (in my case, GDB (GNU Debugger) testing), which don't need anything from the console API that the supported subset of standard VT sequences doesn't already provide. IMO, there could be a console API that such applications could call to enable some restrictive/subset of the API, only. Call it "passthrough mode", or "no intermediate buffer mode" or some such, and when that mode is active, the problematic console APIs (like complete buffer access) would just fail with an error.

claunia commented

@zadjii-msft commented on GitHub (Jul 25, 2023):

FWIW that's my preferred approach to solving this. A console mode that a client app can enable to say "I solemnly swear I am up to good". Something like WSL would opt-in, because it knows it's only ever going to do VT.

That doesn't work as well for mixed applications that want to do both. But that would let legacy console apps rely on conpty's regeneration for their own needs, and modern apps just use VT and all the new features that come with it.

@zadjii-msft commented on GitHub (Jul 25, 2023): FWIW that's my preferred approach to solving this. A console mode that a client app can enable to say "I solemnly swear I am up to good". Something like WSL would opt-in, because it knows it's only ever going to do VT. That doesn't work as well for mixed applications that want to do both. But that would let legacy console apps rely on conpty's regeneration for their own needs, and modern apps just use VT and all the new features that come with it.

claunia commented

@j4james commented on GitHub (Jul 25, 2023):

If that's the way we want to go, that's fine, but it means the Windows shells don't gain any benefit from it. For example, you wouldn't be able to TYPE a sixel file, or ECHO a Contour-specific escape sequence and expect it to work. Personally I'd consider this a waste of time, but I can accept that's all some people might care about.

@j4james commented on GitHub (Jul 25, 2023): If that's the way we want to go, that's fine, but it means the Windows shells don't gain any benefit from it. For example, you wouldn't be able to `TYPE` a sixel file, or `ECHO` a Contour-specific escape sequence and expect it to work. Personally I'd consider this a waste of time, but I can accept that's all some people might care about.

claunia commented

@jerch commented on GitHub (Jul 25, 2023):

To avoid rewriting console API into wonky VT pendants, wouldn't the following work:

make stream-IO/passthrough VT-mode default
additionally make legacy console API fully abstract on both sides (process & TE side)
a TE can decide whether to implement the legacy console primitives, if it does - processes can call into console API as before, if not - processes may not call into legacy console (may need special process flags?)
TE operates as single source of truth for console buffer primitves - its the TEs resp. to get data from its internal terminal buffer feeding the TE-side of the console API
provide a standard TE on OS side fully implementing legacy console primitives, so things like AttachConsole still works
last step - retire ConPty 😺

Ofc there are details to overcome, like the question whether the console primitives can be made blocking or need true memory sharing & possible security implications.

@jerch commented on GitHub (Jul 25, 2023): To avoid rewriting console API into wonky VT pendants, wouldn't the following work: - make stream-IO/passthrough VT-mode default - additionally make legacy console API fully abstract on both sides (process & TE side) - a TE can decide whether to implement the legacy console primitives, if it does - processes can call into console API as before, if not - processes may not call into legacy console (may need special process flags?) - TE operates as single source of truth for console buffer primitves - its the TEs resp. to get data from its internal terminal buffer feeding the TE-side of the console API - provide a standard TE on OS side fully implementing legacy console primitives, so things like `AttachConsole` still works - last step - retire ConPty :smiley_cat: Ofc there are details to overcome, like the question whether the console primitives can be made blocking or need true memory sharing & possible security implications.

claunia commented

@csdvrx commented on GitHub (Aug 1, 2023):

On a sidenote - recently had a similar image forth and back encoding/decoding need for state serialization within xtermjs, and did not vote for sixel, but QOI (reasonably fast in wasm with good enough compression - much better than any PNG handling offered by the browser engines).

@jerch , am I right to say that we had a few standards already existing (sixel, kitty, ...) and now we've got one more?

I think it's just sad that the desire for technical perfections goes before practical concerns for something that'd work about everywhere, if leveraging the existing ecosystem.

So like @j4james, I think not being able to reach some baseline level of functionality is waste of time:

If that's the way we want to go, that's fine, but it means the Windows shells don't gain any benefit from it. For example, you wouldn't be able to TYPE a sixel file, or ECHO a Contour-specific escape sequence and expect it to work. Personally I'd consider this a waste of time

Actually, I'd consider that not just a waste of time, but a sad waste of time.

@csdvrx commented on GitHub (Aug 1, 2023): > On a sidenote - recently had a similar image forth and back encoding/decoding need for state serialization within xtermjs, and did not vote for sixel, but QOI (reasonably fast in wasm with good enough compression - much better than any PNG handling offered by the browser engines). @jerch , am I right to say that we had a few standards already existing (sixel, kitty, ...) and now we've got one more? I think it's just sad that the desire for technical perfections goes before practical concerns for something that'd work about everywhere, if leveraging the existing ecosystem. So like @j4james, I think not being able to reach some baseline level of functionality is waste of time: > If that's the way we want to go, that's fine, but it means the Windows shells don't gain any benefit from it. For example, you wouldn't be able to TYPE a sixel file, or ECHO a Contour-specific escape sequence and expect it to work. Personally I'd consider this a waste of time Actually, I'd consider that not just a waste of time, but a sad waste of time.

claunia commented