3 ms·

I've read all of the blog posts about the Windows Command Line [1] and the following posts and it still boggles my mind how long it's taking Microsoft to overha

I've read all of the blog posts about the Windows Command Line [1] and the following posts and it still boggles my mind how long it's taking Microsoft to overhaul their command line and create a decent terminal emulator. They're on year 6 of this effort, if you didn't know. I don't think people at MS are stupid or anything - I obviously have no idea of the real complexity underpinning this stuff. But holy cow. This is a problem that's long been solved on other platforms and it just seems ludicrous. 1. https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/ https://devblogs.microsoft.com/commandline/windows-command-l...

OptionX 7y ago
The team on it is rather small. I think M$ takes it as a side project more than a new feature for the OS. But I agree with you, should've been done ages ago. When they first put out powershell, for example, would've made sense.
- austdi 7y ago
  The team is incredibly small compared to other teams. 2-4 devs at a time, roughly a tenth of those on powershell. Much of the difficulty of the project came from the lack of resources yes, but also the age of the codebase. It was originally written in the 1980s (before most of the dev team was born) and the original authors had long since left the company by the time the mothballs were dusted off. The team also owned other codebases that time had to be split between. Maintaining compatibility and performance were two of the main unbreakable tenets of the team (and Windows in general). This made it difficult to move quickly with features right out of the gate. A few of those years were spent understanding the system and modernizing the code from crufty C to C++17, while still managing to add features. One of the first dev tasks I heard about when I became exposed to the project was of a dev mapping out all of the PVOIDs in the codebase so they could be eventually replaced with better abstractions. Another fun one was a different dev that refactored the GDI rendering, as a side project squeezed in around other tasks. The new renderer ended up being much faster and ~7000 lines shorter, if I remember right. We also took CJK language support quite seriously, which was difficult as none of the devs could read one of those languages day to day to catch bugs quickly.
  - dboreham 7y ago
    1980s? For some reason I always assumed cmd was re-written for NT in around 1991.
    - bitcrazed 7y ago
      Hi. PM on Windows Command-Line here: A couple of things: 1. You're confusing Cmd (the command-line shell) with Console (the terminal UX you see and interact with on-screen) 2. Development for NT started in Oct 1989 and the first version of NT shipped in 1993 You might find it interesting to read my series of posts on the evolution of the Windows Command Line: https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/ https://devblogs.microsoft.com/commandline/windows-command-l... HTH.
    - austdi 7y ago
      Development started in the late 1980s and continued through the early 1990s, I may have been slightly hyperbolic.
- tbyehl 7y ago
  The reality is probably that it took PowerShell succeeding, and WSL looking like another win, to make it worth revamping the console. What was the last console improvement? Quick Select? Windows 2003? Mouse-resizable console windows had me salivating for Windows 10!
lenkite 7y ago
Maintaining compatibility and not breaking stuff generally adds a severe multiplication factor to the development time compared to a greenfield project.
nailer 7y ago
> They're on year 6 of this effort, if you didn't know. Are you sure? The command line and WSL folks only started being prominent a couple of years ago. Maybe I missed something?
- bitcrazed 7y ago
  Hi. PM on Windows Command-Line here. The Console/Terminal team first took-ownership of the Console & Cmd codebases in late 2014, so it's been ~5.5 years. Until v. recently, the team averaged ~2.5 devs and 0.5 PM (I had to split my time across Console and WSL). Since spring 2019 when we began the effort to build Windows Terminal, we've grown the team to 4 devs and 1.25 PM (I am now the .25 since Terminal now has a dedicated PM). During this time, we have shipped improvements to Console in every release of Win10, including transparent background, VT, 24-bit color, and many perf, stability, etc. fixes. But we can only do so much to the Console before we start to break users' existing systems, apps, and tools. Since Console & Cmd's key responsibility is backward compat, we're pretty much leaving them alone. But we're plowing ENORMOUS effort into building Windows Terminal which is shaping-up nicely for its v1.0 release this summer. Please give it a try and if you find problems, find/file issues in the github repo because, yes, Windows Terminal and Console are open-source! Repo: https://github.com/microsoft/terminal https://github.com/microsoft/terminal

OptionX 7y ago

The team on it is rather small. I think M$ takes it as a side project more than a new feature for the OS. But I agree with you, should've been done ages ago. When they first put out powershell, for example, would've made sense.

austdi 7y ago
The team is incredibly small compared to other teams. 2-4 devs at a time, roughly a tenth of those on powershell. Much of the difficulty of the project came from the lack of resources yes, but also the age of the codebase. It was originally written in the 1980s (before most of the dev team was born) and the original authors had long since left the company by the time the mothballs were dusted off. The team also owned other codebases that time had to be split between. Maintaining compatibility and performance were two of the main unbreakable tenets of the team (and Windows in general). This made it difficult to move quickly with features right out of the gate. A few of those years were spent understanding the system and modernizing the code from crufty C to C++17, while still managing to add features. One of the first dev tasks I heard about when I became exposed to the project was of a dev mapping out all of the PVOIDs in the codebase so they could be eventually replaced with better abstractions. Another fun one was a different dev that refactored the GDI rendering, as a side project squeezed in around other tasks. The new renderer ended up being much faster and ~7000 lines shorter, if I remember right. We also took CJK language support quite seriously, which was difficult as none of the devs could read one of those languages day to day to catch bugs quickly.
- dboreham 7y ago
  1980s? For some reason I always assumed cmd was re-written for NT in around 1991.
  - bitcrazed 7y ago
    Hi. PM on Windows Command-Line here: A couple of things: 1. You're confusing Cmd (the command-line shell) with Console (the terminal UX you see and interact with on-screen) 2. Development for NT started in Oct 1989 and the first version of NT shipped in 1993 You might find it interesting to read my series of posts on the evolution of the Windows Command Line: https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/ https://devblogs.microsoft.com/commandline/windows-command-l... HTH.
  - austdi 7y ago
    Development started in the late 1980s and continued through the early 1990s, I may have been slightly hyperbolic.
tbyehl 7y ago
The reality is probably that it took PowerShell succeeding, and WSL looking like another win, to make it worth revamping the console. What was the last console improvement? Quick Select? Windows 2003? Mouse-resizable console windows had me salivating for Windows 10!

lenkite 7y ago

Maintaining compatibility and not breaking stuff generally adds a severe multiplication factor to the development time compared to a greenfield project.

nailer 7y ago

> They're on year 6 of this effort, if you didn't know. Are you sure? The command line and WSL folks only started being prominent a couple of years ago. Maybe I missed something?

bitcrazed 7y ago
Hi. PM on Windows Command-Line here. The Console/Terminal team first took-ownership of the Console & Cmd codebases in late 2014, so it's been ~5.5 years. Until v. recently, the team averaged ~2.5 devs and 0.5 PM (I had to split my time across Console and WSL). Since spring 2019 when we began the effort to build Windows Terminal, we've grown the team to 4 devs and 1.25 PM (I am now the .25 since Terminal now has a dedicated PM). During this time, we have shipped improvements to Console in every release of Win10, including transparent background, VT, 24-bit color, and many perf, stability, etc. fixes. But we can only do so much to the Console before we start to break users' existing systems, apps, and tools. Since Console & Cmd's key responsibility is backward compat, we're pretty much leaving them alone. But we're plowing ENORMOUS effort into building Windows Terminal which is shaping-up nicely for its v1.0 release this summer. Please give it a try and if you find problems, find/file issues in the github repo because, yes, Windows Terminal and Console are open-source! Repo: https://github.com/microsoft/terminal https://github.com/microsoft/terminal