New Experimental Console Features
As of Windows 10 build 18298, when you open the properties page of any Console window, you’ll notice an additional “Terminal” tab. Click on this tab and you’ll see several new settings for some experimental features we’re working on for future OS releases:
Important Note: These settings are “experimental”, because in certain scenarios, it’s possible that they might not behave like you would expect them to, may not make it into the next OS release, and may change completely before we ship! But have fun with them anyway and let us know how you get on – we’d love to hear your feedback. Let’s outline each of the settings groups from the bottom up, ending with a more thorough discussion the Terminal Color settings:
Disable Scroll Forward:
- When cleared (default state), the Console can to scroll anywhere within the Console’s buffer, even below the most recent row of text displayed When checked, the Console will not allow scrolling below the last line output, similar to how most *NIX terminals work
Legacy Style: Thicker underscore by default, but controlled by the cursor size property in the “Options” page
Underscore: Thinner underscore
Vertical Bar: For all you crazy kids who like your cursors tall and skinny
Empty Box: The second-best cursor:
Solid Box: The one true cursor
Inverse Color: The current and default behavior where the cursor color is the calculated inverse of the background color … which results in, for example, this adorable fetching pink against the bright green background of my first computer – the Dragon 32 😊
Use Color: Draw the cursor in a specific RGB color, like this fetching green against dark gray background:
The Terminal Colors fields allow you to specify specific RGB color values for the default foreground and/or background colors. These colors are independent of the color palette and are not affected by changes you make to your color palette! But before we discuss the inherent implications here, we need to consider how these new settings fit into the color changes we’ve been making over the last several Windows 10 releases:
Karma Karma Karma Karma Console Chameleon
Over the last couple of years, during “The Grand Overhaul” of Windows Console, we’ve made some significant improvements to Console’s parsing and handling of ANSI/VT sequences, and how the Console stores and renders colored text.
This all started with a rewrite of the Console’s VT parser. Prior to the (then new) team’s efforts, Windows Console barely supported any VT sequences at all. But with the steady growth in adoption of *NIX-first open-source tools, many of which emit VT sequences to color and draw text-based UI’s, it was increasingly imperative that the Windows Console be able to support VT sequences.
This was made even more important and urgent due to the arrival of Windows Subsystem for Linux which allowed unmodified Linux binaries to run natively on Windows, allowing Windows users to easily run most of the *NIX tools they’d previously had to fire-up in a separate VM.
The first significant version of the Console’s new VT engine shipped in Windows 10 1609 (Anniversary Update), and was quickly followed in the 1703 (Creators Update) release which contained much richer support for a wider range of VT sequences. This allowed Console to render many of even the most complex text-based UI’s generated by tools like Tmux (a great tutorial here for the uninitiated) and Midnight Commander … or even
Midnight Commander and
htop running simultaneously in separate
Also in Creators Update, the Console shipped its massively improved color support, increasing its color support from a mere 8-bit/16-colors (a single 8-bit value held both the foreground and background color 0-7 in the low and high nybble respectively), to full 24-bit/16M-colors!
But we weren’t yet done! In the Fall Creators Update (Oct 2017), we updated the Console’s default color palette for the first time … ever! After working with Microsoft’s usability and accessibility teams, and following recommended color selection guidelines, we arrived at a new color palette that is FAR better suited to modern high-contrast displays.
In addition, we also shipped an open-source ColorTool which you can use to apply different color palette’s to your Console windows if you wish.
So, we’re done with color support in the Console, right?
Looking Back, Moving Forward
The Console now lives in two worlds:
- 1. Windows – Console supports traditional/legacy command-line Windows apps that call the Win32 Console APIs to color/manipulate text displayed on the Console
- ANSI/VT – Console also now supports apps that color/manipulate the text that they display by embedding VT sequences within the text that they emit
Because of #2 above, Console has to support some of the different ways in which VT compatible terminals think about the world.
A key difference between Windows Console and *NIX-based VT Terminals is that *NIX Terminals have a notion of default foreground and background colors, which are independent from the Terminal’s color palette. The Windows Console does not … at least not quite the same!
Windows Console refers the “Screen Text” and “Screen Background” colors to the colors defined in the Console’s palette:
But Console has no notion of “default” foreground or background color to the command-line apps that draw on the screen. At best, there’s an assumption that color #0 is often the background color, and that #7 is the foreground, but this is an often-incorrect assumption, not a widely-understood rule. In fact, Windows command-line apps have no way of determining the default foreground and background colors!!
For a good example of this, let’s explore Windows PowerShell: The Windows PowerShell team wanted to differentiate PowerShell Consoles from Cmd Consoles by changing the PowerShell Console’s default background color.
They specifically modified the PowerShell shortcuts’ settings:
- Re-defined color #5 as a specific shade of blue: RGB(1,36,86)
- Re-defined color #6 as a specific shade of gray: RGB(238,237,240)
However, they also decided to modify the shortcut’s background and foreground color indexes to
- Color #5 as the background color (instead of the generally assumed color #0)
- Color #6 as the foreground color (instead of the generally assumed color #7)
Sometimes, PowerShell wants to, for example, “render this text in
Alas, because Windows Console has no API to discover what the “default background color” is, PowerShell assumes that the background is the color defined by color #0 … which usually IS the background color … except in PowerShell which uses color #5
Thus, if you’ve ever mis-typed a command in Windows PowerShell, you’ve likely seen something like this:
Alas, the changes we’re working on (and exposing via the experimental Terminal settings page) won’t fix this specific issue for Windows PowerShell ☹
Existing/legacy applications that specifically say “draw this text in
However, making Console aware of the notion of “default independent foreground and background colors” will enable Console to more accurately render VT enriched text-UI, and will give Console users more control over the customizability of their Command-Line environment.
Call To Action!
This issue further amplifies the recommendation to start writing (or update existing) Command-Line apps to emit VT enriched text, rather than calling Win32 Console APIs to control/format Console output: VT-enabled apps will not only benefit from rendering improvements like those described above (with more on the way), but they’ll also enjoy richer features available via VT-sequences, like 24-bit color support, and default foreground/background color support.
We look forward to hearing how you get-on with these experimental changes. If you find issues with the color support, please find/file issues on our GitHub issues repo, reach out and let @richturn_ms know on Twitter, and/or submit feedback via the Feedback Hub.
Any news in cmd.exe improovements?
I strongly suspect Windows Terminal is the way going forward.
Note: Cmd is a command-line shell, not a terminal.
@Petr: Cmd’s primary job is to continue to run legacy batch scripts. This means that:
1. Cmd can never be removed from the OS while there are still legacy batch scripts to run
2. Cmd can almost never be changed because even tiny changes/fixes breaks someone, somewhere
3. Any new command-line scripts, or existing batch files should be migrated to PowerShell scripts wherever possible. PowerShell is a MUCH more powerful, feature-rich, x-platform, open-source shell and is where all of Microsoft’s scripting effort is being spent.
John – I deleted your commentary which was way off-topic. Please keep comments respectful or you will blocked from posting comments on this site.
I still waiting this moment when cmd will support 256colors. PDcurses wanna blood & colors
Get the Windows Terminal Beta!
My Cmd, I assume you mean the Windows Console UX through which you interact with Cmd and other command-line apps?
If so, then Console has supported 16M 8-bit RGB colors since 2017, but only if your command-line app/script emits VT to control colors. Windows’ Command-Line API is not going to be extended to support more than the current/legacy 16 palette terminal-controlled colors.
PLEASE PLEASE PLEASE add in full xterm-256 support!
this is vitally important to actually using text editors under ssh.
While colors do work, the simple pico text editor does not behave. this is because not all of the used control codes work. xterm supports a totally ludicrous number of excape sequences.
Support EVERYTHING. then stuff will work.
Have you tried Windows Terminal instead of Windows Console? Take a look: https://devblogs.microsoft.com/commandline/introducing-windows-terminal/
Thanks Chuck. I think what you mean is “support more VT-Sequences” – XTerm is NOT the only terminal in the world, and there are many apps & tools that emit VT-Sequences that even xterm doesn’t support! This said, we are expanding and improving our VT support with each release, especially in Windows Terminal. Improvements made in Windows Terminal will be re-integrated into the in-box Console over time, though on a slower cadence since Console is built-into and thus gated by the frequency of Windows updates, whereas Terminal is (currently) updated ~monthly.
Bless you for adding the Disable Scroll Forward option!
Though some may find it useful, I’ve alway found it to be the most consistently aggravating things when using the Windows console. Having to constantly sroll back up because a spinn of the mouse wheel scrolled you down way past the current line is so horrible.
Change “Cursor Shape” doesn’t work for me. After I type anything, it will change to “Legacy Style”. This happened in Windows 10 build 18894.
You are not alone.
I had a little trouble with the cursor option resetting, but it seemed like it would reset whenever I changed settings tabs without hitting okay and reopening the settings panel. Not sure if I was experiencing the same bug as you guys. What if you set the cursor via the Right Click > Defaults panel? That might force it to stay.
The colortool looks very interesting. Although it’s a larger issue than just configuring colors for the terminal , one of the things I would like to see more focus on is the ability to quickly visually distinguish different windows/terminals to determine context. For example, I often have 7 or 8 different terminal windows open across multiple virtual desktops and figuring out which one I’m trying to get back to for a particular operation is always tricky. The least bad solution seems to be to give each a distinct background color so I can just remember to alt-tab to “the red one” for example and colortool will certainly help with this (avoiding clashing text colors is always a problem). Other approaches that might be useful….
* Allow the title/tab bar color to be configured
* Allow a custom background image per instance
* Provide a large numeral overlay during Alt-tab (a bit like when you choose “Identify desktops” in multi-monitor configuration)
* Provide a mechanism for _automatically_ shading/brushing the terminal background differently for each new instance.
Of course this is a much larger issue than just Terminal – I often have 2 or 3 instances of Visual Studio running and would like to be able to theme these separately for quick identification – but terminal/powershell are usually the worst case for me.
Some of this we already do, but please file new feature requests on https://github.com/microsoft/terminal.
I realize this blog post is fairly old now and a lot has changed, though FYI, the link in the “Terminal” tab still comes to this page. Once here, there is some information that no longer holds true. That is, the link to the other blog post (where I’ll comment too) https://blogs.msdn.microsoft.com/commandline/2017/08/11/introducing-the-windows-console-colortool/ – is referencing ColorTool as if it is still part of the Microsoft Terminal. But it isn’t. It also seems like all development is going into Microsoft Terminal, and the links lead to that as well in these posts. So it’s hard to determine what these posts have to do with the built in cmd.exe anymore.
Hey Jeremy. Please note that Windows Terminal <> Windows Console. The former is our brand new next-generation Terminal app for Windows. The latter is the traditional Console app shipped within Windows itself. I encourage you to read the blog post series I’ve written to help explain how the Windows command-line evolved, how it ended up where it has, and where we’re going into the future:
I wonder if these changes are related to cmd.exe’s color command breaking?
I used to be able to use the color command without any arguments to reset the colours to what they were when the window opened, but now that only works if cmd.exe is run using the /T:xx option. My PC with windows 10.0.16299.1087 is still working, but all my others have 10.0.18362.295 or later have the problem. I thought it might be something to do with my settings, but when I copied cmd.exe from the working install to one of the other PCs it started working like it used to. Hardly an ideal workaround, especially considering the permissions changes required to replace cmd.exe, but it saves me having to update a huge number of .bat files.
The Popup Text and Popup Background “Colors” does not work at all.
And, when switching to Chinese input mode, the cursor disappears and never appear again.
Microsoft Windows [Version 10.0.18362.418]
(c) 2019 Microsoft Corporation. All rights reserved.
I have been using the “legacy terminal” style from the beggining of the terminal changes.
Today I installed the WSU and so I unclicked the “legacy terminal” (in order to be able of configuring the username), but I had a black screen for Debian.
When I finally could make a user for it (after resetting the install three times), I noticed that when I opened cmd, all I saw was a black window, also.
After some tries, I found there was some invisible text I could copy and paste in a notepad.
I opened the console properties, selected “colors” and saw they were configures as white text on black background.
But then I noticed the new “terminal” tab. Inside it, despite of the colors chosen in the “colors” tab, black was chosen for both text and background.
I think I never tinkered with the terminal colors before, but, anyway, shouldn’t be some warning about background being the same color as text?
You should only very rarely need to use the Legacy Console. FWIW, I’ve used it once in the last 5 years! Also note that if you enable Legacy Console, it affects ALL Console instances, not just the one you configure. Best option is to never use Legacy console unless you have no other choice.
Console only sets colors etc. to defaults on install. Any other changes to your colors must have been done manually. But don’t feel bad – I did just the same with my foreground and background colors a few months ago 😜
Re. warnings about foreground == background, please post an ask in the GitHub repo: https://github.com/microsoft/terminal/issues.