There's an excellent blog post by the product manager I believe that explains the history of the CMD command, how terminal emulation works in Windows, and the work they were doing.
The way I understand this project is essentially "an interface" to the new ConPTY they developed (which IIRC is closed source, naturally).
That doesn't make it any lesser. I've used it since a build was available, 4 years ago or something. I love it.
So, one of the cool things about this repository (Hi! I’m the engineering lead for the Terminal/Console/… team. I’m biased!) is that it also contains the source for ConPTY and the rest of the Windows console host[1]. Every change made here flows back into Windows, and vice-versa.
In this repo, you can find some of our terrible secrets and workarounds and debugging hooks and perhaps even some explanation for why things work the way they do. Or don't work the way they should.
If you’re looking for a good[2] way to spend a few minutes, search for “LOAD BEARING” :)
[1]: If you build the “Host.EXE” project and copy the resulting OpenConsole.exe over %WINDIR%\System32\conhost.exe, it’ll work just fine and you’ll pick up a bunch of the console changes we’ve made in the past few years.
[2] Goodness not guaranteed, void where prohibited, etc.
EDIT: Oh, kaelinl mentioned this in a sibling comment to yours. Sorry about that! I've also reworded parts of the main comment body to flow better.
Oh man, my memory must be bad. I remember the conhost.exe and the whole PTY stuff being closed source for some reason. Either way it will make for a very nice rabbit hole for one of those week-ends :D
Thank you and every one of your team members for the excellent work you guys have been doing on this. You have brought so much joy to working and living w/ Windows.
There are multiple projects in this repo. Windows Terminal, which the other commenters focus on, is a relatively new standalone app and not (yet?) bundled with the OS. They opted to open source it from the start, more or less. The other part is conhost, which is the classical terminal that has existed in Windows for decades. Some of the layout and rendering logic was pulled out of conhost to be shared with Terminal, and the two projects are maintained by the same team, so they open-sourced both. As I understand it, they then ship conhost and its shared components in Windows releases.
Probably the same reason they've opened sourced some other components lately: community feedback and updates.
There are a bunch of bugs in Windows core that I can't even get anyone to look at (and I'm an MVP). With these little bits they've opened sourced you can actively participate in helping the team fix the bugs, and add features as needed.
I know the team on Terminal had a whole muddle of problems to do with rendering recently that probably still needs some outside input. Even Microsoft's developers can't and don't know all the best ways to carry out tasks with their own APIs - there is just too much to learn.
Why pay employees to fix bugs when some random can fix it for free? It makes perfect corporate business sense. (Not saying its a good thing, but it does make sense from a business POV)
That's definitely the cynical way of looking at it :) And sure, if they threw more bodies at the problem they would definitely catch some of them. But in my experience the community has found and fixed some weird bugs that probably would have been hard to bubble up through normal channels, or would have just been deemed too low priority under normal circumstances.
Not sure I'd really call this a component of the OS. It is a new app that works with various shells (including cmd, powershell, and WSL) to create a better experience using them including tabbed view so you can have multiple terminals from a single window.
the code has been open since the beginning of the project, IIRC... back when it was announced first, to get it to build, you needed to build it locally...
It might have vulnerabilities that a motivated attacker could discover by reading the source code. It might contain copied code that Microsoft doesn't have the right to distribute.
Not saying these are good reasons, but in a company whose main products are closed-source software, I'd expect some PM to make these objections.
> It might have vulnerabilities that a motivated attacker could discover by reading the source code.
I'm sure the flipside of that, that lots of people looking at the code will uncover the vulnerability and fix it, more than compensate for that.
> It might contain copied code that Microsoft doesn't have the right to distribute.
This is why opensourcing an existing codebase can be complicated, but, if you start something managing the licenses of included code, then it's not a huge issue.
> in a company whose main products are closed-source software, I'd expect some PM to make these objections.
I'm sure they'll never opensource Exchange, SharePoint, or SQL Server.
