That is _technically_ correct (the best kind). There's some plumbing between conhost and Terminal we need to clean up before we can add it to Terminal too. We've got a branch ready, we've just got to merge a whole stack of PRs first before we can get there.
We shipped it (the Terminal) with the first versions of Windows 11. I don't think the "default terminal" feature defaulted to the new Terminal in the first win11 builds, but it should now. And you can always pick whichever terminal you want as the default terminal
Conhost and Terminal share quite a lot of code in fact. The text buffer, the renderer, the VT sequence parser - all that's the same codebase. That allows bugfixes and improvements to the the Terminal to also flow back to the vintage console (for people who still use that)
This is a great write up, thanks for sharing. I had never heard of these before, and would usually be totally against a subscription based product like that. But the idea of totally bypassing their "drm" for 1/60th the cost? Much more intriguing
Happy to have the feedback! Most of those I've already fixed internally, there's just a 3-4 week delay between me checking in, and it flowing to Insiders.
For the other few things I missed: Very happy for the feedback! I've filed bugs and those'll be the first things I look at come Monday morning.
There are security implications for running elevated processes connected to unelevated console/terminal windows. "New window" mode avoids those security concerns. A secure-by-default posture seemed prudent.
Yep, that's basically the entire diagram. The information that's passed is basically just the commandline, env vars, and a handle to the console of the unelevated sudo's console. Once it's got a handle to the console, the elevated sudo can spawn the target app attached to the original console, rather than a new one. Simple as that!
> This looks like one of those KPI fulfilling projects
It actually wasn't. This has been one of the top community requests for the Windows Command Line for years. Literally, for like, the entire 8 years I've been here, we've been talking about if there was a way to do Sudo for Windows.
This was done because it makes developers happy, plain and simple. If that's a KPI, then that's the one we're optimizing for.
There are several ways to do sudo for Windows already, to the extent this program does sudo for Windows.
In other words, you're not actually solving the reason people are asking you for sudo for Windows. How do I configure my sudoers policy to allow someone to run a specific application (and only that application) through sudo? THAT is the magic of sudo. Sudo is not just "use your own password for root" like you seem to think it is.
I live by a one step at a time philosophy. It's better to make some incremental progress here, now, and open the door for future progress in this space too. Just like the Terminal - what we're putting out here in the first versions is just the first thing we feel comfortable with people using. We've got lots of ideas for more things to add, just, one step at a time :)
I don't know why people are so negative on this project. I already know about gsudo and yet I was still happy to see an official solution! Even if it were to never evolve, not having to pull a third-party executable in is always nice.
I'd say waking up today to all this... negativity? was kinda a bummer. We've been working hard on something that people (myself included) have been asking for _for years_.
Like, obviously, it's not perfect out of the gate. That's fine! It was a haul enough to ship this in any form. Now that it's out there, we can make more and more improvements. One step at a time.
Sometimes, I just need a break from the internet I guess.
Because it isn't sudo. It's a marketing effort stealing the name of sudo for a completely different technology that is only tangentially related to sudo.
