How developers interact with the Windows Console doesn’t change much. For 13 years, from Windows NT to the end of Windows XP, the only access users had was through the command line—good old cmd.exe. In 2006, PowerShell was introduced to leverage the power of the .NET Framework and facilitate much greater scripting and automation capabilities for system admins. Ten years later, the Windows Subsystem for Linux came to Windows 10 to allow Linux binaries and distros to run on Windows machines. Three significant changes in 25 years.
With the iterative update scheduled for Windows 10, though, console improvements have begun trickling out to users, especially more *NIX-like features. The primary obstruction to implementing *NIX features in the Windows Console up to this point has been the Windows Console interface: the Console API. Command Prompt, PowerShell, and other Windows command-line tools run connected to the Windows Console by exchanging information via the Console API and IOCTL messages. *NIX terminals and command-line apps communicate via streams of characters—much simpler than the architecture around the Windows Console.
So why not scrap the Windows Console and replace it with a *NIX-like one? Millions, probably billions, of apps, tools, and scripts depend on the Windows Console. Instead, when Microsoft began working on the Windows Subsystem for Linux, it established a new Windows Console team to begin delivering more *NIX-like console features developers had been using for years via third-party solutions, like CygWin, MinGW, and MSYS.
Some of the first Windows Console improvements targeted the front-end and UX—features that left one asking, “How were these not features for so long?!”—like full-screen maximization for command-line windows, copy and paste keyboard shortcuts, word wrapping, line selection, and text selection. In addition, comprehensive support for ASNI/VT sequences was added, allowing Windows tools to have colorful text UIs, something *NIX users have had for decades. Wider Unicode support has also been added, but it’s still a long way from being able to render complex glyphs and support features like zero-width joiners. Soon, though, greater changes are coming.
Windows Console before (left) and after (right) ANSI/VT Support. Source: Microsoft.
On the Windows Command Line Tools for Developers blog, the Windows Console team has been publishing a detailed history of the Windows Console, from the origins of the command line to the current state of the Windows Console. It’s an impressive read currently in three parts (Part 1, Part 2, Part 3) that drops hints about future improvements. Perhaps in the next post or two, we’ll really get an idea of how much the Windows Console team can accomplish. They’ve certainly illuminated past and current limitations, but something tells us that we’re on the verge of a big reveal. Perhaps a new Console API?
If you’re subscribed to the Windows Insider builds, you can be among the first to try out new features the Windows Console team is testing for future Windows updates. We’ll be keeping an eye on those and the Command Line Tools blog, and hope you will, too. With years and even decades of experience with the Windows Console, dear reader, you know better than anybody what practical improvements are truly needed in the Windows Console. Let us know what you currently love and what you’re still holding out for in the comments below, or on Facebook or Twitter.
If you like this blog post, we think you’ll also like the following free e-books:
Windows 8.1 Succinctly
Windows Azure SQL Reporting Succinctly
Windows Store Apps Succinctly
