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

Potential regression with ScreenColors #394

New Issue
Closed
opened 2026-01-30 21:50:47 +00:00 by claunia · 3 comments
claunia commented 2026-01-30 21:50:47 +00:00
Owner
Copy Link

Originally created by @andyleejordan on GitHub (Oct 2, 2018).

  • Your Windows build number: Windows Version 1803 OS Build 17134.228

  • What you're doing and what's happening:

Attempting to set background and foreground colors through the registry keys, as detailed here.

  • What's wrong / what should be happening instead: (Quoting from other issue:)

After experimenting, I think there is currently a regression. ScreenColors is supposed to be of the form 0008 0009 where the first two bytes are the background color and the last two bytes are the text color. This is what we previously documented (in the theme), and indeed, it's how PopupColors is still behaving.

However, it appears that the last byte of ScreenColors is being read for the colors, instead of two pairs of two bytes. That is, what I've set is being interpreted as 09 ending up as base02 (color 0) and base00 (color 9). If I edit the default value in the GUI of cmd.exe to use base03 and base00 (colors 8 and 9), and save this, the registry key ScreenColors is then saved as 0000 0089.

So instead of the first two bytes being the background color, it appears to me that a console regression is instead reading only the last byte as the background color.

See PR to Solarized theme for console here: https://github.com/neilpa/cmd-colors-solarized/pull/35
/cc @bitcrazed

Originally created by @andyleejordan on GitHub (Oct 2, 2018). * Your Windows build number: Windows Version 1803 OS Build 17134.228 * What you're doing and what's happening: Attempting to set background and foreground colors through the registry keys, as [detailed here](https://github.com/neilpa/cmd-colors-solarized/pull/35#issuecomment-415555366). * What's wrong / what should be happening instead: (Quoting from other issue:) After experimenting, I think there is _currently_ a regression. `ScreenColors` is supposed to be of the form `0008 0009` where the first two bytes are the background color and the last two bytes are the text color. This is what we previously documented (in the theme), and indeed, it's how `PopupColors` is _still_ behaving. However, it appears that the last byte of `ScreenColors` is being read for the colors, instead of two pairs of two bytes. That is, what I've set is being interpreted as `09` ending up as `base02` (color 0) and `base00` (color 9). If I edit the default value in the GUI of cmd.exe to use `base03` and `base00` (colors 8 and 9), and save this, the registry key `ScreenColors` is then saved as `0000 0089`. So instead of the first two bytes being the background color, it appears to me that a console regression is instead reading only the last byte as the background color. See PR to Solarized theme for console here: https://github.com/neilpa/cmd-colors-solarized/pull/35 /cc @bitcrazed
claunia added the Product-ConhostIssue-Question labels 2026-01-30 21:50:48 +00:00
claunia commented 2026-01-30 21:50:48 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 2, 2018):

I don't believe it was ever read as a pair of four bytes encoding that information.

ScreenColors has always been a REG_DWORD that contains only one actual byte of useful information. The lowest 4 bits being the index in the color table of the foreground color, and the next-lowest 4 bits being the index of the background color. In this schema, 0x0f is "Foreground Bright White, Background dark black"

Note that there is a pretty confusing mechanism by which the properties are actually loaded. There are probably two relevant keys in the registry: HKCU\Console and
HKCU\Console\%SystemRoot%_system32_cmd.exe.

These work in a cascading fashion - first the console will apply the hardcoded defaults, then it will apply the settings in HKCU\Console (the defaults), then it'll either load properties from a shortcut (if launched via a shortcut, like Win+X, C), or it'll load any settings present in the registry for the "Title" the console was launched with (in the case of Win+R, cmd, this is translated to %SystemRoot%_system32_cmd.exe.

@zadjii-msft commented on GitHub (Oct 2, 2018): I don't believe it was ever read as a pair of four bytes encoding that information. `ScreenColors` has always been a REG_DWORD that contains only one actual byte of useful information. The lowest 4 bits being the index in the color table of the foreground color, and the next-lowest 4 bits being the index of the background color. In this schema, `0x0f` is "Foreground Bright White, Background dark black" Note that there is a pretty confusing mechanism by which the properties are actually loaded. There are probably two relevant keys in the registry: `HKCU\Console` and `HKCU\Console\%SystemRoot%_system32_cmd.exe`. These work in a cascading fashion - first the console will apply the hardcoded defaults, then it will apply the settings in `HKCU\Console` (the defaults), then it'll either load properties from a shortcut (if launched via a shortcut, like Win+X, C), or it'll load any settings present in the registry for the "Title" the console was launched with (in the case of Win+R, cmd, this is translated to `%SystemRoot%_system32_cmd.exe`.
claunia commented 2026-01-30 21:50:49 +00:00
Author
Owner
Copy Link

@andyleejordan commented on GitHub (Oct 3, 2018):

I don't believe it was ever read as a pair of four bytes encoding that information.

@zadjii-msft I am so sorry, I misunderstood how it was broken up; but the examples still hold true. I've updated the post with the correct terminology I intended.

This behavior has seemed to change though. Or, if it didn't change, than we'd just "gotten lucky" previously in the theme with an incorrect understanding of how ScreenColors is read, which is quite possible!

@andyleejordan commented on GitHub (Oct 3, 2018): > I don't believe it was ever read as a pair of four bytes encoding that information. @zadjii-msft I am so sorry, I misunderstood how it was broken up; but the examples still hold true. I've updated the post with the correct terminology I intended. This behavior has seemed to change though. Or, if it didn't change, than we'd just "gotten lucky" previously in the theme with an incorrect understanding of how `ScreenColors` is read, which is quite possible!
claunia commented 2026-01-30 21:50:49 +00:00
Author
Owner
Copy Link

@andyleejordan commented on GitHub (Oct 3, 2018):

I understand now... thank you so much @zadjii-msft

@andyleejordan commented on GitHub (Oct 3, 2018): I understand now... thank you so much @zadjii-msft
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 Issue-Question 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#394
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?