But rather than just add a few more colors, or limit our console to a mere 256 colors, in Windows 10 Insiders Build #14931, we've updated the Windows Console to support full, glorious 24-bit RGB true color!

This is actually a little tricky to demo since most Windows apps only support 16 colors at most whereas the Linux world has broadly supported 256 color terminals for a while now, and 24-bit color is becoming more established.

Thanks to our ability to run Linux apps and scripts using our new Bash on Ubuntu on Windows environment atop the Windows Subsystem for Linux (WSL), we can use some Linux scripts and tools to demonstrate the Console's new 24-bit color support:

24-bit Color Bars

24-bit Color Grids

We've not yet started work on improving the console properties page to support the Console's new color rendering capabilities, and we've not modified the default Windows color mappings; we'll be making improvements here, and on the many, MANY other features queued-up in our backlog in future builds.

Over the years I’ve had countless conversations with people about the command line experience in Windows; mostly trying to sell them on the idea of PowerShell (because it’s awesome). I would often hear them say they can’t stand PowerShell/cmd, and then proceed to list a bunch of reasons like not being able to resize the window sensibly, etc.

I don’t know what that reason was, but I always just assumed maybe the console had a really intimidating codebase that would explode if you so much as sneezed at it. Or maybe it was just a business case thing? Whatever the reason, I am so happy and impressed with the work you guys have done on the console in Windows 10 and the UserVoice page is full of really exciting stuff. You guys are awesome and I can’t wait to see what comes next.

I started working on code a VS Code port equals Electron port equals Chrome port here https://goo.gl/ONCwUN (note the version number) but got bogged down in missing futex surface. It should be possible to do with what’s available in WSL now, I just haven’t gotten back to it.

Very cool on the the true color support. But it would be even cooler with Sixel. 🙂

I would like to upvote Sixel support, but I can’t find where on that site. Sixel works now in Bash on Ubuntu on Windows but requires Xming and MLTerm or XTerm. I’ve recompiled GNUPlot from the Ubuntu 16.04 distribution with support for Sixel graphics (set term sixel). GNUPlot is in turn used by Octave and other big data programs. It’s very useful to have the diagrams in the terminal and not in some popup window, because one can e.g. scroll back, know where to look, and can avoid the mouse. It would also be easier to install these big data programs if one doesn’t need Xming.

WSL is only focusing on running command-line tools right now. That said, rather than run VSCode “in” WSL, we’re working to improve interop between Bash and Windows which should make things a lot easier.

I am impressed! It’s a weird step sorta backwards from the Windows GUI, yet forward from plain-Jane monochrome. I can’t wait to see what I can do in that mode, being an old-timer and used to terminfo-style graphics.

Sweet! I’m really loving the new Console and supporting 24-bit colors is a fantastic addition! I look forward to seeing what more you have in store for us with this feature… I’m super stoked about Microsoft embracing and support Linux instead of considering it a “cancer” 🙂

This is great! Do you have any plans to bring ANSI colors support back into the Command Prompt in Windows 10? It was there and worked great in the November 2015 version of Windows 10 but then was removed and no longer works in the Anniversary Update. It was nice while it lasted, but it would be great if you could bring it back with this change as well!

I already had Bash on Ubuntu on Linux installed (and I quit using it and went back to my Mac because the colors were so bad I couldn’t read the screen) and so now I’m eager to try this out, but after getting the update (my desktop shows 14931 in the right hand corner) and rebooting I still see this when I ssh into a box that has vim set up with the solarized theme:

I already had Bash on Ubuntu on Linux installed (and I quit using it and went back to my Mac because the colors were so bad I couldn’t read the screen) and so now I’m eager to try this out, but after getting the update (my desktop shows 14931 in the right hand corner) and rebooting I still see this when I ssh into a box that has vim set up with the solarized theme:

In 1511 we had access to colorized output (programs could print colored output) but now after Anniversary Update, they have been impeded to do so, (however, txt/bat files containing ESC sequences still work). Is there any reason that you have removed this feature from 1607 just to add a somewhat broader implementation in the Insider Build? Is there any workaround till the update goes public?

