starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Add support for VT100 Answerback Feature #16138

New Issue
Closed
opened 2026-01-31 04:58:44 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 04:58:44 +00:00
Owner
Copy Link

Originally created by @SteveIves on GitHub (Dec 15, 2021).

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.

Originally created by @SteveIves on GitHub (Dec 15, 2021). # 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.
claunia added the Help WantedProduct-ConhostIssue-TaskIn-PRArea-VTNeeds-Tag-Fix labels 2026-01-31 04:58:44 +00:00
claunia commented 2026-01-31 04:58:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 15, 2021):

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

@zadjii-msft commented on GitHub (Dec 15, 2021): 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`](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Single-character-functions)
claunia commented 2026-01-31 04:58:47 +00:00
Author
Owner
Copy Link

@SteveIves commented on GitHub (Dec 15, 2021):

@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!

@SteveIves commented on GitHub (Dec 15, 2021): @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!
claunia commented 2026-01-31 04:58:48 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 16, 2021):

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 commented on GitHub (Dec 16, 2021): 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.
claunia commented 2026-01-31 04:58:48 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 16, 2021):

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.

@j4james commented on GitHub (Dec 16, 2021): 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.
claunia commented 2026-01-31 04:58:48 +00:00
Author
Owner
Copy Link

@SteveIves commented on GitHub (Dec 16, 2021):

@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.

@SteveIves commented on GitHub (Dec 16, 2021): @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.
claunia commented 2026-01-31 04:58:48 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 28, 2021):

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 commented on GitHub (Dec 28, 2021): 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.
claunia commented 2026-01-31 04:58:48 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 28, 2021):

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.

@j4james commented on GitHub (Dec 28, 2021): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Help Wanted In-PR Issue-Task Needs-Tag-Fix Product-Conhost
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16138
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?