One thing I've always missed is tabbed consoles. I've use Cmder ( http://cmder.net/ I have no affiliation) for quite a while now and has been totally awesome as it provides a tabbed container window with any mixture of cmd.exe, bash shell, launching as Admin and best of all it persists all your windows after reboot.
Inside the Windows Console
171–180 of 259 posts
Re: Inside the Windows Console
#172Yikes, the anti-Windows crowd is strident today. Yeah, cmd.exe is crap, and if you're expecting to use a Unix workflow rather than learn how things work in Windows, you're going to have a bad time. I'm not sure that religiously sticking to the baggage and constraints of obsolete hardware from fifty years ago is really a great ideal either... But you just can't change existing shit willynilly in Windows, with the kind…
> I'm not sure that religiously sticking to the baggage and constraints of obsolete hardware > But you just can't change existing shit willynilly in Windows, with the kind of install base and legacy it has, You do see the irony, right?
I think his (?) point is that if you don't have the backwards-compatibility goals of Windows, you can afford to be - and perhaps should be - a lot more adventurous. Which is something POSIX systems have summarily failed to be in this respect, for all that they've managed to polish that turd to an acceptable shine.
Re: Inside the Windows Console
#173Earlier quoted context omitted.
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…
He can't say it publicly but the code behind the console is crap. Not just from a modern perspective looking back, the original devs hated it too. The book Show Stopper! Has some colorful words about it. And since it's so core to the system and deeply intertwined you can't just go in and start arbitrarily changing things. Everyone has been too scared to touch it for the last 20 years. This is painstaking careful work…
Oh no, I can say that quite publicly. When I started on the team in 2015, that code was some nightmarish shit. It was hardly componentized, you'd have 70 different places in the code all calling out to GDI to do rendering at seemingly random points in the app's lifecycle. It was painful to get work done in the codebase.
After a LOT of refactoring it's finally in a state that's really quite managable, and much more modernized.
Re: Inside the Windows Console
#174Earlier quoted context omitted.
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…
Pty-like API sounds great. I assume you are referring to what's discussed here https://github.com/Microsoft/console/issues/57 .
Yep that's it!
Re: Inside the Windows Console
#175Earlier quoted context omitted.
Its not quite UNIX style - it works like a weird frame selection instead of follow the text LtR like any *nix console I can think of. It would be super if that could be fixed as well with an option.
I'm pretty sure it's block/column selection instead of line selection. Why they made that design decision, we will never know. Maybe a dev was working with a lot of hex output? (even so, he should be slapped retroactively, unless he's Raymond Chen, cause Raymond Chen is amazing so we'll forgive his transgressions)
The console 'screen' is a grid of (character,attribute) pairs, so there are no lines as such...
I'm not sure the box selection is super useful these days, but in the late 80s/early 90s, GUI-style interfaces were very popular, and a box selection makes a certain amount of sense, so you can avoid picking up borders and so on. Would have been nice if they'd got both types in from day 1 though...
Re: Inside the Windows Console
#176Earlier quoted context omitted.
He can't say it publicly but the code behind the console is crap. Not just from a modern perspective looking back, the original devs hated it too. The book Show Stopper! Has some colorful words about it. And since it's so core to the system and deeply intertwined you can't just go in and start arbitrarily changing things. Everyone has been too scared to touch it for the last 20 years. This is painstaking careful work…
Oh no, I can say that quite publicly. When I started on the team in 2015, that code was some nightmarish shit. It was hardly componentized, you'd have 70 different places in the code all calling out to GDI to do rendering at seemingly random points in the app's lifecycle. It was painful to get work done in the codebase. After a LOT of refactoring it's finally in a state that's really quite managable, and much more mo…
I hope you updated all that to D2D. I was always deeply offended you forced office to move with Universal but had the gall to link GDI in and keep using it for your own stuff :).
Re: Inside the Windows Console
#177Earlier quoted context omitted.
> I'm not sure that religiously sticking to the baggage and constraints of obsolete hardware > But you just can't change existing shit willynilly in Windows, with the kind of install base and legacy it has, You do see the irony, right?
I think his (?) point is that if you don't have the backwards-compatibility goals of Windows, you can afford to be - and perhaps should be - a lot more adventurous. Which is something POSIX systems have summarily failed to be in this respect, for all that they've managed to polish that turd to an acceptable shine.
What exactly are backwards-compatibility goals of Windows? Are they that different from backwards-compatibility goals of POSIX systems?
I read the above sentences as: 1) the legacy on $SYSTEMS_I_DONT_LIKE is bad 2) the legacy on $SYSTEM_I_LIKE is there for a reason.
Re: Inside the Windows Console
#178Earlier quoted context omitted.
Unfortunately it has no effect on the menu in Windows Explorer which also dropped cmd for PowerShell recently.
I tend not to use the file menu in Windows Explorer, but yeah it'd be nice if that option swapped it there too. I found out recently you can just type "cmd" in the Explorer address bar and hit enter and it'll open cmd.exe to the current directory, so long as you're not in a special shell folder or an unmapped network share. That's saved me a bunch of time.
I didn't know that. I usually just hit "ctrl + r" and then type in "cmd" and press "enter" and then navigate to the directory I want with "cd".
Your pointer will save me time.
Re: Inside the Windows Console
#179One thing I've always missed is tabbed consoles. I've use Cmder ( http://cmder.net/ I have no affiliation) for quite a while now and has been totally awesome as it provides a tabbed container window with any mixture of cmd.exe, bash shell, launching as Admin and best of all it persists all your windows after reboot.
Trust us, the pain on not having a tabbed console is felt here in the console team too. It's our most requested feature, but implementing it has always ended up a lot harder than expected. Fortunately we're working with the Tabbed Sets team to help nail that experience for the console.
Re: Inside the Windows Console
#180The 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.
I would agree that our perf isn't the best. Almost all of that comes down to our rendering stack - something like 90% of our CPU time is spent rendering the window. This is because at the moment we're stuck with GDI, and IIRC we have to kernel-thunk every row of text we render. It's not a great situation.
Stay tuned for updates in this area though. Improving this experience is one of our top priorities.