So they have been working on uograding this since 2014? So far, the visible results seem a bit underwhelming for the invested time and effort. How big is the team? What am I missing here?
Inside the Windows Console
11–20 of 259 posts
Re: Inside the Windows Console
#12I'm not sure why the author is so excited! But it makes the article a bit difficult to read!
That's Rich for you - He's pretty passionate about everything we do :)
Re: Inside the Windows Console
#13Earlier quoted context omitted.
Powershell. All of these shortcomings were fixed in it. Currently its also supported in Windows/*nix
I love Powershell, but it still uses the exact same ConHost as cmd and command.com before it. When scripting PS this is a non-issue, but using it interactively remains painful.
May I ask what your specific pain points are? We've been doing a lot to try and improve our usability but there's so very much on our backlog that it's hard to prioritize. I'm always curious if people have specific requests
edit: pain points with conhost*. I work on conhost, the "terminal", not PowerShell
Re: Inside the Windows Console
#14So they have been working on uograding this since 2014? So far, the visible results seem a bit underwhelming for the invested time and effort. How big is the team? What am I missing here?
Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows.
Not only that, but since the team was founded we discovered that conhost was not the only console implementation in Windows, though it's the only one available on Desktop. There was a pretty massive undertaking to unify all the separate console implementations on different SKUs under one application, so that all of them would be improved at the same time. It didn't have a terrible lot of impact on the everyday developer, but it was important to help internal engineering efforts.
Re: Inside the Windows Console
#15Earlier quoted context omitted.
I love Powershell, but it still uses the exact same ConHost as cmd and command.com before it. When scripting PS this is a non-issue, but using it interactively remains painful.
May I ask what your specific pain points are? We've been doing a lot to try and improve our usability but there's so very much on our backlog that it's hard to prioritize. I'm always curious if people have specific requests edit: pain points with conhost*. I work on conhost, the "terminal", not PowerShell
Not the parent, but personally, my only real pet peeve with PowerShell as an IT admin is that the right click start menu replaced cmd with PowerShell despite it still being drastically slower to load on many PCs. There's a setting to change it back, but if you are working on other computers all the time, that's not useful at all. This is my main peeve with the Settings panel as well: It's slower to get things done with, but the legacy panels have been intentionally made harder to reach[1] before performance parity has been reached.
My understanding is that improving PowerShell's start time is a big part of the next release of Windows 10, and that's great, but once that's done was the right time to put PowerShell as the default console on Windows, not before. 98% of why I open a prompt is to run "ping", and waiting for the prompt to actually show up in PS takes longer than a ping timeout. (Which is to say, if you need one takeaway from this post: Remember that no matter how cool you make PowerShell, most of us are only opening it to ping something, that's the most important experience to get right.)
Especially some of the decisions with the install screens for Windows 10 seem to highlight that people at Microsoft aren't aware how some subtle changes cause significant pain/delay for IT folks. Like with 1803 being forced to come up with security questions when creating the local account on a PC you're about to domain join.
[1]Example: Programs and Features from the legacy control panel no longer appears in search, even if you type it all the way out. Typing "appwiz.cpl" is the fastest way to see what's installed on a computer (and what versions) at a glance, but kinda a pro trick.
Re: Inside the Windows Console
#16Earlier quoted context omitted.
I love Powershell, but it still uses the exact same ConHost as cmd and command.com before it. When scripting PS this is a non-issue, but using it interactively remains painful.
May I ask what your specific pain points are? We've been doing a lot to try and improve our usability but there's so very much on our backlog that it's hard to prioritize. I'm always curious if people have specific requests edit: pain points with conhost*. I work on conhost, the "terminal", not PowerShell
Can't speak for OP, but I tried migrating some of our workflow to Windows. First annoyance I hit was this one:
https://stackoverflow.com/questions/30418886/how-and-why-doe...
This may be by design, but there has to be a better way. Unix/Linux consoles have allowed mouse copy/paste for as long as I can remember and I've never experienced this bug over there.
Really annoying when you go out to lunch with a job running, only to come back to find that it's right where you left it. So many solutions to this problem like making the copy/paste mode harder to trigger accidently. Visual feedback that it's in that mode, or allowing the buffer to expand indefinitely when copy mode is triggered.
Pausing the job is the last thing I'd want, especially since this seems to easy to trigger accidentally.
Re: Inside the Windows Console
#17Earlier quoted context omitted.
May I ask what your specific pain points are? We've been doing a lot to try and improve our usability but there's so very much on our backlog that it's hard to prioritize. I'm always curious if people have specific requests edit: pain points with conhost*. I work on conhost, the "terminal", not PowerShell
Not the parent, but personally, my only real pet peeve with PowerShell as an IT admin is that the right click start menu replaced cmd with PowerShell despite it still being drastically slower to load on many PCs. There's a setting to change it back, but if you are working on other computers all the time, that's not useful at all. This is my main peeve with the Settings panel as well: It's slower to get things done wi…
You could change the right click back to cmd by using a group policy to change the registry. E.g. https://blogs.msmvps.com/russel/2016/11/18/defaulting-to-pow...
Re: Inside the Windows Console
#18Earlier quoted context omitted.
Yeah, this 30 years old code-base.. besides it is questionable only dev's below 30yr old are working on it (age discrimination, or accidental?), hardly anything changed. If I want to copy something I still have to do the ancient mark and copy sequence from the right click menu! What are they working on then? Still fixing bugs?
Have you tried enabling QuickEdit mode in the Properties (right click on the titlebar)? Quick edit lets you use the mouse for selecting, and in Insider's releases we've even added support for Ctrl+Shift+C/V for copy paste (even in wsl!). We've been working on not only tons of bugs, but adding plenty of new features, including support for VT sequences, 256/RGB color, improving our unicode support, enhanced accessibili…
Why do you need to select quick edit to be able to copy? That makes no sense.
Re: Inside the Windows Console
#19Earlier quoted context omitted.
Not the parent, but personally, my only real pet peeve with PowerShell as an IT admin is that the right click start menu replaced cmd with PowerShell despite it still being drastically slower to load on many PCs. There's a setting to change it back, but if you are working on other computers all the time, that's not useful at all. This is my main peeve with the Settings panel as well: It's slower to get things done wi…
You could change the right click back to cmd by using a group policy to change the registry. E.g. https://blogs.msmvps.com/russel/2016/11/18/defaulting-to-pow...
Also true, but there's a limit to how much nonsense you want to dump into GPOs. Most of what you throw in your Group Policy will inevitably end up sticking around for the next decade and a half long past its irrelevance, and regardless of whether you throw everything in one big GPO or have several dozen small GPOs, you will never remember where that stupid setting came from down the road.
So I'm hesitant to go overboard on custom registry entry pushes (as opposed to the standard templates) for things that only affect IT experience.
Re: Inside the Windows Console
#20The article seems to ignore the other big problem with the Windows console. It is painfully slow compare to Linux and Mac terminal programs. Especially when scrolling large amounts of text.