New Experimental Console Features

Rich Turner

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:

Experimental settings in action
]2 Experimental settings in action

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:

Terminal Scrolling

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

Cursor Shape

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

Cursor Colors

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:


Terminal Colors

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.

Before (XP) and after (Win10) VT support added to Console
]10 Before (XP) and after (Win10) VT support added to Console

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 vim, bash, Midnight Commander and htop running simultaneously in separate Tmux panes:

TMux hosting vim, bash, Midnight Commander, and htop
]14 TMux hosting vim, bash, Midnight Commander, and htop

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. 1. Windows – Console supports traditional/legacy command-line Windows apps that call the Win32 Console APIs to color/manipulate text displayed on the Console
  2. 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:

Console color settings
]19 Console color settings


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 on whatever the default background color is”.

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:

PowerShell assumes the background color is #0
]20 PowerShell assumes the background color is #0

Moving Forward

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 on color #0” will still draw text in some-foreground-color, on a (usually black/dark) background, even if the Console’s default background color is bright green! In some ways this is good;there will be no behavioral change for existing/legacy apps. But the downside is that such apps will continue to render less than optimal output (like in the PowerShell example above.

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.



Discussion is closed. Login to edit/delete existing comments.

  • Валерий Заподовников 1

    Sorry Валерий: I don’t understand the issue you’re describing?

  • 1

    Overall, I think the new console is great! There’s two things the experimental console does “wrong”. (NOTE: The editor on this site is weird, it won’t let me add numbers 1 and 2 to the two points below.)

    Unlike the classic console, if you use “Discard Old Duplicates”, the new one is case-insensitive. Thus, if I run foo /v and then foo /V, only one of the two is kept in the command history, despite the fact the case is significant to foo!

    You can’t bypass DOSkey macros by placing a space in front of them.

    Who may I pass these issues on to? Thanks!

    • Rich TurnerMicrosoft employee 1

      Thanks for the note, but please file issues in the team’s GitHub repo where we triage and manage all issues, asks, etc.:

      However, we do recommend that, wherever possible, enthusiastic command-line users adopt the new Windows Terminal and PowerShell – Console + Cmd are both supported, but are not receiving significant investment as their job is preserving backward compatibility, whereas Terminal + PowerShell is all about the future.

  • David Bollman 1

    Please allow some of the same functionality as putty, primarily the nearly unlimited scroll up option. Limiting it to 999 is crazy small. Also the default of 20000 would be my recommendation (similar to putty), it’s rare you need to bump that (but it happens).

    Also you really should have no limit either on the command history.

    Finally you should not have a different copy paste mechanism in every different cmd prompt, (powershell, linux window, cmd)…

    • Rich TurnerMicrosoft employee 1

      Thanks for sharing your thoughts David. Alas, we can only change Console so much before we start to break people, so we’re having to pretty much leave it alone, except for essential maintencnace.

      However, we’re building a whole new, modern, fast, productive command-line UX in Windows Terminal in which we’re improving at a significant pace. You can download the Terminal from the Windows Store, and/or clone the source and report issues via its GitHub repo:

      Ultimately what you’re asking for will be delivered when we get to the “persistent sessions” collection of features that are currently in our backlog. The idea here is to provide the ability to serialize command-history to a file, providing for command-history that is only limited in length by your PC’s storage capacity We’re also considering enabling command output to be serialized to a file to enable restartable sessions, though this presents some security/privacy concerns which need very careful consideration.

      We don’t currently offer a different copy & paste per-profile in Terminal, through it has been requested because different shells use different key sequences/chords for different operations. E.g. in Cmd & PowerShell, CTRL+C == break, whereas many Linux distros default CTRL + SHIFT + C/V to copy and paste because CTRL+C has specific behaviors in many Linux tools like EMACS. Rest assured, we’ll provide a way for you to declare what key chords you want to map to which operations (as we do today), but may consider allowing you to override specific key chords on a per-profile basis if you want to.

  • Douglas Tondo 1

    Is there a way to allow a configuration that terminal blinks (in taskbar) after a long command (more them 30 seconds) finish the execution?
    Example of use: imagine that you are installing a big program that takes 3 minutes to download at least… I normally minimize the terminal and do other stuffs… It would be good if the terminal blinks after the installation finished ( allow user to type the next command )


    • Rich TurnerMicrosoft employee 1

      Hey Douglas. Since blog comments aren’t monitored as actively, and don’t provide a good way of having a bidirectional conversation, I encourage you to search the Terminal repo and file asks/issues if you don’t find any that already describe your scenario:

Feedback usabilla icon