ConPTY does not pass Device Control Strings (DCS) to 3rd-party terminals about terminal HOT 14 OPEN

Do you have a rough timeline (weeks/months/quarters) of when this might get shipped?

I think a month is a fair estimate for this. I don't think it'll take multiple months.
I'm currently working on a prototype, as well as the design spec based on that. After the design has been approved, I'll have to finish implementing the more complex parts of ConPTY within the new architecture. But if my proposal is rejected, I'll happily implement a workaround for you anyway. 🙂

from terminal.

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• ConPTY modifies escape sequences passed to process input (#12166), similarity score: 0.76
• ConPTY not emitting OSC sequences longer than 256 characters (Windows 10) (#15551), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

from terminal.

Did you use the system ConPTY API? Due to the lengthy release cycle of Windows that API is usually quite outdated. We're currently experimenting with shipping ConPTY as a nupkg. You can find a build here: https://terminalbuilds.blob.core.windows.net/builds/Microsoft.Windows.Console.ConPTY.1.19.240130002.nupkg
That's the same build that WezTerm uses. There was a discussion about it here: https://mas.to/@DHowett/111909543700190300
The .nupkg contains a prebuilt conpty.dll (= ConPTY client) as well as a v1.19 build of OpenConsole.exe (= ConPTY server).

To be fair, I haven't tried your repro, so my suggestion may be pointless. 🙈 However, even if that nupkg doesn't fix the issue, you'd still need to use a bundled OpenConsole.exe version to receive an updated version later on.

But the good news is that I'm currently working on replacing the complex ConPTY setup we have. Afterwards it'll pass VT text from your shell, etc., 1:1 directly to the terminal. The bad news is that I am currently working on it. If the above .nupkg doesn't work, and I'm not sure if you can share your timeline of shipping Warp on Windows publicly, but if it's still a while out, you could consider waiting for me to finish my work on that.

from terminal.

Hi @lhecker thanks for taking the time to respond! I'm another engineer at Warp, working with @acarl005.

Did you use the system ConPTY API?

We followed the instructions outlined in the Mastodon thread you linked but unfortunately using the newer ConPTY build does not solve the issue. Specifically, I still see that DCS strings are not getting sent from ConPTY and that the custom OSCs we use as an alternative are sent out of order.

However, even if that nupkg doesn't fix the issue, you'd still need to use a bundled OpenConsole.exe version to receive an updated version later on.

Noted! We'll ship with these newer bundles instead of relying on the system API.

Afterwards it'll pass VT text from your shell, etc., 1:1 directly to the terminal.

This is exactly what we need, looking forward to this releasing! 🥳 Many of the features we use would depend on this particular part of the PTY since we rely on it to implement many of our key features, like blocks. We can't meaningfully test most of the core functionality of Warp without this. Do you have a rough timeline (weeks/months/quarters) of when this might get shipped? Our intention is not to rush you but just to plan around it!

from terminal.

@lhecker Awesome! We're happy to hear someone is working on this. May I ask about order preservation in your planned implementation? As for Warp's requirements, we use DCS for things like delimiting our "blocks" and so ordering is an important for our case, e.g. if a process emits something like...

echo "some output `eP <some data for terminal> `e\ some other output"

...then we depend on some output ESCP <some data for terminal> ESC\ some other output to come out of the PTY.

from terminal.

@lhecker We'd also love to try out the prototype you are building, if you can easily share it! We can try it from a remote branch, a specific build, or anything else that's convenient.

from terminal.

May I ask about order preservation in your planned implementation?

If you have ENABLE_VIRTUAL_TERMINAL_PROCESSING enabled (I'm sure you do 😄), then the text will not be touched by ConPTY at all anymore. Warp will receive the VT output entirely unmodified. (It'll go through UTF-16 <> UTF-8 conversion, because our VT parser uses UTF-16, but I'm sure that's beside the point.)

We'd also love to try out the prototype you are building, if you can easily share it! We can try it from a remote branch, a specific build, or anything else that's convenient.

I'm not at a point yet where you could rely on it, but my WIP branch is here: https://github.com/microsoft/terminal/tree/dev/lhecker/goodbye-vtengine
If you'd like to try it and need help building OpenConsole and conpty.dll, let me know.

The design spec is here: https://github.com/microsoft/terminal/blob/dev/lhecker/goodbye-vtengine/doc/specs/%2313000%20-%20In-process%20ConPTY.md
This issue and your problem will be solved after Step 1 in that design doc already, so you can ignore the rest if you'd like. (Although you're likely to benefit from the remaining 3 steps, since it would significantly improve your performance.) I do have to say again though that everything within the doc still needs to go through review, nothing is final, and the entire thing or parts of it may be scrapped if we find that it's impossible to achieve.

from terminal.

@lhecker It sounds like this is essentially "passthrough mode", is that correct?

Please let us know if Warp engineers can help with this migration in any way. We would likely be able to commit at least one engineer to this effort to help get it launched.

from terminal.

@alokedesai Not in the original sense.

(Some more context for those who may not be super familiar with ConPTY's architecture:) ConPTY parses any VT output of any application and stores the results in a local buffer, so that later calls to the ReadConsole* family of functions can read that output back. This is for instance used by Far Manager to backup and restore the viewport contents.
VtRenderer is currently used to "render" those buffer contents back to VT output. This is why the order of operations is lost: VT output gets parsed, thrown away, and then regenerated.

Passthrough mode used to be the idea that we could stop parsing the VT output of any application that promises to only ever use VT and not call anything except for Read/WriteFile or Read/WriteConsole (= primitive text only). We would thus not need to transform any complex Console API calls and be able to pass the VT output directly through to the terminal. This would preserve the order of operations and increase performance, because output would not need to be parsed nor "rendered".

My upcoming proposal on the other hand is to always parse the output, despite the cost. I've improved the performance of our text buffer by >10x over the last 3 years so it's not as much of an issue anymore. My above branch for instance gets ~100MB/s with cat despite the double-parsing, which is not great, but also not terrible. This will allow us to always serve the ReadConsole* calls.
Next, my idea is to transform complex console API calls like WriteConsoleOutputCharacter into a series of VT sequences directly (purely algorithmically right within the console API implementation).
Lastly, to help terminals not be bottlenecked by the double-parsing, I'm proposing a nano-COM API for ConPTY where it runs within your process, you give it access to your buffer, and it will provide you with a genuine 0-overhead console server in exchange. Windows Terminal would use such an in-process ConPTY without double-buffering, while something like sshd would continue to use a ConPTY that keeps a buffer (since sshd runs remotely).

from terminal.