-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ConPTY Passthrough mode #1173
Comments
@zadjii-msft was looking into this. The main issue, if I recall correctly, is that we need to trash the entire buffer when something enters or exits “passthrough” mode. It’s also only truly applicable when there is a connected pseudoconsole session. |
And the reason one console might enter and exit passthrough mode multiple times is that you may run Additional concerns: if you have a tree of four processes, each of which wants passthrough to be different, should the ones that are doing It’s complicated when you get into compatibility discussions. 😄 |
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. |
From #1985:
|
We need a |
This is an essential feature for opening MS text-mode software (esp. WSL) to 3rd-party environments.
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. |
Just realized #2035 is this ask framed differently.
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
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) |
@mintty |
Great. Invent a new CSI sequence for that. Send the |
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. |
The people who hate how ConPTY is implemented today will absolutely hate how it's implemented if we do that. 😁 |
They wouldn't even notice in pure pass-through applications. It might be necessary to solve an otherwise unresolvable dilemma. |
This solution makes no sense because there is no window in To the point of #2035, neither
Yes. And as a practical matter I wouldn't expect the
I think we are closer than that. If ...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 [Then we need |
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 I think you're looking to turn this request, and this project, into something it's not. You may be attempting to turn 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.
|
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. |
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:
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 |
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. |
Interesting. That makes sense; thanks for explaining it :) |
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? |
Other terminals, such as Wezterm, 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 microsoft/WSL#9117 |
@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. |
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. |
I've been browsing issues and wanted to point out, that sorted by 👍, the third issue is sixels where @j4james said, that
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). |
This comment was marked as off-topic.
This comment was marked as off-topic.
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. 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 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. |
You mean like reading back the screen contents? An exotic feature rarely useful and certainly not relevant in the WSL domain.
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. |
@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 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. |
You can find a list of the console APIs here: 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.
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. |
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. |
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. |
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 |
To avoid rewriting console API into wonky VT pendants, wouldn't the following work:
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 , 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:
Actually, I'd consider that not just a waste of time, but a sad waste of time. |
Nope, that serialization format is for TE internal usage only, not intended for outside with an explicit sequence. QOI yields the best compression/performance ratio covering RGBA in 32bit. Since xtermjs is browser based, we cannot just store raw bytes somewhere on the disk for session restore, as other desktop TEs would do here. |
what is the latest update on this? |
Modern apps won’t read the hidden character grid and do everything in VT. So why not an API/console mode to tell Console Host to completely throw away that?
The text was updated successfully, but these errors were encountered: