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 DECRQCRA #19514

New Issue
Closed
opened 2026-01-31 06:45:37 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 06:45:37 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Mar 9, 2023).

Description of the new feature/enhancement

DECRQCRA is an escape sequence which lets you request a checksum of a portion of the screen, and that gives you a way to read back the buffer contents. This is useful for creating automated tests that can be run on the original DEC terminals and then easily compared against our own implementation to verify that we're doing things correctly (for an example of that, see #14876).

Proposed technical implementation details (optional)

The problem with this functionality is that some people consider it a security risk. Looking at the other terminals that support this, most do seem to have it enabled by default, but some have it behind an option, and some require you to build the app yourself with a specific define enabled.

VTE and Konsole are the ones I know of that require a build-time option, XTerm and iTerm2 have a runtime option, and MLTerm, Mintty, WezTerm, RLogin, SyncTerm, and Reflection all have it enabled by default (I think - I can't rule out some of them having an option that I've forgotten about turning on).

So if we do want to support this, how do you want to handle it? I could live with a compile time option - that's at least better than merging from a stash (which is what I'm doing at the moment). A step up from that would be enabling from a registry entry - it would only apply in conhost, but that is fine for testing. My personal preference, though, would be to have it enabled all the time, but I can understand if that's not acceptable.

Originally created by @j4james on GitHub (Mar 9, 2023). # Description of the new feature/enhancement [`DECRQCRA`](https://vt100.net/docs/vt510-rm/DECRQCRA.html) is an escape sequence which lets you request a checksum of a portion of the screen, and that gives you a way to read back the buffer contents. This is useful for creating automated tests that can be run on the original DEC terminals and then easily compared against our own implementation to verify that we're doing things correctly (for an example of that, see #14876). # Proposed technical implementation details (optional) The problem with this functionality is that some people consider it a security risk. Looking at the other terminals that support this, most do seem to have it enabled by default, but some have it behind an option, and some require you to build the app yourself with a specific `define` enabled. VTE and Konsole are the ones I know of that require a build-time option, XTerm and iTerm2 have a runtime option, and MLTerm, Mintty, WezTerm, RLogin, SyncTerm, and Reflection all have it enabled by default (I think - I can't rule out some of them having an option that I've forgotten about turning on). So if we do want to support this, how do you want to handle it? I could live with a compile time option - that's at least better than merging from a stash (which is what I'm doing at the moment). A step up from that would be enabling from a registry entry - it would only apply in conhost, but that is fine for testing. My personal preference, though, would be to have it enabled all the time, but I can understand if that's not acceptable.
claunia added the Help WantedIssue-TaskIn-PRArea-VTNeeds-Tag-FixProduct-Terminal labels 2026-01-31 06:45:38 +00:00
claunia commented 2026-01-31 06:45:39 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 9, 2023):

In lieu of making a real decision - we could put it behind a feature flag, and have it enabled for Dev builds only. That would result in the code being checked in, but removed at compile time from release & preview (& inbox) builds.

as an example: Define a new flag in here. This one is the same, "Always disabled, but enabled for dev builds"

fe2220e07b/src/features.xml (L148-L156)

And use it like:
fe2220e07b/src/cascadia/TerminalApp/TerminalPage.cpp (L1252-L1259)

@zadjii-msft commented on GitHub (Mar 9, 2023): In lieu of making a real decision - we could put it behind a [feature flag](https://github.com/microsoft/terminal/blob/main/src/features.xml), and have it enabled for Dev builds only. That would result in the code being checked in, but removed at compile time from release & preview (& inbox) builds. as an example: Define a new flag in here. This one is the same, "Always disabled, but enabled for dev builds" https://github.com/microsoft/terminal/blob/fe2220e07b3b46482a34f29cc2dabea9286fd02c/src/features.xml#L148-L156 And use it like: https://github.com/microsoft/terminal/blob/fe2220e07b3b46482a34f29cc2dabea9286fd02c/src/cascadia/TerminalApp/TerminalPage.cpp#L1252-L1259
claunia commented 2026-01-31 06:45:39 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Mar 9, 2023):

You know what, that's actually perfect for my needs. 99% of the time I'm going to be using this in a dev build anyway. We can always reconsider making it more widely available in the future, but there's no urgency for that.

