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 #391

New Issue
Open
opened 2026-01-30 21:50:45 +00:00 by claunia · 0 comments
claunia commented 2026-01-30 21:50:45 +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:45 +00:00
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#391
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?