Repository navigation
ConPTY Passthrough mode #1173
Description
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?
Reacted by Christian Parpart, ExE Boss, David Hewitt, Lemmingh, Reilly Wood, therealkenc, gurpreetshanky, vannomad, Ami, Tag Howard and 31 more
Activity
DHowett-MSFT commentedon Jun 8, 2019
Mike Griese (@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.
DHowett-MSFT commentedon Jun 8, 2019
And the reason one console might enter and exit passthrough mode multiple times is that you may run
coolNewThing.exefrom 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
ReadConsoleOutputbe able to read the buffers from the other legacy/non-passthrough ones?It’s complicated when you get into compatibility discussions. 😄
zadjii-msft commentedon 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 commentedon Jul 16, 2019
From #1985:
[-]Give ability to let console applications to claim that it will never use Console API and do everything with VT, so Console Host can do more optimizations[/-][+]ConPTY Passthrough mode [/+]oising commentedon Jul 17, 2019
We need a
SIGWINCHasynchronous signal for resizing somehow.mintty commentedon 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 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.
83 remaining items
jerch commentedon Jul 25, 2023
Christian Parpart (@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).
j4james commentedon Jul 25, 2023
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.
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.
palves commentedon 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.
zadjii-msft commentedon 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.
j4james commentedon 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
TYPEa sixel file, orECHOa 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.jerch commentedon Jul 25, 2023
To avoid rewriting console API into wonky VT pendants, wouldn't the following work:
AttachConsolestill worksOfc there are details to overcome, like the question whether the console primitives can be made blocking or need true memory sharing & possible security implications.
csdvrx commentedon Aug 1, 2023
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 James Holderness (@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.
jerch commentedon Aug 1, 2023
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.
zadjii-msft commentedon Apr 5, 2024
Nothing to share at this time. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
☺️
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread
Add support for Sixel images in conhost (#17421)
A minor ConPTY refactoring: Goodbye VtEngine Edition (#17510)