@j4james commented on GitHub (Mar 9, 2023): You know what, that's actually perfect for my needs. 99% of the time I'm going to be using this in a dev build anyway. We can always reconsider making it more widely available in the future, but there's no urgency for that.
claunia commented 2026-01-31 06:45:40 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Mar 10, 2023):

@al20878 When you have a chance, could you please try out this script on both your VT520 and VT525. It's a test of the DECRQCRA checksum query, which I'm assuming they interpret differently.

https://gist.github.com/j4james/efd2993f9f90b542857c7dfe3a0f2521

The way it works is it writes out a range of characters in each of the main character sets, and while it's doing so it requests a checksum of each character. It also does a couple of runs with different rendition attributes and colors.

As with the margins test, it'll probably take a couple of minutes to run. There are three screens worth of tests, but if it's going unbearably slowly, you can always break after the first (that has the most crucial tests).

The results are logged in a file named decrqcra.log, although if you run the script with a parameter like say vt520, then it'll save the log as decrqcra.vt520.log.

I'm hoping from these results that I'll be able to figure out the algorithms that the two terminals use.

@j4james commented on GitHub (Mar 10, 2023): @al20878 When you have a chance, could you please try out this script on both your VT520 and VT525. It's a test of the `DECRQCRA` checksum query, which I'm assuming they interpret differently. https://gist.github.com/j4james/efd2993f9f90b542857c7dfe3a0f2521 The way it works is it writes out a range of characters in each of the main character sets, and while it's doing so it requests a checksum of each character. It also does a couple of runs with different rendition attributes and colors. As with the margins test, it'll probably take a couple of minutes to run. There are three screens worth of tests, but if it's going unbearably slowly, you can always break after the first (that has the most crucial tests). The results are logged in a file named `decrqcra.log`, although if you run the script with a parameter like say `vt520`, then it'll save the log as `decrqcra.vt520.log`. I'm hoping from these results that I'll be able to figure out the algorithms that the two terminals use.
claunia commented 2026-01-31 06:45:40 +00:00
Author
Owner
Copy Link

@al20878 commented on GitHub (Mar 11, 2023):

could you please try out this script on both your VT520 and VT525

The logs from both, and a colorful screenshot from VT525 are attached:

decrqcra.vt520.log
decrqcra.vt525.log

VT525

Hope this helps!

@al20878 commented on GitHub (Mar 11, 2023): > could you please try out this script on both your VT520 and VT525 The logs from both, and a colorful screenshot from VT525 are attached: [decrqcra.vt520.log](https://github.com/microsoft/terminal/files/10948929/decrqcra.vt520.log) [decrqcra.vt525.log](https://github.com/microsoft/terminal/files/10948930/decrqcra.vt525.log) ![VT525](https://user-images.githubusercontent.com/44822487/224495844-f7b40832-7143-42a3-9def-2a6fa53d79c5.png) Hope this helps!
claunia commented 2026-01-31 06:45:40 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Mar 11, 2023):

Hope this helps!

@al20878 Very much so, thank you! I now know why the VT525 checksums weren't working in my margin test. The VT525 includes the color attributes in the checksum, and the base checksum is what you'd get with black text on a black background. So with a default foreground of 7, the checksums differ from the monochrome terminals by an offset of 0x70.

Also I appreciate you sharing that screenshot, because that shows some interesting aspects of the rendering that I wasn't aware of. For example, I didn't know that underlines are still shown when the invisible attribute is set. And am I correct in thinking that the dimmer sections of text were actually blinking, i.e. they're alternating between their original intesity and a dimmer version?

@j4james commented on GitHub (Mar 11, 2023): > Hope this helps! @al20878 Very much so, thank you! I now know why the VT525 checksums weren't working in my margin test. The VT525 includes the color attributes in the checksum, and the base checksum is what you'd get with black text on a black background. So with a default foreground of 7, the checksums differ from the monochrome terminals by an offset of 0x70. Also I appreciate you sharing that screenshot, because that shows some interesting aspects of the rendering that I wasn't aware of. For example, I didn't know that underlines are still shown when the invisible attribute is set. And am I correct in thinking that the dimmer sections of text were actually blinking, i.e. they're alternating between their original intesity and a dimmer version?
claunia commented 2026-01-31 06:45:40 +00:00
Author
Owner
Copy Link