Will we get access to more colors also outside of WSL, say in the PowerShell console host, in the PowerShell ISE (and why not in CMD even though I try to avoid this by all means, except maybe to write double-clickable launchers for .ps1 scripts 😉 )?

If yes, how? (I’m thinking of being able to specify a 24-bit color value in, say, $host.UI.RawUI.BackgroundColor or as the -ForegroundColor argument to Write-Host, etc.)

When those tools start emitting the necessary VT sequences to render > 16 colors. We don’t currently plan on updating the console API’s to support the many new features we have added, and continue to add, to support VT.

The following extended API’s would be appreciated, which utilise RGB values plus underline/bold etc in the high order bits.
SetConsoleTextAttributeEx, GetConsoleTextAttributeEx
WriteConsoleOutputAttributeEx, ReadConsoleOutputAttributeEx

We have no current plans to retrofit the additional VT capabilities into the Windows API. While this may appear odd at first, understand that there are some breaking scenarios, esp. when talking between a local Console and a remoted command-line app (even if it’s running on the same machine).

The model of embedding VT sequences into your output text is a far more resilient, consistent, and future-proofed way of rendering formatted/structured text.

OMG! I just accidentally ran 24 color shell script and saw true color support. It is early to state that thee God does exist, before property page is done, but I start getting hard suspicious that it is true:D

This is awesome! Is it possible to update WSL separately of Windows builds? I’d prefer not to run the insider builds but instead run the stable, which at this point in time is 1607 (the anniversary update) which has WSL but not the 24-bit color support. Is there a way for me to update just WSL or do I really need to run insider builds?

I assume it’ll be at least a few months before it comes to stable?
Thanks!

No – although we’d love to if we could! 🙂 WSL itself is kernel infrastructure which takes advantage of, and is coupled to, several other pieces of kernel infrastructure which currently have to evolve in lock-step. Not saying we can’t do this at some point in the future, but it’s not on the cards anytime soon.

This is wonderful. My favourite Monokai theme in Emacs, and my custom colour configuration in Mutt look just the way I like them. I’ve been using OpenBSD 6 in VirtualBox to do my daily work, but now I think I should try switching to WSL full-time. Thank-you Rich and everyone else at Microsoft. My favourite Linux Desktop is Windows 10.

Very interested in 256+ console color support. Previously this functionality could be implemented by hijacking the DC and directly drawing into the console, whilst updating the native console with redraw disabled. I am keen to build a library which supports 256+ on both 10 and legacy Windows versions/consoles, Please publish the underlying ESC controls.

That’s good but I have a problem since this update. Unfortunately I can’t use the new ESC sequences in my Java program. Previous year when I wrote ” System.out.print(“\u001b[31mText”); ” my text was in Red color and now my text appear with a non-recognized character before (like a square with an interrogation point in). So, what it’s the new escape sequence please ??
Pardon my english.

Is this an increase in the number of colors the “Windows Console” supports or a whole new shell program? Because it seems to me this is not cmd.exe but bash.exe, and we’ve had decent color support from external shell emulators from a long time ago. I reckon transparency was a very nice addition to Windows Console (cmd.exe), I’m glad, but I really still wait for the color upgrade, please take a look at that!!

Windows Console is the terminal app built into Windows. Until we overhauled its color support, it was only able to display up to 16 colors. This improvements now allows the console to render in full 16M 24-bit color. To use these new colors, apps will need to enable VT support (already enabled when using Bash & PowerShell), and will need to emit VT sequences requesting 24-bit colors.

This doesn’t magically make things display rich colors if they’ve not been built to ask for rich colors.

Is there a Win32 API available for this yet? The ANSI codes work great, but it seems like ESC[3J doesn’t work at all and ESC[2J clears the screen with the default background color (as defined by the “color” console command, which is just a wrapper around SetConsoleTextAttribute()) instead of the color that was set via something like ESC[48;2;;m.

Is any work being done to publish a Command reference for the latest version of the console commands? There have been several significant improvements to them in Windows 10 but there is no supporting documentation.

Purely by way of example, the netsh command has been made much more powerful but the only method for studying it is to plod through each set of sub-commands using netsh mbn connect /? & so on.