Add support for VT100 Answerback Feature

[SteveIves]

Add support for VT100 Answerback Feature

I am attempting to use Windows Terminal to execute legacy Linux applications using WSL2, and it's great that Terminal now seems to support most VT100 features, but most of the applications I am attempting to host require the terminal to provide an "answerback message" (string) in response to an ASCII 5 character (Ctrl+E) being received by the terminal. The answerback message must be able to be defined by the user, ideally in settings UI, or at least in the settings file. I believe there is also an "auto answerback" capability, but I am unclear on exactly how that works, but do not need it for my use case.

[zadjii-msft]

Might as well, though, out of curiosity, any specific examples when you say

most of the applications I am attempting to host

I'm under the impression that the console/Terminal does a pretty good job of hosting most linux applications these days, and there aren't that many apps that actually rely on ENQ

[SteveIves]

@zadjii-msft, I work for a software tools company supporting a software development environment that has been used for 45 years to develop a significant number of "legacy" applications across all industries. While it is not the case that all such applications rely on terminal answerback, a significant portion do. Currently I am migrating a specific application for a customer, and without terminal answerback it literally won't run. We could re-engineer the code to remove this requirement, but I would consider it a win for Windows Terminal if it could support the feature. Currently we are forced to use a terminal emulator that implements full DEC VT compatibility, such as Reflections, PowerTerm or Putty. It would be a win for us if we could run our apps using native Windows tools, and we are SO CLOSE!

[j4james]

Note that if it needs to be user configurable, then we can't really implement this on the conhost side. It would have to be passed through to WT and have the answerback message configured somewhere in the settings (probably at the profile level).

One other possibility would be to support the DECLANS escape sequence for defining the answerback, and that way we could avoid having to add a setting for it. However, that could be a bit of a security risk, unless maybe limited to printable characters, and even then I'm not sure that's wise.

[j4james]

Another thought: I know we don't want to add more stuff to the legacy conhost properties dialog, but can we add new properties to the console registry area? It's obviously not very user-friendly, but it would be a quick way to get the functionality implemented on the conhost side, and then we could leave the WT settings UI until later.

[SteveIves]

@j4james For my use case, I'm totally fine if there is no UI, as long as I can specify the answerback value in a configuration file.

[j4james]

FYI, I've managed to get a basic implementation of this working (configured via the registry for conhost, and in settings.json for Windows Terminal), but there's a catch. It potentially breaks legacy console apps that depend on ASCII 5 being displayed as a printable character (namely the ♣ club suite).

I had initially thought we could work around that by treating ASCII 5 as printable when the answerback message was blank, but that won't work in Windows Terminal because of the nature of the conpty passthrough. So if we want to do this, we may need to bite the bullet and decide to drop support for printable C0 characters (essentially what was discussed in #10786).

The other option would be to wait until we have a full passthrough mode (#1173), because that would allow us to make the distinction between a printable char and the ENQ control on the WT side of the conpty connection (based on the presence of the answerback message). But that's likely to be a long way off still.

[j4james]

After playing with this for a bit, I realised there's another problem: when ENQ is combined with other VT queries, the responses can be returned out of order.

The reason this matters, is because it's common for queries like this (where you can't be sure of a response) to be followed by another query that definitely is supported. For example, you might send ENQ followed by DSR-CPR (because that's something everyone supports), so you know that anything you receive prior to the CPR report is part of the answerback message.

On Windows Terminal this won't work though. The DSR-CPR query is handled at the conhost level, while the ENQ request has to be passed through to conpty. This results in the CPR report being returned first, wrongly giving the impression that the answerback is blank.

This should eventually be addressed by the full passthrough mode (#1173), but if we don't want to wait for that, we need to accept that this query won't always work as expected. This might still be acceptable for @SteveIves' use case though.