PowerShell is considering enabling VT support *unconditionally* in its conhost.exe sessions. Is it safe?

[mklement0]

Description of the new feature/enhancement

Note: This isn't a feature request, but since it is also isn't a bug report, I chose this issue type.

PowerShell (Core) currently selectively disables VT support for calls to external programs when running in conhost.exe windows - unless the VirtualTerminalLevel value in HKEY_CURRENT_USER\Console exists and is nonzero (this value doesn't exist by default) - while enabling support for PowerShell-native commands.

This makes for an awkward asymmetry:

• While"It ain't easy being `e[32mgreen`e[m." (a PowerShell-native command) properly renders the VT sequences,
• python -c 'print(''It ain\''t easy being \x1b[32mgreen\x1b[m.'')' does not (unless explicitly enabled via the registry)

This is non-obvious, given that the exact same string is emitted in both cases.
Currently, unless VT support is explicitly enabled via the registry, the garbled It ain't easy being ←[32mgreen←[m. prints to the console.

By contrast, Windows Terminal already has VT support enabled unconditionally.

PowerShell/PowerShell#19101 proposes making PowerShell (specifically, transiently, for its own processes and its child processes only) similarly enable VT support unconditionally.

@SteveL-MSFT wonders whether it is safe to do so:

• Does anyone anticipate any problems if this were to be done?

[DHowett]

I moved this over to discussions! Sorry, we don't have clear signposts about what does where. 😆

Once I'm back inside work hours, I'd love to write up the pitfalls we've run into doing this... and what we're looking at doing to improve the situation going forward. I've added a TODO item!

[floh96]

@DHowett Have you had time to look at this?

[mklement0]

Looking forward to the write-up.

@o-sdn-o has found this comment of yours from a while back: #6634 (comment), which - if I understand correctly - implies that Windows Terminal has already decided to break backward compatibility with legacy CLIs that rely on the ability to "print raw control characters directly to the screen", correct?

[iSazonov]

Windows Terminal has already decided to break backward compatibility

This is manifested on main page https://github.com/microsoft/terminal#the-windows-console-host

However, because Windows Console's primary goal is to maintain backward compatibility, we have been unable to add many of the features the community (and the team) have been wanting for the last several years including tabs, unicode text, and emoji.

These limitations led us to create the new Windows Terminal.

[mklement0]

Note that it also states, with respect to conhost.exe:

"Since taking ownership of the Windows command-line in 2014, the team added several new features to the Console, including background transparency, line-based selection, support for ANSI / Virtual Terminal sequences, 24-bit color, a Pseudoconsole ("ConPTY"), and more."

That, combined with the quotes from my previous comment, suggests that it is ultimately conhost.exe providing the VT rendering both in console windows and Windows Terminal.

So the question for PowerShell comes down to:

• Is not supporting legacy CLIs anymore that rely on printing raw control sequences a real-world problem in PowerShell, specifically, or does it constitute a beneficial bucket 3 change?

  • Running such CLIs without a shell or via cmd.exe will still be compatible.

• I don't know the answer, and, at least pre-Windows 11, "just use Windows Terminal" is probably not a viable solution, because you don't always get to control how a console is created.

[mklement0]

(On a side note, it seems that when I post comments they are auto-up-voted, ostensibly by me - strange...)

[zadjii-msft]

I believe that's just how GitHub Discussions works, kinda like reddit in that sense