@al20878 commented on GitHub (Mar 11, 2023):

And am I correct in thinking that the dimmer sections of text were actually blinking, i.e. they're alternating between their original intesity and a dimmer version?

Some of the text was blinking -- on the right half of the output, IIRC. I can take a little video with my phone, I suppose, so that you can see what's blinking and what's steady. It was actually going not so slow (and interestingly, it was much slower in a PuTTY window when I first ran the script, just to see what to expect -- and was surprised to observe it moving much faster on the real H/W).

@al20878 commented on GitHub (Mar 11, 2023): > And am I correct in thinking that the dimmer sections of text were actually blinking, i.e. they're alternating between their original intesity and a dimmer version? Some of the text was blinking -- on the right half of the output, IIRC. I can take a little video with my phone, I suppose, so that you can see what's blinking and what's steady. It was actually going not so slow (and interestingly, it was _much_ slower in a PuTTY window when I first ran the script, just to see what to expect -- and was surprised to observe it moving much faster on the real H/W).
claunia commented 2026-01-31 06:45:40 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Mar 11, 2023):

I can take a little video with my phone, I suppose, so that you can see what's blinking and what's steady.

Not to worry. At some point I would like to create a test that covers the color rendering functionality in more detail, and I may ask you to do a video then. It's not essential now, though. I was just curious because that photo looks fairly close to the current Windows Terminal implementation (video below).

https://user-images.githubusercontent.com/4181424/224516078-495a5479-62c1-4204-b4f8-27bfc9d5da0f.mp4

@j4james commented on GitHub (Mar 11, 2023): > I can take a little video with my phone, I suppose, so that you can see what's blinking and what's steady. Not to worry. At some point I would like to create a test that covers the color rendering functionality in more detail, and I may ask you to do a video then. It's not essential now, though. I was just curious because that photo looks fairly close to the current Windows Terminal implementation (video below). https://user-images.githubusercontent.com/4181424/224516078-495a5479-62c1-4204-b4f8-27bfc9d5da0f.mp4
claunia commented 2026-01-31 06:45:41 +00:00
Author
Owner
Copy Link

@al20878 commented on GitHub (Mar 11, 2023):

Not to worry.

LOL I already did: https://drive.google.com/file/d/1dTaNPfYioIxBh1JafCK93eJYXjnpok9O/view?usp=share_link
(sorry about the video to be somewhat shaky and a bit blurry)
So you can take a look there just as well :-)

But your implementation does indeed show a very similar picture (if not the same, exactly). Impressive!

@al20878 commented on GitHub (Mar 11, 2023): > Not to worry. LOL I already did: https://drive.google.com/file/d/1dTaNPfYioIxBh1JafCK93eJYXjnpok9O/view?usp=share_link (sorry about the video to be somewhat shaky and a bit blurry) So you can take a look there just as well :-) But your implementation does indeed show a very similar picture (if not the same, exactly). Impressive!
claunia commented 2026-01-31 06:45:41 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Mar 11, 2023):

LOL I already did: https://drive.google.com/file/d/1dTaNPfYioIxBh1JafCK93eJYXjnpok9O/view?usp=share_link

Thanks, I do appreciate that. As you say, it's quite similar to our implementation, but there are some aspects I'm not sure I understand correctly. Will probably be easier to see what's going on with a custom palette.

it was much slower in a PuTTY window when I first ran the script, just to see what to expect

I forgot to mention that this is quite likely because PuTTY doesn't support the DECRQCRA query. So if that's the case, the script would be blocking for 2 seconds on every character, since it's waiting for a response from the terminal that never arrives.

@j4james commented on GitHub (Mar 11, 2023): > LOL I already did: https://drive.google.com/file/d/1dTaNPfYioIxBh1JafCK93eJYXjnpok9O/view?usp=share_link Thanks, I do appreciate that. As you say, it's quite similar to our implementation, but there are some aspects I'm not sure I understand correctly. Will probably be easier to see what's going on with a custom palette. > it was _much_ slower in a PuTTY window when I first ran the script, just to see what to expect I forgot to mention that this is quite likely because PuTTY doesn't support the `DECRQCRA` query. So if that's the case, the script would be blocking for 2 seconds on every character, since it's waiting for a response from the terminal that never arrives.
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-Terminal
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#19514
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?