Inside the Windows Console(blogs.msdn.microsoft.com)
blogs.msdn.microsoft.com
Inside the Windows Console
https://blogs.msdn.microsoft.com/commandline/2018/07/10/windows-command-line-inside-the-windows-console/
258 comments
There's actually an option in Settings to swap between Powershell and cmd.exe in the Win + X menu.
On top of that you can actually go in and customise it quite a bit to your own liking as it's just a folder inside your local app data: C:\Users\YourWindowsUsername\AppData\Local\Microsoft\Windows\WinX
On top of that you can actually go in and customise it quite a bit to your own liking as it's just a folder inside your local app data: C:\Users\YourWindowsUsername\AppData\Local\Microsoft\Windows\WinX
Unfortunately it has no effect on the menu in Windows Explorer which also dropped cmd for PowerShell recently.
You can add a right-click "Console Here" menu item yourself. It's one of the things I've done on fresh installs of Windows since 95.
HKCR\*\shell\Console Here\command
Default="%WINDIR%\system32\cmd.exe"
HKCR\Directory\shell\Console Here\command
Default="%WINDIR%\system32\cmd.exe /k cd %1"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 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.
Your pointer will save me time.
I believe it should work with any executable in your PATH but I've never tried it with anything beyond cmd.exe to be honest.
Additional tip: use Cntl+L to get to Windows Explorer address bar, type cmd, enter.
Do you have something custom going on in powershell? I’m not a power user of windows shells but it opens very quickly for me. So much so that I never thought about the speed of either terminal.
"very quickly" is subjective, but compared to cmd it is noticeably slower even in a fresh install of Windows --- the few times I'm forced to actually use it to configure some things.
I think powershell is kept in memory so only the first start should be slow. Although I don't really notice the first start being slower anymore - maybe it preloads depending on settings or is just fast enough with an ssd?
Windows picks up usage patterns and pre-loads applications to match that. But indeed, right after launching an application it's still in the disk cache anyway, so subsequent launches (until heavy I/O) should be quick.
I'm not sure how often you start and stop your shells, but start time is seldom a concern.
I enjoy you chose Hyper.js, which uses electron. I'm not sure what speed you were expecting there. You might try ConEmu https://conemu.github.io/.
I enjoy you chose Hyper.js, which uses electron. I'm not sure what speed you were expecting there. You might try ConEmu https://conemu.github.io/.
I love ConEmu, but it's still pretty slow starting up
What's your definition of slow?
ConEmu takes about 1 full second to open a new window. Not too bad.
But oddly enough, opening a new split panel takes about 2 seconds, which IMO is starting to feel slow, but it's not too big of a deal.
ConEmu takes about 1 full second to open a new window. Not too bad.
But oddly enough, opening a new split panel takes about 2 seconds, which IMO is starting to feel slow, but it's not too big of a deal.
You can choose to have it run on startup and keep it in the system tray, that'll help with the startup time.
Hi there! Author of the post that's the subject of this thread here :)
Two questions:
1. Does your machine use a spinning disk for its system drive, or SSD? If the former, that's slowing you down more any anything else. STRONGLY recommend moving to SSD system drive if so. 2. Have you tried `powershell /noprofile` from Run dialog or Cmd? If you're still seeing PowerShell take > 600ms to load and start, likely something else is up.
If you're expecting PowerShell to load faster than ~600ms, your expectations are likely a little out of whack - Cmd loads so fast because it's tiny and - relatively speaking - as dumb as a stump. PowerShell is a .NET language, and so loads the CLR, so incurs some overhead vs. Cmd, but it does A TON more that'll save you more time and effort over-all than any amount of time saving vs. starting Cmd.
HTH.
Two questions:
1. Does your machine use a spinning disk for its system drive, or SSD? If the former, that's slowing you down more any anything else. STRONGLY recommend moving to SSD system drive if so. 2. Have you tried `powershell /noprofile` from Run dialog or Cmd? If you're still seeing PowerShell take > 600ms to load and start, likely something else is up.
If you're expecting PowerShell to load faster than ~600ms, your expectations are likely a little out of whack - Cmd loads so fast because it's tiny and - relatively speaking - as dumb as a stump. PowerShell is a .NET language, and so loads the CLR, so incurs some overhead vs. Cmd, but it does A TON more that'll save you more time and effort over-all than any amount of time saving vs. starting Cmd.
HTH.
Well, re:
>1. Does your machine use a spinning disk for its system drive, or SSD?
This really shouldn't be a question regarding the performance of a terminal window.
If cmd.exe starts fast regardless, then so should Powershell if it is going to replace it.
And on that note, on a new laptop with an SSD I can see a difference between Powershell and cmd.exe execution-to-prompt-ready time (however small that latency is).
As long as that's the case, Powershell simply isn't a viable replacement for cmd.exe
>1. Does your machine use a spinning disk for its system drive, or SSD?
This really shouldn't be a question regarding the performance of a terminal window.
If cmd.exe starts fast regardless, then so should Powershell if it is going to replace it.
And on that note, on a new laptop with an SSD I can see a difference between Powershell and cmd.exe execution-to-prompt-ready time (however small that latency is).
As long as that's the case, Powershell simply isn't a viable replacement for cmd.exe
I am not comparing performance of a terminal window - Cmd and PowerShell both run connected to the same terminal app - Windows Console (conhost.exe) as discussed ad nauseum in the posts that are the subject of this thread.
But you're comparing a 30+ year old command-line shell that was built in 1989 to primarily provide compatibility with MS-DOS, with a modern object-based shell that runs atop the .NET CLR and provides VASTLY more power and capability than the MUCH older, simpler, shell that it supersedes.
It's like comparing startup perf of Notepad and VSCode … and saying that you won't use VSCode until it starts up as quickly as Notepad, even if VSCode saves you HOURS more per day/week than using Notepad would.
But you're comparing a 30+ year old command-line shell that was built in 1989 to primarily provide compatibility with MS-DOS, with a modern object-based shell that runs atop the .NET CLR and provides VASTLY more power and capability than the MUCH older, simpler, shell that it supersedes.
It's like comparing startup perf of Notepad and VSCode … and saying that you won't use VSCode until it starts up as quickly as Notepad, even if VSCode saves you HOURS more per day/week than using Notepad would.
Sure, sure, more functionality.
That's not an excuse for the startup time of a shell not being instantaneous on a modern system.
To harness the power, I write Powershell scripts (yay no more batch files), but it's just too annoying to experience the startup lag to use the shell for the simplest tasks (e.g. simply running a console application).
That shouldn't be the case.
PS: "modern object-oriented" was all the hype in the 80-s. It's not an excuse for a performance hit today :)
That's not an excuse for the startup time of a shell not being instantaneous on a modern system.
To harness the power, I write Powershell scripts (yay no more batch files), but it's just too annoying to experience the startup lag to use the shell for the simplest tasks (e.g. simply running a console application).
That shouldn't be the case.
PS: "modern object-oriented" was all the hype in the 80-s. It's not an excuse for a performance hit today :)
You mention Hyper. Are you running PowerShell connected to Hyper or Console?
If you're running Hyper, note that this alone takes 6s to (warm) start Cmd on my 16GB RAM Core-i7 Surface Pro 4.
PowerShell takes ~1.2s to (warm) start connected to Console, while also starting a half dozen modules and scripts in my PowerShell user profile.
PowerShell takes < .7s to start when run with `-NoProfile`
If you're running Hyper, note that this alone takes 6s to (warm) start Cmd on my 16GB RAM Core-i7 Surface Pro 4.
PowerShell takes ~1.2s to (warm) start connected to Console, while also starting a half dozen modules and scripts in my PowerShell user profile.
PowerShell takes < .7s to start when run with `-NoProfile`
Oh … and re. Hyper - its awesome and beautiful, but it's an Electron app which means you're first loading and starting Electron base, then Chromium's JS & HTML engines, then loading A TON of JavaScript which has to be tokenized, parsed, compiled and executed every time you run it.
This doesn't come cheap. Electron consumes & fills ~100MB working set just to get rolling, plus several more tens of MB to load, compile and execute.
For example, on my 16GB Core-i7 Surface Pro 4, starting a single Hyper instance connected to Cmd, requires 134MB. Starting Console takes < 1s, and consumes 6MB.
This doesn't come cheap. Electron consumes & fills ~100MB working set just to get rolling, plus several more tens of MB to load, compile and execute.
For example, on my 16GB Core-i7 Surface Pro 4, starting a single Hyper instance connected to Cmd, requires 134MB. Starting Console takes < 1s, and consumes 6MB.
cmd.exe is not getting any improvements, for better or for worse.
And Powershell Core (Powershell 6) is quite snappy. Try it out. They changed the name to pwsh.exe, you can have them in parallel in your PATH.
And Powershell Core (Powershell 6) is quite snappy. Try it out. They changed the name to pwsh.exe, you can have them in parallel in your PATH.
Powershell 5 is slow.
Powershell 6 preview is much faster (not as fast as bash but does more)
Powershell 6 preview is much faster (not as fast as bash but does more)
PS you can download it here
https://github.com/PowerShell/PowerShell/releases
https://github.com/PowerShell/PowerShell/releases
I think your experience is atypical. I use powershell everyday and I've not noticed any startup time difference between it and cmd. Are you sure you don't have some gigantic import in your profile.ps1? Are you launching the really terrible and definitely slow as balls to launch Powershell IDE?
Frankly, given how superior powershell is as a language (both to cmd and bash) it is beyond me why anyone would consider a small startup cost difference a dealbreaker anyway.
Frankly, given how superior powershell is as a language (both to cmd and bash) it is beyond me why anyone would consider a small startup cost difference a dealbreaker anyway.
I've got no powershell customizations, and an i5-4670k. I've also experienced Powershell having a very noticeably slow startup. It's about on par with my heavily modified zsh setup on a 2015 MBP for startup time (the same zsh setup starts up much faster on the same desktop).
It's not a dealbreaker, but it's definitely an annoyance.
It's not a dealbreaker, but it's definitely an annoyance.
Very strange. My work rig is a downright geriatric Core2 Quad @ 2.66Ghz. There has to be some reason for the difference.
I think it's pretty typical: powershell is slower to start up than cmd. On my machine, i7, 16GB RAM, Windows 10, the fastest is cmd (instantaneous), then powershell (1s) and bash WSL (1s), then supper slow default install of git-bash (12s!). I cannot use git-bash because of that.
I just keep one or two shells open all day.
Technical errors regarding how UTF encodings work:
* UTF-8 is at maximum four bytes per codepoint (which aren't characters, since multiple codepoints can make up a single character... see combining diaretics or ZWJ emoji things). "additional 1-4 bytes" should be "additional 1-3 bytes" (Historically, UTF-8 did support 5- and 6-byte sequences, and if you read up on it, the implementation is obvious, but that was before Unicode settled on U+10FFFF[1] being the maximal codepoint for backwards compatibility reasons with UCS-2...)
* It says UTF-16 extends UCS-2 (which is correct) by incorporating a 4-bit encoding... which probably was intended to be a "4-byte encoding" instead. The surrogate pairs reserve their first six bits for an additional 10 bits making up half of the codepoint being stored (whose value is later added to by 0x10000 to get the actual codepoint). Also, it provides 16 additional planes to the BMP. 17 total including the BMP.
[1] Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints on every plane are reserved and declared as noncharacters. Few parsers are really so strict.
* UTF-8 is at maximum four bytes per codepoint (which aren't characters, since multiple codepoints can make up a single character... see combining diaretics or ZWJ emoji things). "additional 1-4 bytes" should be "additional 1-3 bytes" (Historically, UTF-8 did support 5- and 6-byte sequences, and if you read up on it, the implementation is obvious, but that was before Unicode settled on U+10FFFF[1] being the maximal codepoint for backwards compatibility reasons with UCS-2...)
* It says UTF-16 extends UCS-2 (which is correct) by incorporating a 4-bit encoding... which probably was intended to be a "4-byte encoding" instead. The surrogate pairs reserve their first six bits for an additional 10 bits making up half of the codepoint being stored (whose value is later added to by 0x10000 to get the actual codepoint). Also, it provides 16 additional planes to the BMP. 17 total including the BMP.
[1] Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints on every plane are reserved and declared as noncharacters. Few parsers are really so strict.
> Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints on every plane are reserved and declared as noncharacters. Few parsers are really so strict.
This is what Unicode 11.0, §2.4 says:
Noncharacter code points are reserved for internal use, such as for sentinel values. They have well-formed representations in Unicode encoding forms and survive conversions between encoding forms. This allows sentinel values to be preserved internally across Unicode encoding forms, even though they are not designed to be used in open interchange.
It would wrong for a general-purpose parser to reject these codepoints.
This is what Unicode 11.0, §2.4 says:
Noncharacter code points are reserved for internal use, such as for sentinel values. They have well-formed representations in Unicode encoding forms and survive conversions between encoding forms. This allows sentinel values to be preserved internally across Unicode encoding forms, even though they are not designed to be used in open interchange.
It would wrong for a general-purpose parser to reject these codepoints.
Hmm, alright. I have seen parsers reject them, presumably from misinterpreting the standard.
Thanks for the correction :)
Thanks for the correction :)
Hi - Windows Console PM and author of the post here :)
You're absolutely correct.I made some fixes, adjustments, and clarifications to the post this afternoon - hope they're a little more accurate.
We'll be digging into this area in much more detail in future posts.
You're absolutely correct.I made some fixes, adjustments, and clarifications to the post this afternoon - hope they're a little more accurate.
We'll be digging into this area in much more detail in future posts.
The 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.
Stay tuned for updates in this area though. Improving this experience is one of our top priorities.
GDI?!
Throw that bad boy into the abandoned WPF framework and hardware accelerate it! (Without the sandbox shengigans of UWP in the way)
Throw that bad boy into the abandoned WPF framework and hardware accelerate it! (Without the sandbox shengigans of UWP in the way)
Hi. Windows Console PM, and @zadjii's whipping boy here :)
LOL :) Nice idea - though it turns out that this won't help. Don't ask me why we know this ;)
We DO, however, (as @zadjii indicates above) have plans afoot to considerably improve Console's text rendering.
Also note that scrolling speed is actually not a good measure of rendering perf! Why? Because at most, scrolling should max-out at around one vertical page every 1/60 of a second. Any more than that and the text tears.
This may or may not be an issue for some, but tearing the text upsets people who're visually looking for a particular text layout-pattern which might get discarded if the Console scrolls faster than one page per refresh.
This said, yes, we're gonna get faster with less CPU ;)
LOL :) Nice idea - though it turns out that this won't help. Don't ask me why we know this ;)
We DO, however, (as @zadjii indicates above) have plans afoot to considerably improve Console's text rendering.
Also note that scrolling speed is actually not a good measure of rendering perf! Why? Because at most, scrolling should max-out at around one vertical page every 1/60 of a second. Any more than that and the text tears.
This may or may not be an issue for some, but tearing the text upsets people who're visually looking for a particular text layout-pattern which might get discarded if the Console scrolls faster than one page per refresh.
This said, yes, we're gonna get faster with less CPU ;)
I regularly use both Windows and Linux, and I can't say that I've ever noticed a performance problem?
The terminals you use in Linux must either be painfully slow or you must be very insensitive to latency issues because the latency on Windows console is really high. When I type something I expect it to appear immediately (<10ms), not in 20-50ms. I'm just guessing the timings here though but the point is that there's definitely a difference.
A lot of basic commands in general run more slowly on Windows but I don't think that's the terminal's fault so much as it's lack of optimisation on the command itself.
A lot of basic commands in general run more slowly on Windows but I don't think that's the terminal's fault so much as it's lack of optimisation on the command itself.
Afaik, 10ms is not achievable nowadays, unless you use a very old computer. https://danluu.com/input-lag/
> For desktop results, results are measured from when the key started moving until the screen finished updating
When the key starts moving and when the key actually actuates are very different times. Some of this latency could be key travel time. This is also a methodical issue I found with his [keyboard latency test](https://danluu.com/keyboard-latency/).
When the key starts moving and when the key actually actuates are very different times. Some of this latency could be key travel time. This is also a methodical issue I found with his [keyboard latency test](https://danluu.com/keyboard-latency/).
Do you have any recommendation to get at least a decent latency (< 30 ms) on linux or windows 10?
The least infuriating to me is lxterm. Consoles (no X) used to feel ok several years ago, but now I use fbuffer it feels slower (and I can't do without because high screen resolutions make fonts tiny, even with setfont)
The least infuriating to me is lxterm. Consoles (no X) used to feel ok several years ago, but now I use fbuffer it feels slower (and I can't do without because high screen resolutions make fonts tiny, even with setfont)
I'd be curious to see the original IBM PC/XT/AT tested too. I guess it would be near the low end of the list too.
Also, the last entry in the list provides another reason why Lisp machines never became popular --- 300ms of input lag! That's definitely in unusable territory, especially when other machines of the time were almost an order of magnitude faster.
Also, the last entry in the list provides another reason why Lisp machines never became popular --- 300ms of input lag! That's definitely in unusable territory, especially when other machines of the time were almost an order of magnitude faster.
If you look at the table you'll see that the 3620 from Symbolics in 1986 was an entirely different system. It had a megapixel bitmap-only screen as a separate console (which had mouse, keyboard, serial and an audio interface) with console cables often of 30 meters. The refrigerator size machines often would be running in some machine room and the console would be used in some office room. The console was handled by a separate Front End Processor with a communication protocol over the console cable. An entirely different technology for a different setup.
Later Symbolics Lisp machines used different technology for the graphics system, but basically the same console setup.
See here for some more info about the 3620: http://lispm.de/3620/3620.html
Later Symbolics Lisp machines used different technology for the graphics system, but basically the same console setup.
See here for some more info about the 3620: http://lispm.de/3620/3620.html
So, I mainly use Cmder on Windows 10 these days (which uses ConEmu under the hood). I just tried typing in Windows cmd, Cmder and WSL, as well as a CentOS terminal. If I really try to notice it, I concede that there is tiny bit of latency in the Windows cmd console.
Maybe it is just me (willing to accept it is!), but I actually have to try to notice any difference, and even then, it's barely noticeable.
Maybe it is just me (willing to accept it is!), but I actually have to try to notice any difference, and even then, it's barely noticeable.
[deleted]
Write a simple program that outputs 10k lines of text, then compile and run on Linux and Windows. It's night and day.
[deleted]
Are you using a high-DPI display? In my experience, scrolling in the console is much slower on a high-DPI display.
Yes, but I use HiDPI displays on Linux and macOS as well.
I’ve just run “tree /f” from the root of my drive. It printed huge amounts of text but the scrolling remained instant.
I think your big problem is not necessarily with Windows console, could be with the command-line apps you’re using in it.
I think your big problem is not necessarily with Windows console, could be with the command-line apps you’re using in it.
Is that true for other UIs like conemu?
Good question. The article says that
> Alas, the story here is not a good one: There ARE some great 3rd party Consoles (and server apps) for Windows (e.g. ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH, etc.), but they have to jump through extraordinary hoops to act like a normal Console would!
> For example, 3rd party Consoles have to launch a Command-Line app off-screen at, for example, (-32000,-32000). They then have to send keystrokes to the off-screen Console, and screen-scrape the off-screen Console's text contents and re-draw them on their own UI!!
I'd guess that the third party emulators might perform worse, but someone need to test it empirically.
> Alas, the story here is not a good one: There ARE some great 3rd party Consoles (and server apps) for Windows (e.g. ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH, etc.), but they have to jump through extraordinary hoops to act like a normal Console would!
> For example, 3rd party Consoles have to launch a Command-Line app off-screen at, for example, (-32000,-32000). They then have to send keystrokes to the off-screen Console, and screen-scrape the off-screen Console's text contents and re-draw them on their own UI!!
I'd guess that the third party emulators might perform worse, but someone need to test it empirically.
That bit you've quoted is only half the story. I've written both terminal emulators as well as ported my own UNIX shell to Windows and never resorted to those kind of tricks. However the stuff I've focused on isn't interactive commands (ie just normal POSIX-like file streams). The moment you envoke "del" or other command that prompts "Are you sure you want to delete" (or whatever) then for some odd reason Windows just jumps over that STDIN read request and ploughs through the rest of the program.
I can't say if this is a bug in my shell specifically or a wider problem that has lead to the work around you described, but it's literally the only problem left in my Windows port and I'm definitely not smarter than average nor have I spent any excessive time working in Windows so I cannot see how I might have solved problems that other shells are still grappling with given the limited time I've spent on the Windows specific portion of the code.
As for the bug itself, I get this is a pretty major bug which severally hampers the usability of the shell but I think given enough time (and a new development machine to test it one since I now longer have access to a Windows laptop after changing jobs) I could get this bug solved too. Hopefully without resorting to the kludge you described, but who knows.
I can't say if this is a bug in my shell specifically or a wider problem that has lead to the work around you described, but it's literally the only problem left in my Windows port and I'm definitely not smarter than average nor have I spent any excessive time working in Windows so I cannot see how I might have solved problems that other shells are still grappling with given the limited time I've spent on the Windows specific portion of the code.
As for the bug itself, I get this is a pretty major bug which severally hampers the usability of the shell but I think given enough time (and a new development machine to test it one since I now longer have access to a Windows laptop after changing jobs) I could get this bug solved too. Hopefully without resorting to the kludge you described, but who knows.
Actually, the part that you have addressed is half the story.
I wrote about both halves a couple of decades ago.
* http://jdebp.info./FGA/capture-console-win32.html
I wrote about both halves a couple of decades ago.
* http://jdebp.info./FGA/capture-console-win32.html
Interesting read. Thank you.
I wonder how many programs are still using low level access these days given that's more a throw over from the DOS days and most languages will have proper frameworks for reading and writing from the NT console. del et al being obvious exceptions because they're just cmd.exe builtins.
Unfortunately I don't have a Windows system to test that assumption but when I think about when I last did my testing, that was only against the cmd.exe builtins so it's possible this bug I was experiencing isn't as widespread as I assumed
I wonder how many programs are still using low level access these days given that's more a throw over from the DOS days and most languages will have proper frameworks for reading and writing from the NT console. del et al being obvious exceptions because they're just cmd.exe builtins.
Unfortunately I don't have a Windows system to test that assumption but when I think about when I last did my testing, that was only against the cmd.exe builtins so it's possible this bug I was experiencing isn't as widespread as I assumed
Is your shell on github?
Indeed. https://github.com/lmorg/murex
However I'd still recommend WSL or Powershell over my shell for Windows use as I haven't invested an great amount of time on the Windows port (and certainly haven't used nor tested it extensively on Windows like I do on Linux and FreeBSD). Though at some point - probably after I've finished documenting the thing - I do plan to go back and revisit the Windows port.
However I'd still recommend WSL or Powershell over my shell for Windows use as I haven't invested an great amount of time on the Windows port (and certainly haven't used nor tested it extensively on Windows like I do on Linux and FreeBSD). Though at some point - probably after I've finished documenting the thing - I do plan to go back and revisit the Windows port.
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.
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.
Hi - Windows Console PM and author of the Command-Line posts here.
We hear ya. Tabs are VERY high up our to-do list, but to get there, we had a TON of internal engineering and modernization to do to wrangle the ~30 year old codebase into a shape where we could efficiently and effectively work on UX features.
We're now nearing the completion of the core re-engineering effort and will start to turn to more UX-visible features in the next few releases.
Bear with us - TONS of exciting stuff coming soon!
We hear ya. Tabs are VERY high up our to-do list, but to get there, we had a TON of internal engineering and modernization to do to wrangle the ~30 year old codebase into a shape where we could efficiently and effectively work on UX features.
We're now nearing the completion of the core re-engineering effort and will start to turn to more UX-visible features in the next few releases.
Bear with us - TONS of exciting stuff coming soon!
Another Cmder lover here. Although when the Windows 10 "Sets" UI comes out and default Powershell/conhost has tabs built in, it may be time to just stick with that. We'll see...
Pretty unhappy Cmder user here.
Sooo many bugs. Currently have dash.exe crashes on start-up, fatal race conditions generating certain types of error output, performance becomes unusable in git folders with lots of files because of how it updates the auto-text in the prompt and it has the configuration/settings from hell but they just blame ConEmu.
I just want a tabbed console that will remember the tab locations and command history between sessions. This would seem obvious thing but no.
Sooo many bugs. Currently have dash.exe crashes on start-up, fatal race conditions generating certain types of error output, performance becomes unusable in git folders with lots of files because of how it updates the auto-text in the prompt and it has the configuration/settings from hell but they just blame ConEmu.
I just want a tabbed console that will remember the tab locations and command history between sessions. This would seem obvious thing but no.
I run mosh on windows 10 over bash inside cmder, I have had a few weird issues too. I thought I was the one at fault!!
As a nix person who now spends his entire day in the Windows terminal, I wrote a guide to setting up the console and pwsh for maximum productivity:
https://github.com/mikemaccana/powershell-profile/blob/maste...
https://github.com/mikemaccana/powershell-profile/blob/maste...
I really like the point that an API-centric console does not remote well (think ssh).
In general I prefer the WIN32 object-handle model to the Unix file-descriptor model, and I much prefer the WIN32 security descriptor and access token model to the Unix haphazard security model, but very clearly, the everything-is-a-file model is superior at least for remote access: it's easier to design and implement protocols for that since the protocols don't need to know anything about the remote resources' nature. Thus the Windows console cannot be exported via SSH, not without writing a layer that converts text reads/writes into ioctls, because it's not remotely file-like. That the Windows team had to and did write that layer really is fantastic news.
In general I prefer the WIN32 object-handle model to the Unix file-descriptor model, and I much prefer the WIN32 security descriptor and access token model to the Unix haphazard security model, but very clearly, the everything-is-a-file model is superior at least for remote access: it's easier to design and implement protocols for that since the protocols don't need to know anything about the remote resources' nature. Thus the Windows console cannot be exported via SSH, not without writing a layer that converts text reads/writes into ioctls, because it's not remotely file-like. That the Windows team had to and did write that layer really is fantastic news.
Very interesting. I learned a lot.
The author mentions "re-re-re-implementing" command line history as a disadvantage of using shells in a dumb terminal emulator.
But, with respect, I think he's wrong about that. Command line history is a valuable productivity enhancer, and tying the details of its operation to the terminal rather than the shell restricts functionality and flexibility. For example, witness the differences between git bash (mingw) and cmd on Windows.
Inbuilt OS stuff should be as simple as possible. It doesn't have to be precisely /dev/tty - like, but it should be simple. Partly to avoid bloat, and partly because it's much less flexible than userland stuff.
Even when RAM was worth twice its weight in gold, various UNIX shells weren't heavy. Now? not worth worrying about.
I admit I came up as a UNIX user so I favor sh-like history. But still, Windows terminal history just isn't as good. (I wish it didn't deduplicate repeated commands and lose them when they're edited.)
The author mentions "re-re-re-implementing" command line history as a disadvantage of using shells in a dumb terminal emulator.
But, with respect, I think he's wrong about that. Command line history is a valuable productivity enhancer, and tying the details of its operation to the terminal rather than the shell restricts functionality and flexibility. For example, witness the differences between git bash (mingw) and cmd on Windows.
Inbuilt OS stuff should be as simple as possible. It doesn't have to be precisely /dev/tty - like, but it should be simple. Partly to avoid bloat, and partly because it's much less flexible than userland stuff.
Even when RAM was worth twice its weight in gold, various UNIX shells weren't heavy. Now? not worth worrying about.
I admit I came up as a UNIX user so I favor sh-like history. But still, Windows terminal history just isn't as good. (I wish it didn't deduplicate repeated commands and lose them when they're edited.)
There was a few points the other raised which I disagreed with and that was one of them. I completely agree with you that shell history should be managed by the shell itself.
I also didn't agree with the points about Console API. I mean sure, he's right that ANSI / VT escape sequences are naff, but they are the standard so we're stuck with them. However as much as I love the idea of a Console API, the fact that they only work on local host is just inexcusable. And I don't say this because "hindsight is 20/20", there was already decades of proven example that remote consoles are worth having before the console API was even written. Why they couldn't have created is a network API (ala rsh) is beyond me. But we are where we are.
Some of the examples given about OOP was just plain wrong too. You can't bunch 20 years of object oriented langaues together and say "they all quickly followed". 20 years is not quick; not in real terms and most definitely not in IT terms.
What surprised me the most when reading that article is that NT was originally command line driven with a GUI added for release. It's amazing just how bad the console sucks even without taking the evolution of NT into account; and now that I know NT was originally command line oriented, well I'm just shocked.
If there was anything good that can be taken from the article, it's that it sounds like they are working on better terminal / shell separation which will enable developers to write better terminal emulators and better alternative shells. Plus potentially allow for a networked shell. My next request after that would be to write a unified way of splitting ARGS because their current method of passing all command line parameters as a single string is just terrible (yes, I get that's DOS legacy and impossible to change due to backwards compatibility, but isn't it about time Windows had a standard API for splitting that ARGS string so, going forward, programs can be written to split parameters in a consistent way meaning command line users know exactly when they can and cannot use quotation marks, spaces and escaped characters, etc.
I also didn't agree with the points about Console API. I mean sure, he's right that ANSI / VT escape sequences are naff, but they are the standard so we're stuck with them. However as much as I love the idea of a Console API, the fact that they only work on local host is just inexcusable. And I don't say this because "hindsight is 20/20", there was already decades of proven example that remote consoles are worth having before the console API was even written. Why they couldn't have created is a network API (ala rsh) is beyond me. But we are where we are.
Some of the examples given about OOP was just plain wrong too. You can't bunch 20 years of object oriented langaues together and say "they all quickly followed". 20 years is not quick; not in real terms and most definitely not in IT terms.
What surprised me the most when reading that article is that NT was originally command line driven with a GUI added for release. It's amazing just how bad the console sucks even without taking the evolution of NT into account; and now that I know NT was originally command line oriented, well I'm just shocked.
If there was anything good that can be taken from the article, it's that it sounds like they are working on better terminal / shell separation which will enable developers to write better terminal emulators and better alternative shells. Plus potentially allow for a networked shell. My next request after that would be to write a unified way of splitting ARGS because their current method of passing all command line parameters as a single string is just terrible (yes, I get that's DOS legacy and impossible to change due to backwards compatibility, but isn't it about time Windows had a standard API for splitting that ARGS string so, going forward, programs can be written to split parameters in a consistent way meaning command line users know exactly when they can and cannot use quotation marks, spaces and escaped characters, etc.
Hear hear!
Terminal escapes... you know what, they may seem ridiculous, but they work with a read/write API instead of an ioctl API, and that makes all the difference. And they work with serial ports and terminals. From day 1 terminals were read/write-oriented, not ioctl-oriented, and the concept of escapes originates with the terminal vendors, not with Unix.
Regarding command-line parsing, there are ways to move to a Unix-style argument array in a way that is backwards-compatible. It could just be an attribute of the executable to exec(), that it wants a proper argument vector. Shell escaping in Windows is just not-sane.
Terminal escapes... you know what, they may seem ridiculous, but they work with a read/write API instead of an ioctl API, and that makes all the difference. And they work with serial ports and terminals. From day 1 terminals were read/write-oriented, not ioctl-oriented, and the concept of escapes originates with the terminal vendors, not with Unix.
Regarding command-line parsing, there are ways to move to a Unix-style argument array in a way that is backwards-compatible. It could just be an attribute of the executable to exec(), that it wants a proper argument vector. Shell escaping in Windows is just not-sane.
Hey Laumars - Console PM and author of the post here:
Fair points in part, though …
Remember that things like Remote Desktop obviated the pressing need for command-line --> remote command-line access for many years. RDP quickly evolved into a very efficient way of remoting the entire desktop experience, not just Command-Line - something that was particularly necessary until PowerShell started to mature due to Windows' heavy GUI tool influence (for better and worse).
Don't despair though - there's a VERY interesting post coming soon on this subject, that I think you'll enjoy! ;)
I summarized 20 years of history: Simula arrived in '68, Smalltalk in '72 and then, other than research efforts, relatively little until CFront/C++ around '85. After that there was a new variant of C++ or new object oriented language almost every 8-12 months ever since - ObjectBASIC, Modula-2, ObjectPascal, Delphi, Java, Python, C#, Ruby, etc. It was practically a language explosion.
And, of course NT started as a command-line OS. All new OS' start that way it's the simplest UX to get running. The Windows GUI wasn't slapped on at the end though - it arrived relatively quickly since Microsoft was able to leverage much of the experience of having build Windows 3.x/9x etc. previously.
Command-line args are not all passed as a single string. In Windows, args are separated by space. If you use C/C++ and others, you get argv and argc, or in C# you get an array of space separated values.
Alas, when NT came along it was seen as EXTREMELY important to make it easy to run/port MS-DOS scripts and tools to encourage migration and adoption. By this time, so many tools used so many ways of specifying args and values … / vs. \ vs. - vs. none, /o=foo, /o foo, etc. … that it was practically impossible to both support backward compat while rationalizing usage.
PowerShell, though, has done much to make args MUCH more consistent, self-documenting, etc.
This said, yes, it'd be AWESOME if args could be rationalized and handled in a more consistent manner. Had a fascinating discussion about just this the other day. Stay tuned to our blog ;)
Fair points in part, though …
Remember that things like Remote Desktop obviated the pressing need for command-line --> remote command-line access for many years. RDP quickly evolved into a very efficient way of remoting the entire desktop experience, not just Command-Line - something that was particularly necessary until PowerShell started to mature due to Windows' heavy GUI tool influence (for better and worse).
Don't despair though - there's a VERY interesting post coming soon on this subject, that I think you'll enjoy! ;)
I summarized 20 years of history: Simula arrived in '68, Smalltalk in '72 and then, other than research efforts, relatively little until CFront/C++ around '85. After that there was a new variant of C++ or new object oriented language almost every 8-12 months ever since - ObjectBASIC, Modula-2, ObjectPascal, Delphi, Java, Python, C#, Ruby, etc. It was practically a language explosion.
And, of course NT started as a command-line OS. All new OS' start that way it's the simplest UX to get running. The Windows GUI wasn't slapped on at the end though - it arrived relatively quickly since Microsoft was able to leverage much of the experience of having build Windows 3.x/9x etc. previously.
Command-line args are not all passed as a single string. In Windows, args are separated by space. If you use C/C++ and others, you get argv and argc, or in C# you get an array of space separated values.
Alas, when NT came along it was seen as EXTREMELY important to make it easy to run/port MS-DOS scripts and tools to encourage migration and adoption. By this time, so many tools used so many ways of specifying args and values … / vs. \ vs. - vs. none, /o=foo, /o foo, etc. … that it was practically impossible to both support backward compat while rationalizing usage.
PowerShell, though, has done much to make args MUCH more consistent, self-documenting, etc.
This said, yes, it'd be AWESOME if args could be rationalized and handled in a more consistent manner. Had a fascinating discussion about just this the other day. Stay tuned to our blog ;)
Hi, thank you for taking the time to respond.
Re the command line arguments being a single string, this is what I'm referring to:
> For better or for worse1, Windows knows about only one command line string for each process. Because one string is not terribly useful, libraries conspire to provide the illusion of multiple command line arguments: before creating a subprocess, a program combines all argument strings into one command line string, and the newly-born subprocess, before calling main, splits this string into arguments and passes the arguments as argv. In principle, each program can parse the command line string differently, but most use the convetion that CommandLineToArgvW and the Microsoft C library understand. This convention is a good one because it provides a way to encode any command line argument as part of a command line string without losing information.
> The problem is that there is no ArgvToCommandLineW. How do we construct an argument string understood by CommandLineToArgvW?
Source https://blogs.msdn.microsoft.com/twistylittlepassagesallalik...
Having one command line string is passable if you only handle ASCII characters and consider whitespace a delimiter (as was the case in the days of DOS). But the moment you start needing to pass more complex data (as you often need to when you start writing shell scripts) then you quickly run into pain points.
Another drawback of a single string is you then limit the usefulness of writing alternative languages which are heavily exec orientated (shell languages). This is a particular pain point I've experienced with my own custom shell because I apply escaping rules to quotes and allow for other methods of quotations (such as proper support for nested quotes). However since Linux / UNIX treat all parameters as an array at all points in the stack it means I can consistently parse my own languages syntax and reliably pass that to the program I'm wishing to call. It means I can drop a variable as a parameter without having to manually escape / quote it for fear of whitespaces breaking the syntax (ie using variables like you would in "normal" language). But that simply does not translate well to Windows.
And finally there is also the painpoint that not all Windows CLI tools read from ARGV. Some don't even decode the single string parameter correctly. Theres better articles demonstrating this point so I won't waste more page space on this issue but suffice to say its a bit of a mess.
Re OOP explosion: I get the point you're making but all language paradigms have experienced a similar explosion in That time frame. Be it functional, logical, object oriented, etc. I get the need to emphasize the logic of Windows as an object oriented OS (a point I don't disagree with myself) but I just feel your example was a little overreacting - to the extent that you started undermining the crux of the point you were attempting to make.
Much like how your points about UNIX "everything is a file" was somewhat mislead. That didn't really become a thing until much later in UNIX's history (Plan 9 - UNIXs successor - really pioneered that concept and many ideas were then backported. Eg The /proc example you used isnt even available on UNIX as it's Linux specific. Plus your example was really more a reporting tool than a demonstration of file system objects. Theres better examples of your point in /proc such as the PIDs and their runtime parameters, and kernel setting that can be read and written to as a filesystem objects).
Re GUI Vs console. My point was really more about how if Microsoft were dependant on the console anyway to have made it their first GUI application then it's a great pity they did such a bodge job of it. I get that RDP was a necessity anyway - and it's fair to say the performance of RDP is really quite impressive - but back in the 90s I seem to recall most Windows shops still used to just throw a physical keyboard and mouse into their racks (usually via KVM) rather than deal with RDP. Where as "Unix" (BSD, Solaris, whatever) would be wired up via serial on the machines console port for remote access. So for the best will in the world, remote access still wasn't a popular choice on NT until it's relatively recent history where as it was the main way of interacting with UNIX-like systems from the get go. And that is my problem with how NT was designed. I can take or leave the whole GUI Vs command line debate - that's purely personal opinion. My issue was until network speeds etc all really caught up, Windows made it painful to work remotely. To an extent it still does as you have to wait for the damned RDP service to come up after a reboot (which would take half an hour after the reboot had finished on one Windows domain controller I used to manage) where as on Solaris / BSD / Linux / etc I can stream it's boot process from the moment the boot menu loads (in fact I've even installed Linux remotely via serial). Obviously we all now have OOB management tools like ilo or their respective cloud management tools so the shortcomings of the RDP service are somewhat mitigated there these days but how many years of NTs history has it taken us to get to that point where a _server_ no longer needs a physical monitor, keyboard and mouse wired up to it?
All in all it was an interesting read, even if I didn't agree with some of the specific points you were making. But then life would be dull if we all agreed on everything all of the time. :)
Re the command line arguments being a single string, this is what I'm referring to:
> For better or for worse1, Windows knows about only one command line string for each process. Because one string is not terribly useful, libraries conspire to provide the illusion of multiple command line arguments: before creating a subprocess, a program combines all argument strings into one command line string, and the newly-born subprocess, before calling main, splits this string into arguments and passes the arguments as argv. In principle, each program can parse the command line string differently, but most use the convetion that CommandLineToArgvW and the Microsoft C library understand. This convention is a good one because it provides a way to encode any command line argument as part of a command line string without losing information.
> The problem is that there is no ArgvToCommandLineW. How do we construct an argument string understood by CommandLineToArgvW?
Source https://blogs.msdn.microsoft.com/twistylittlepassagesallalik...
Having one command line string is passable if you only handle ASCII characters and consider whitespace a delimiter (as was the case in the days of DOS). But the moment you start needing to pass more complex data (as you often need to when you start writing shell scripts) then you quickly run into pain points.
Another drawback of a single string is you then limit the usefulness of writing alternative languages which are heavily exec orientated (shell languages). This is a particular pain point I've experienced with my own custom shell because I apply escaping rules to quotes and allow for other methods of quotations (such as proper support for nested quotes). However since Linux / UNIX treat all parameters as an array at all points in the stack it means I can consistently parse my own languages syntax and reliably pass that to the program I'm wishing to call. It means I can drop a variable as a parameter without having to manually escape / quote it for fear of whitespaces breaking the syntax (ie using variables like you would in "normal" language). But that simply does not translate well to Windows.
And finally there is also the painpoint that not all Windows CLI tools read from ARGV. Some don't even decode the single string parameter correctly. Theres better articles demonstrating this point so I won't waste more page space on this issue but suffice to say its a bit of a mess.
Re OOP explosion: I get the point you're making but all language paradigms have experienced a similar explosion in That time frame. Be it functional, logical, object oriented, etc. I get the need to emphasize the logic of Windows as an object oriented OS (a point I don't disagree with myself) but I just feel your example was a little overreacting - to the extent that you started undermining the crux of the point you were attempting to make.
Much like how your points about UNIX "everything is a file" was somewhat mislead. That didn't really become a thing until much later in UNIX's history (Plan 9 - UNIXs successor - really pioneered that concept and many ideas were then backported. Eg The /proc example you used isnt even available on UNIX as it's Linux specific. Plus your example was really more a reporting tool than a demonstration of file system objects. Theres better examples of your point in /proc such as the PIDs and their runtime parameters, and kernel setting that can be read and written to as a filesystem objects).
Re GUI Vs console. My point was really more about how if Microsoft were dependant on the console anyway to have made it their first GUI application then it's a great pity they did such a bodge job of it. I get that RDP was a necessity anyway - and it's fair to say the performance of RDP is really quite impressive - but back in the 90s I seem to recall most Windows shops still used to just throw a physical keyboard and mouse into their racks (usually via KVM) rather than deal with RDP. Where as "Unix" (BSD, Solaris, whatever) would be wired up via serial on the machines console port for remote access. So for the best will in the world, remote access still wasn't a popular choice on NT until it's relatively recent history where as it was the main way of interacting with UNIX-like systems from the get go. And that is my problem with how NT was designed. I can take or leave the whole GUI Vs command line debate - that's purely personal opinion. My issue was until network speeds etc all really caught up, Windows made it painful to work remotely. To an extent it still does as you have to wait for the damned RDP service to come up after a reboot (which would take half an hour after the reboot had finished on one Windows domain controller I used to manage) where as on Solaris / BSD / Linux / etc I can stream it's boot process from the moment the boot menu loads (in fact I've even installed Linux remotely via serial). Obviously we all now have OOB management tools like ilo or their respective cloud management tools so the shortcomings of the RDP service are somewhat mitigated there these days but how many years of NTs history has it taken us to get to that point where a _server_ no longer needs a physical monitor, keyboard and mouse wired up to it?
All in all it was an interesting read, even if I didn't agree with some of the specific points you were making. But then life would be dull if we all agreed on everything all of the time. :)
Hey Oliver - Console PM and author of the above post here.
Glad you learned lots - makes writing it worthwhile ;)
I didn't mean to imply that command history is not a productivity enhancement - it absolutely IS!
What I was saying was that in the absence of a system/terminal-provided command history mechanism, every shell has to implement its own. Cmd needs it. PowerShell needs it. Bash needs it. Zsh … fish … yaddayaddayadda need command-history.
So if every shell (and many apps) need a command history buffer, why not provide command-history as a service from the terminal. There are MANY amazing and valuable things one could do if one could consistently log/store/serialize command-history for later replay, analysis, etc.
I agree 1000% that Windows' command history is FAR from good, but I think there are some pretty awesome things we could do to make it so.
Bear with us on this ;)
Glad you learned lots - makes writing it worthwhile ;)
I didn't mean to imply that command history is not a productivity enhancement - it absolutely IS!
What I was saying was that in the absence of a system/terminal-provided command history mechanism, every shell has to implement its own. Cmd needs it. PowerShell needs it. Bash needs it. Zsh … fish … yaddayaddayadda need command-history.
So if every shell (and many apps) need a command history buffer, why not provide command-history as a service from the terminal. There are MANY amazing and valuable things one could do if one could consistently log/store/serialize command-history for later replay, analysis, etc.
I agree 1000% that Windows' command history is FAR from good, but I think there are some pretty awesome things we could do to make it so.
Bear with us on this ;)
I really don't understand why I would want the terminal to be aware of command-line history. That seems completely wrong. On Unix one can have a terminal used by a non-shell application -- what would a terminal's command-line history mean in that case?
I love reading about the work that's being put into old apps like Console and Notepad. Keep it up!
This a very candid and informative look at the Windows console and it comes from Microsoft! I'm impressed. Congrats to the writer and thanks for posting!
This is of a piece with Microsoft's GitHub acquisition -- seems to be part of a program to win developer mindshare. And it's working; I was impressed by this post, both tone and technical content. Windows having never really been suitable for the server, and rapidly losing its grip on the home user, it seems totally sensible to push the "windows is a good platform for people doing serious work" angle. It's all Windows has left.
Hi. Windows Console PM and Author of the post here :)
Thanks for your kind words. Glad you liked it - check our blog often - LOTS more posts coming on this subject!
Thanks for your kind words. Glad you liked it - check our blog often - LOTS more posts coming on this subject!
Oops! That page can’t be found.
It looks like nothing was found at this location. Maybe try a search?
Is this just me? Late to the party?
In case this isn't temporary: https://web.archive.org/web/20180717165103/https://blogs.msd...
Is this just me? Late to the party?
In case this isn't temporary: https://web.archive.org/web/20180717165103/https://blogs.msd...
LOL - nothing nefarious - made a few corrections and improvements to the post - aaaaand managed to bork the publishing process which took a few mins to re-generate and refresh the cache!
Ugh!
Should be back up and available now!
Ugh!
Should be back up and available now!
I'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 :)
I want to work with more people like Rich! Whatever they may lack in English convention, they more than make up for it in enthusiasm!
lol Rich is straight outta Britain English - his English is the most English of any of ours :P
edit: Now that I say that, I guess he is Welsh so maybe his english isn't the best... :P
edit: Now that I say that, I guess he is Welsh so maybe his english isn't the best... :P
I'd swear at you in Welsh but I fear I may wear-out my 'l', 'e', and 'u' keys ;)
Thanks all - appreciate that some of my enthusiasm came through, though the previous poster had a point about the sheer density of my excitement so I toned it down a little while making a few corrections, clarifications, and improvements in the update I posted this afternoon.
Keep the feedback coming though - you'll also find me on Twitter a lot more than in here: https://twitter.com/richturn_ms
Thanks all - appreciate that some of my enthusiasm came through, though the previous poster had a point about the sheer density of my excitement so I toned it down a little while making a few corrections, clarifications, and improvements in the update I posted this afternoon.
Keep the feedback coming though - you'll also find me on Twitter a lot more than in here: https://twitter.com/richturn_ms
Thank you, love the series. Nothing wrong with the writing style.
Keep up the good work, it is great to see the console getting gradual improvements!
Keep up the good work, it is great to see the console getting gradual improvements!
Yes, it's surprisingly interruptive. I kept going back rereading a sentence, wondering about what makes it so special.
Found the article content quite interesting but the tone of the writing (emojis and exclamation marks everywhere) really put me off. Sounded forced and added nothing.
Fair comment - I agree and so removed a bunch of !'s and emoji for you, though I did leave a few in to convey some of my (and the team's) excitement - we're genuinely buzzed to be able to massively improve the Console.
Hope you find the latest updated version more palatable.
Hope you find the latest updated version more palatable.
It reminded me of a very excited Steve Ballmer: https://www.youtube.com/watch?v=HMhrRovP9qA
I'm late to the party, but maybe the console guys are still lurking. If so, than first and foremost I wanted to thank you for the amazing walk you guys took the console so far.
That said, as someone who uses your product for hours on daily basis, I have two pain points that I would love to have fixed, if that possible at all:
1. selection of text and deletion - works in PowerShell, doesn't work in cmd. Is this curable?
2. Customizing the console is pain. I don't mind doing it once but it is impossible to save theme and copy it between computers. It is also impossible to export registry keys - not only do they differ for various consoles, the color settings are not saved there. The only way I found so far for achieving this is copying the shortcut for the specific console - the colors are saved to the .lnk file in binary form. Seriously, can we have at least color exportable themes in a format that can be edited with a text editor?
That said, as someone who uses your product for hours on daily basis, I have two pain points that I would love to have fixed, if that possible at all:
1. selection of text and deletion - works in PowerShell, doesn't work in cmd. Is this curable?
2. Customizing the console is pain. I don't mind doing it once but it is impossible to save theme and copy it between computers. It is also impossible to export registry keys - not only do they differ for various consoles, the color settings are not saved there. The only way I found so far for achieving this is copying the shortcut for the specific console - the colors are saved to the .lnk file in binary form. Seriously, can we have at least color exportable themes in a format that can be edited with a text editor?
I think rich (@bitcrazed) already talked a bit about #1, so I'll share a bit on #2.
I agree, the current properties story is INSANE. I don't get how whoever wrote it even came up with it - it's likely a frankencode system that we're stuck supporting for now. I can't tell you how many times I've had to explain how the console settings work, and how your settings can be different depending on how you launch the console. It's been a pain point I've had a particular eye on since I started here.
It's a powerful system that is very prone to "you moved my cheese" syndrome - It's REALLY hard to change it into a sane system without breaking someone's workflow.
That being said, I have a bone to pick with that system, and I think I might have some spare cycles to finally get to it soon :)
PS: While we're on the subject of colors, lemme quick throw out (Colortool)[https://github.com/Microsoft/console/tree/master/tools/Color...]. It can be really helpful for quickly changing the color scheme of the console. It's not great for everything, but I've found it super helpful.
I agree, the current properties story is INSANE. I don't get how whoever wrote it even came up with it - it's likely a frankencode system that we're stuck supporting for now. I can't tell you how many times I've had to explain how the console settings work, and how your settings can be different depending on how you launch the console. It's been a pain point I've had a particular eye on since I started here.
It's a powerful system that is very prone to "you moved my cheese" syndrome - It's REALLY hard to change it into a sane system without breaking someone's workflow.
That being said, I have a bone to pick with that system, and I think I might have some spare cycles to finally get to it soon :)
PS: While we're on the subject of colors, lemme quick throw out (Colortool)[https://github.com/Microsoft/console/tree/master/tools/Color...]. It can be really helpful for quickly changing the color scheme of the console. It's not great for everything, but I've found it super helpful.
That's look promising. Thank you very much!
Hey @zaat. Thanks for your kind words :D
Alas, deleting text is an operation controlled via the shell. PowerShell's (awesome) PSReadLine does it for PowerShell, but introducing that kind of behavioral change is unlikely to be possible in Cmd because, as pointed out in the posts, Cmd is in maintenance mode, is extremely fragile, and it's key MO is backward compat, which includes behaviors because many tools, and scripts depend on behaviors (even broken ones) as "Features" ;)
Alas, deleting text is an operation controlled via the shell. PowerShell's (awesome) PSReadLine does it for PowerShell, but introducing that kind of behavioral change is unlikely to be possible in Cmd because, as pointed out in the posts, Cmd is in maintenance mode, is extremely fragile, and it's key MO is backward compat, which includes behaviors because many tools, and scripts depend on behaviors (even broken ones) as "Features" ;)
Thank you for answering. Any chances on number 2, especially color themes?
There are ways to get much better terminal experience for typical web dev https://blog.ropnop.com/configuring-a-pretty-and-usable-term... (also works for tilix)
Hopefully, support for bidirectional text will be added soon. Microsoft needs to lead the way of handling it in console programs. Even in UNIX systems, only a few terminal emulators support bidirectional text properly.
Could you go submit this to our UserVoice?
https://wpdev.uservoice.com/forums/266908-command-prompt-con...
I'd say that bi-directional text is a pretty low priority at the moment. We just haven't really heard any asks for it, and like you said it's poorly supported on other platforms (if at all).
https://wpdev.uservoice.com/forums/266908-command-prompt-con...
I'd say that bi-directional text is a pretty low priority at the moment. We just haven't really heard any asks for it, and like you said it's poorly supported on other platforms (if at all).
I love Cmder, it's superior to cmd.exe in all possible ways, but from time to time it just stops working. Now I understand better why.
I haven't done any Windows dev since last year, but I've often wondered why more .NET devs don't use Cmder. I've always been a fan of a full-screen console with split panes (tmux style), and other developers have looked at me like I'm some sort of wizard, despite using fairly basic tech.
Sure, it takes a little while to get used to Powershell, but once you get over the hump it's really useful knowledge to have, especially if you have anything to do with devops or deployments.
Sure, it takes a little while to get used to Powershell, but once you get over the hump it's really useful knowledge to have, especially if you have anything to do with devops or deployments.
cmd is the shell, Cmder (which is just a wrapper around ConEmu) is the console/terminal. Both have little to do with each other, apart from that one needs the other to show a window.
G'ah - PLEASE read the posts about which you're commenting - Cmder is a terminal/Console, not a shell.
Cmd.exe is a (headless) command-line shell.
A shell accepts input from a terminal/Console and emits text to its connected terminal/Console to be displayed back to the user.
All this is covered in some detail in the posts thus far.
Cmd.exe is a (headless) command-line shell.
A shell accepts input from a terminal/Console and emits text to its connected terminal/Console to be displayed back to the user.
All this is covered in some detail in the posts thus far.
That's quite clear, I have no idea why people assume I confuse the two. I just said the article helped me to understand why Cmder has certain problems.
So, MS has finally realized they're 40 years behind the civilized world. I'm curious to see how long it will take them to catch up.
So, MS has finally realized they're 40 years behind the civilized world
Yes they should be emulating a teletype like enlightened folk!
Yes they should be emulating a teletype like enlightened folk!
Very appropriate comment. Last year I was tinkering with the implementation of a TUI (Text User Interface), and I wanted it to be cross-platform. I started developing it under Windows, using the Console API (sorely lacking in features, but at least it is just an API to be called from C). I had to abandon the project once I realized that it would have been too hard to harmonize this approach with the weird way you are supposed to program a Unix console.
Let's consider the difference between calling an hypotetical system API to change the text color and a raw sequence of bytes encoding. In Unix, to set the color to be used for writing characters you have to send an ESC character, some more bytes, and then an ASCII representation of the R, G, and B components (assuming your virtual terminal supports this), separated by a colon/semicolon. The terminal will then read this sequence, parse the three numbers and move the character. This approach is not precisely efficient, especially if you consider that today it is not unlikely to have full-screen terminal applications with a large resolution. For a 200x60 terminal like the one I am using right now, to color every character with a different color requires sending 500 Kb of data, compared to the 36 Kb required by a 3-byte representation of each RGB tuples.
And if you are trying to read from a terminal, every time you receive an ESC key, you are always in doubt whether the user pressed ESC, or if it is the start of an ANSI sequence. The usual trick here is to check if there is a character already available immediately after you detect an ESC byte coming from standard input: if there is, you can assume it's the beginning of a sequence.
Admittedly the virtual-terminal approach makes remote connections (through SSH) simpler than an API (you just have to send a bunch of bytes through a socket), but I wonder why in 2018 we are still relying on the old and quirky mechanism of "virtual consoles" when real consoles have long disappeared.
Edit: small fixes.
Let's consider the difference between calling an hypotetical system API to change the text color and a raw sequence of bytes encoding. In Unix, to set the color to be used for writing characters you have to send an ESC character, some more bytes, and then an ASCII representation of the R, G, and B components (assuming your virtual terminal supports this), separated by a colon/semicolon. The terminal will then read this sequence, parse the three numbers and move the character. This approach is not precisely efficient, especially if you consider that today it is not unlikely to have full-screen terminal applications with a large resolution. For a 200x60 terminal like the one I am using right now, to color every character with a different color requires sending 500 Kb of data, compared to the 36 Kb required by a 3-byte representation of each RGB tuples.
And if you are trying to read from a terminal, every time you receive an ESC key, you are always in doubt whether the user pressed ESC, or if it is the start of an ANSI sequence. The usual trick here is to check if there is a character already available immediately after you detect an ESC byte coming from standard input: if there is, you can assume it's the beginning of a sequence.
Admittedly the virtual-terminal approach makes remote connections (through SSH) simpler than an API (you just have to send a bunch of bytes through a socket), but I wonder why in 2018 we are still relying on the old and quirky mechanism of "virtual consoles" when real consoles have long disappeared.
Edit: small fixes.
SSH connections are nearly the most common interface. At the very least, optimizing for them is a good idea.
More specifically, a TeleType Model 37 from 1967. None of this modern ECMA-48 stuff from 1976. (-:
* https://news.ycombinator.com/item?id=17557575
* https://news.ycombinator.com/item?id=15779194
* https://news.ycombinator.com/item?id=17557575
* https://news.ycombinator.com/item?id=15779194
You mean you don't actually print your output?!? Heathen!
Not sure what you mean... PowerShell Console is one of the most modern and advanced consoles there is and it's from Microsoft (compared to old non object oriented and pipelined stuff like cmd here in the article) - but it's still good to see that they haven't forgotten about the good old cmd.exe :)
You're mistaking the shell for the console. As the article quite clearly points out, there's a vast difference between both, even though when you look at a console application (such as a shell) you kind of always see both.
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?
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.
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.
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. I don't think throwing more people at it would really help too much.
My hat is off to you and your team for finally fixing this.
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. I don't think throwing more people at it would really help too much.
My hat is off to you and your team for finally fixing this.
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.
After a LOT of refactoring it's finally in a state that's really quite managable, and much more modernized.
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 :).
That part comes next ;) Getting all of the rendering calls isolated to one component was a pretty big task in itself, and just isolating and de-duplicating them improved our rendering perf by something like 30%
Your efforts are noticeable and appreciated! It was always a mystery to me why the Windows console was stuck in time from the NT days, and your work sends a signal to all those doing sysadmin and programming work that Microsoft is supporting these use cases in Windows.
Ouch. This sounds terrible. I can see how refactoring a bowl of spaghetti like that took a lot of time. I respect you for sticking with it and not throwing in the towel.
Refactoring spaghetti would have been a breeze compared to the Console.
What stands as a HUGE testament to the Console team's effort, however, is the fact that, while re-engineering what was truly a nightmare code-base, apart from a few newly-introduced bugs (most of which were caught before release), the rapidly improving Console didn't break any any existing command-line apps or users' workflows.
The engineering team deserve a medal for pulling this off, quite frankly!
What stands as a HUGE testament to the Console team's effort, however, is the fact that, while re-engineering what was truly a nightmare code-base, apart from a few newly-introduced bugs (most of which were caught before release), the rapidly improving Console didn't break any any existing command-line apps or users' workflows.
The engineering team deserve a medal for pulling this off, quite frankly!
Thank you for explaining! Please don't take my initial post as criticism of your work. There is just this visible disconnect between approximately 4 years of work and comparatively simple features that have been shown off so far. So there must be a story there.
I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass?
Also,I am curious about one other thing: the Windows Console is notorious for having extremely bad perfomance when displaying lots of text. Last time I checked I could only get around 100 lines of text per second on Windows while Linux terminal emulations can show more than 10 times that amount. This may seem petty, but some programs are slowed down by this in practice. Can we expect improvements in that area as well?
I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass?
Also,I am curious about one other thing: the Windows Console is notorious for having extremely bad perfomance when displaying lots of text. Last time I checked I could only get around 100 lines of text per second on Windows while Linux terminal emulations can show more than 10 times that amount. This may seem petty, but some programs are slowed down by this in practice. Can we expect improvements in that area as well?
Oh I certainly don't take it as such. It can be extra frustrating as both a developer and a user of the console to want to be able to improve everything, but know that there is only so much time to get features done, and rarely do usability features rise in priority above supporting other teams.
> I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass?
It's not really something most developers outside the company would have even been aware of honestly. At different points in time, there have been various different teams across Microsoft who had been working on bringing up new pieces of hardware (Xbox, HoloLens, phones, etc) and they found that the existing console didn't work on those minimal Windows OS's. At the time, there was no Console team at all, so whoever was working on that device just implemented their own console that would work on that prototypical device. That prototypical console got re-used and extended for other devices as they were developed, then abandoned as the platforms matured.
Then, in 2014, when the Console team was formed, we found out that not only were we responsible for the desktop console, but these other implementations as well.
> Can we expect improvements in that area as well?
Stay tuned :)
> I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass?
It's not really something most developers outside the company would have even been aware of honestly. At different points in time, there have been various different teams across Microsoft who had been working on bringing up new pieces of hardware (Xbox, HoloLens, phones, etc) and they found that the existing console didn't work on those minimal Windows OS's. At the time, there was no Console team at all, so whoever was working on that device just implemented their own console that would work on that prototypical device. That prototypical console got re-used and extended for other devices as they were developed, then abandoned as the platforms matured.
Then, in 2014, when the Console team was formed, we found out that not only were we responsible for the desktop console, but these other implementations as well.
> Can we expect improvements in that area as well?
Stay tuned :)
As I understand it Windows 3 ran in DOS, Windows 98 had DOS integrated, Windows NT had it emulated and ME was somewhere in between. It wouldn't surprise me if parts from all four have survived til today for compatibility.
ME wasn't between the least. It was DOS based. There is no inbetween. It's either IO.SYS or NTOSKRNL.EXE. It made using the real mode MS DOS even worse by shipping a special MS DOS which skipped CONFIG.SYS and AUTOEXEC.BAT, hidden the files and removed DOS from the boot menu. To fix this, check http://retrosystemsrevival.blogspot.com/2018/06/dos-for-wind... this -- quite new blog post, just last month, for something this old.
Actually, no - Windows ME did not depend on MS-DOS.
For all the bad rap it got (some of which was deserved), ME bypassed real-mode MS-DOS (and its config files) at bootup, and loaded its own protected-mode drivers, etc. in IO.SYS. It also loaded the main registry hive only once, and parallelized PnP resolution, significantly improving boot-up time. It also incorporated Windows 2000's networking stack, and added support for UPnP.
In many ways, ME was a stepping stone, getting some users on less-capable hardware onto Windows 2000 class OS features, without requiring a complete hardware upgrade.
For all the bad rap it got (some of which was deserved), ME bypassed real-mode MS-DOS (and its config files) at bootup, and loaded its own protected-mode drivers, etc. in IO.SYS. It also loaded the main registry hive only once, and parallelized PnP resolution, significantly improving boot-up time. It also incorporated Windows 2000's networking stack, and added support for UPnP.
In many ways, ME was a stepping stone, getting some users on less-capable hardware onto Windows 2000 class OS features, without requiring a complete hardware upgrade.
Erm, nope. IFSMGR.VXD depends on IFSHLP.SYS still.
Everyone's favorite error message: the Microsoft Installable File System Manager cannot find the helper driver. Please ensure that IFSHLP.SYS has been installed.
This means Windows ME needs a real mode DOS helper for certain file system operations.
I can't remember whether the INT 21h function 55h (Create PSP) was still called as frequently as in earlier Windows and handled in DOS but I betcha.
Everyone's favorite error message: the Microsoft Installable File System Manager cannot find the helper driver. Please ensure that IFSHLP.SYS has been installed.
This means Windows ME needs a real mode DOS helper for certain file system operations.
I can't remember whether the INT 21h function 55h (Create PSP) was still called as frequently as in earlier Windows and handled in DOS but I betcha.
IFSHLP.SYS was originally created during the implementation of OS/2 1.2, and later released in Windows 3.11 running on 32-bit 386 Enhanced Mode.
Its job was to provide 32-bit file access (bypassing 16-bit DOS file IO mechanisms), and ensuring nothing else on the system could intercept INT 21h calls.
ME didn't depend on MS-DOS (though it did provide support for running MS-DOS apps).
Its job was to provide 32-bit file access (bypassing 16-bit DOS file IO mechanisms), and ensuring nothing else on the system could intercept INT 21h calls.
ME didn't depend on MS-DOS (though it did provide support for running MS-DOS apps).
The 9x series and ME use DOS during the boot process but not once booted, except for legacy disk access (if there's no 32-bit Win9x disk driver). Microsoft went to huge pains to make Win9x act as if it was an application on top of DOS for compatibility reasons, but it very much isn't, it's a full-blown OS. This is almost true of Windows 3.x too or Windows/286 and Windows/386.
These should help you and others. They cover some of the errors in the above, as well as the change to the console implementation in Windows NT 6.1.
* https://superuser.com/a/319187/38062
* http://jdebp.info./FGA/a-command-interpreter-is-not-a-consol...
* http://jdebp.info./FGA/tui-console-and-terminal-paradigms.ht...
* https://superuser.com/a/319187/38062
* http://jdebp.info./FGA/a-command-interpreter-is-not-a-consol...
* http://jdebp.info./FGA/tui-console-and-terminal-paradigms.ht...
Linux terminal emulators are by no means uniform about this. Scrolling speed, and whether to not re-render for every character, are points of contention amongst the XTerm, Alacritty, and VTE people.
I just set the scrollback history to zero and run tmux. Scrollback speed problem solved.
Please ignore the parent you replied to. The changes you've put into the console are so fundamentally important - and brilliant. Being able to snap a window and have the code flow properly and fill the window completely is great.
In the same way that the Linux desktop has fast caught up with the Windows desktop, the Windows terminal is fast catching up with the Linux terminal.
The stuff your changing most people will never notice, but you've done more for the console in 3 years than was done in the previous 20 as far as I can tell.
It's getting very close to where I can actually use Vim full time at a DOS prompt - it's actually waiting for Vim to catch up with the 24-bit colour changes that you made [0]. Plus there's the nicety of bold/italic fonts but I'd imagine that might not occur for a while.
[0]: https://github.com/vim/vim/issues/1270
In the same way that the Linux desktop has fast caught up with the Windows desktop, the Windows terminal is fast catching up with the Linux terminal.
The stuff your changing most people will never notice, but you've done more for the console in 3 years than was done in the previous 20 as far as I can tell.
It's getting very close to where I can actually use Vim full time at a DOS prompt - it's actually waiting for Vim to catch up with the 24-bit colour changes that you made [0]. Plus there's the nicety of bold/italic fonts but I'd imagine that might not occur for a while.
[0]: https://github.com/vim/vim/issues/1270
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!
Are you able to speak at all to the labor assignment? Microsoft is big, why only put 3 engineers on this project?
Three is probably a good number, if they are decent engineers. Throwing more people at a problem has diminishing results very, very quickly in software, unless the project can be broken down into mostly independent teams. Even then integrating the work into something coherent can easily be more challenging and time consuming than just having a tiny skilled team own the project soup to nuts.
The number of core developers will scale with how well they can separate concerns / components. Three is probably a good number of core developers for this project, but they could probably use a fourth to do things like write tests and do things like test interoperability/compatibility.
This is bizarre to me.
You simply can not attract developers to your platform without a first rate console experience.
Why even bother with Powershell, Linux Subsystem etc without getting this crucial component working perfectly ?
You simply can not attract developers to your platform without a first rate console experience.
Why even bother with Powershell, Linux Subsystem etc without getting this crucial component working perfectly ?
Windows is the biggest, most popular development platform in the world.
Are you not even slightly aware of the bias and bubble you live in?!
Are you not even slightly aware of the bias and bubble you live in?!
According to https://insights.stackoverflow.com/survey/2018#technology-pl... Windows Desktop or Server takes second place with 35.4% of developers, behind Linux at 48.3%.
Apparently the roles were reversed in 2017, when Windows was a platform for 41% and Linux 32.9%: https://insights.stackoverflow.com/survey/2017#technology-pl...
Of course that could all be biased by the demographic composition of StackOverflow users, but it still seems to indicate that Windows is losing importance.
Apparently the roles were reversed in 2017, when Windows was a platform for 41% and Linux 32.9%: https://insights.stackoverflow.com/survey/2017#technology-pl...
Of course that could all be biased by the demographic composition of StackOverflow users, but it still seems to indicate that Windows is losing importance.
It's probably biased. Your average enterprise or in-house dev is super, super likely to use Windows and he's not the kind of person that will respond to a poll.
Even if you live in a strict Windows world, the console is important. Plenty of sysadmin-type tasks can only be done from the command line, or is at least faster/easier than the alternative (Exchange, VMware, SharePoint, ...). At work, ConEmu is among the first programs I start after logging in.
Which languages? Maybe for desktop app development (but that itself is quite a niche market now). I have yet to see a web developer use Windows. All I see are Macs and the occasional Linux.
Location is everything. Outside of the US Macs aren't as popular and enterprise or in-house web development rarely happens on Macs or God-forbid!* Linux.
* I'm kidding, but talk to your average IT department head about Linux desktops :)
* I'm kidding, but talk to your average IT department head about Linux desktops :)
Have you heard of C#? ASP.NET? A few of those devs use Windows...
Are those still used for new projects?
Yes, why wouldn't they.
With Core they are even used for new projects running on Linux.
But exactly, that's my point. You no longer even need to be on Windows to use C#.
You do if you want to use visual studio, which according to Stackoverflow's survey is the second most popular development environment (less than 1% behind visual studio code)[0]
Not to mention that in the enterprise world Java and .net have an overwhelming market share.
[0] https://insights.stackoverflow.com/survey/2018/#development-...
Not to mention that in the enterprise world Java and .net have an overwhelming market share.
[0] https://insights.stackoverflow.com/survey/2018/#development-...
Technically. But it's not really there yet. Most people writing C# code are still using the 4.5+ full desktop framework on Windows.
Thanks for your work on this... this is going to make a big difference for lots of folks. (Myself included.)
I don't use Windows mostly because the console experience is so bad. I'm sure there are many others like me. Your superiors should realize they have lost generations of developers because of this and dedicate the resources needed to fix it. How they haven't realized this yet, astounds me.
As a matter of interest, have you tried Windows 10's Console?
Use mintty (or wsltty for WSL). It's slow but it's good.
The Windows console really is rubbish, even after all these updates; don't bother with it.
The Windows console really is rubbish, even after all these updates; don't bother with it.
Mintty + tmux. It's how I survive Windows.
Also: https://github.com/mintty/wsltty
Could you fix proper emitting of tab escape codes so completion in REPLs, etc., work properly?
Actually the cmd now is vastly improved over the one in win7. I cannot go back to that after using the latest one. The changes are definitely not underwhelming.
> The Windows Console code-base is currently (July 2018) almost 30 years old ... older, in fact, than the developers who now work on it!
Which really shows, especially since you still can't use a TTF-font without editing the registry.
Which really shows, especially since you still can't use a TTF-font without editing the registry.
That's just flat out wrong:
https://i.imgur.com/ae1yyXI.png
We added support for TTF fonts a few releases ago.
We added support for TTF fonts a few releases ago.
...and by "few releases ago", you mean Windows 2000?
http://unixwiz.net/images/console-setup3.gif
(Personally, I don't care for TTF since I prefer the contrast and sharpness of a good pixel font, like this one: http://www.hassings.dk/lars/fonts.html )
http://unixwiz.net/images/console-setup3.gif
(Personally, I don't care for TTF since I prefer the contrast and sharpness of a good pixel font, like this one: http://www.hassings.dk/lars/fonts.html )
I think there were two steps. Yes, TrueType fonts have been available for quite a while, but the list was fixed and you had to edit the registry to add other fonts. The current state seems to be that monospaced fonts installed are automatically picked up by that list, so no registry editing necessary anymore.
All I know is that the last time I installed Windows 10, I still had to edit the registry for it to find DejaVu Sans Mono.
If that has changed recently, that's fantastic!
If that has changed recently, that's fantastic!
Console now enumerates and allows selection of monospace TTF fonts.
Alas, as one of our dev's says often "Fonts are just files containing collections of lies"!
Some fonts claim to only contain monospace, glyphs, but don't and include non-monospace or irregularly sized chars. Others just lie completely.
But if you have well-formed TTF fonts, that express correct metdata, and ARE monospace, then they should be selectable.
Alas, as one of our dev's says often "Fonts are just files containing collections of lies"!
Some fonts claim to only contain monospace, glyphs, but don't and include non-monospace or irregularly sized chars. Others just lie completely.
But if you have well-formed TTF fonts, that express correct metdata, and ARE monospace, then they should be selectable.
Having buggy fonts is no reason to hide fonts from the user.
Wow, so that's fixed after almost 30 years! Flat out amazing, what a team!
...so if they don't fix it, the console sucks. But if they do fix it you still find the need to be snarky?
I think the concept is that if they had added it a long time ago, is that would be good or average. Adding it very late is not worthy of praise, and lacking it for years is still worthy of condemnation. While the change may be part of a broader positive trend, it does not absolve them of the past.
Why not, though? Is it really that useful to fill every Microsoft-related topic with comments that amount to "Micro$oft lol"-level trolling?
I mean, they used to suck, we get it. They're actively trying to improve but that, too, is not enough.
I mean, they used to suck, we get it. They're actively trying to improve but that, too, is not enough.
- "You used to be fat!"
- "I'm thin now, though, through hard work. Isn't that worth something?"
- "...but you used to be fat!"The company has an almost 40 year history. When you’ve built up and miss trust over decades, peoples attitudes are not going to change overnight.
Personally, while I was merely describing what I perceived other people’s viewpoints to be, I don’t know why it’s so hard for Microsoft to make a normal terminal app. People have the choice of a dozen adequate terminal apps on Linux. I guess this article explains any difficulty.
As far as MS modernizing, one could look at it as, what would you think if 25 or 30 years ago, IBM said that they were turning around and we’re now a modern, agile company instead of a slow-moving relic of the previous era, and they built an awesome new console app for OS/2?
Personally, while I was merely describing what I perceived other people’s viewpoints to be, I don’t know why it’s so hard for Microsoft to make a normal terminal app. People have the choice of a dozen adequate terminal apps on Linux. I guess this article explains any difficulty.
As far as MS modernizing, one could look at it as, what would you think if 25 or 30 years ago, IBM said that they were turning around and we’re now a modern, agile company instead of a slow-moving relic of the previous era, and they built an awesome new console app for OS/2?
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 accessibility support.
The fact that all of our devs are under 30 is merely coincidence :)
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 accessibility support.
The fact that all of our devs are under 30 is merely coincidence :)
I just started turning Quick Edit off because I understood it was responsible for that strange bug where the console sometimes gets stuck until you press return. :-( Is that one on the to do list?
That’s how selection has always worked. It halts console output until you’re done selecting.
It's overeager, then. It's pausing the console even when no selection is made. Maybe I'm clicking in the window accidentally, but I'm not selecting anything. I certainly don’t have the problem on Linux.
Ah, so I'm not the only on with this issue! Thanks for the workaround.
sun41(3)
Why do you need to select quick edit to be able to copy? That makes no sense.
You don't need to but it makes it easier
What about learning to use the OS?
Quick edit for UNIX style copy-paste with the mouse goes all the way back to Windows 9X.
The only issue is that it was always disabled by default, until they changed to be enabled by default with the latest set of changes.
Spending a couple of seconds after logging in to enable it, for the very first time on a new system, was never a big deal.
Quick edit for UNIX style copy-paste with the mouse goes all the way back to Windows 9X.
The only issue is that it was always disabled by default, until they changed to be enabled by default with the latest set of changes.
Spending a couple of seconds after logging in to enable it, for the very first time on a new system, was never a big deal.
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)
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...
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...
This is one of the major changes that happened since this team started working on the console. In Windows 10 it has line selection that flows correctly over line breaks.
This is also not true as of Windows 10 build 16299/Fall Creator's Update (what I'm currently using), and may not be true of an earlier release or two. Ctrl+C and Ctrl+V both work just fine in cmd. I found evidence it was considered an "experimental feature" available in the Command Prompt's Properties dialogue back in 2015, it looks like it's been folded into the default behavior at this point.
Microsoft's done a lot of work on legacy components of Windows like cmd and notepad in the last few years, assumptions about behavior that has worked the same for the last twenty years may no longer be valid. ;)
Microsoft's done a lot of work on legacy components of Windows like cmd and notepad in the last few years, assumptions about behavior that has worked the same for the last twenty years may no longer be valid. ;)
Powershell. All of these shortcomings were fixed in it. Currently its also supported in Windows/*nix
PowerShell is a shell, thus a console application, buy not the console. So it's just the settings of the console window if you observe any differences. The PowerShell shortcut on the start menu may have different settings from the command prompt shortcut.
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
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.
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.
> 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.
Security Questions are a really bad anti feature that nonetheless is really persistent. I don't need 5 more random alphanumeric Passwords in case I forget that other random alphanumeric password I can barely remember. In most places online where they are used the rip open huge security holes should you actually set reasonable a answer to "Whats my Pet called?".
Security Questions are a really bad anti feature that nonetheless is really persistent. I don't need 5 more random alphanumeric Passwords in case I forget that other random alphanumeric password I can barely remember. In most places online where they are used the rip open huge security holes should you actually set reasonable a answer to "Whats my Pet called?".
Yeah, and it was introduced for local accounts in Windows 10 just in the last few months. Beyond the general irritation of it being a poor security system, making me do it for a user account that isn't personal to me is additionally quite silly: I told the installer I was going to domain join the PC.
I end up mashing the keyboard for each one to create hopefully suitably random answers that even I myself don't know. But it's still arguably an additional security hole that I have to simply hope Microsoft hasn't somehow stored in plaintext somewhere.
I end up mashing the keyboard for each one to create hopefully suitably random answers that even I myself don't know. But it's still arguably an additional security hole that I have to simply hope Microsoft hasn't somehow stored in plaintext somewhere.
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.
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.
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.
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.
Even on Windows I use mingw64 terminal + pacman. My pain points are:
- Conemu can show up on a shorcut, Windows Console can't - Windows Console doesn't have tabs - There is no CTRL + R to search for the last command
Ok maybe I've got more bash issues: - autocompletion in cmd doesn't work, not for commands nor for command arguments, like in Linux consoles - mc doesn't work in cmd
- I really hate dos batch language because it is not logical imho (I don't want to start to rant about it here). On the other hand I remember the bash language better and can write small one liners to create commands that don't natively exist. PowerShell is not an alternative because it treats everything as text and inserts new lines, where bash does not.
- Conemu can show up on a shorcut, Windows Console can't - Windows Console doesn't have tabs - There is no CTRL + R to search for the last command
Ok maybe I've got more bash issues: - autocompletion in cmd doesn't work, not for commands nor for command arguments, like in Linux consoles - mc doesn't work in cmd
- I really hate dos batch language because it is not logical imho (I don't want to start to rant about it here). On the other hand I remember the bash language better and can write small one liners to create commands that don't natively exist. PowerShell is not an alternative because it treats everything as text and inserts new lines, where bash does not.
> There is no CTRL + R to search for the last command
On Unix this is typically a shell feature, not a console/terminal feature. The corresponding way to do this in the Windows console would be F8, I think.
> autocompletion in cmd doesn't work
> I really hate dos batch language
None of those have anything to do with the console.
On Unix this is typically a shell feature, not a console/terminal feature. The corresponding way to do this in the Windows console would be F8, I think.
> autocompletion in cmd doesn't work
> I really hate dos batch language
None of those have anything to do with the console.
Wow! This blew my mind. I have grown very used to using cmd, but have not thought of using the F keys before (do not know why). Behavior seemed strange at first, but after a quick DDG search found this StackOverflow question [0] and that led to this documentation [1]. This is a huge area of functionality which I don't think most people know about.
I will be using F7 a lot in the future.
As an aside, maintaining backwards compatibility (this is DOS era stuff) is why IMO it would be very hard to update core windows utilities, but maintaining backwards compatibility (and similar decisions) is why IMO Windows is as popular as it is.
[0] https://stackoverflow.com/questions/1641948/f-n-shortcuts-in...
[1] https://docs.microsoft.com/en-us/previous-versions/windows/i...
I will be using F7 a lot in the future.
As an aside, maintaining backwards compatibility (this is DOS era stuff) is why IMO it would be very hard to update core windows utilities, but maintaining backwards compatibility (and similar decisions) is why IMO Windows is as popular as it is.
[0] https://stackoverflow.com/questions/1641948/f-n-shortcuts-in...
[1] https://docs.microsoft.com/en-us/previous-versions/windows/i...
Almost any console is better than the Windows console. I use iTerm2 on OSX now, what an awesome UX. Maybe it's a good idea that you guys first take a look at what you are actually trying to reinvent.
Yikes, 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 of install base and legacy it has, or you'll break things in a way that has been historically unacceptable in Redmond.
But you just can't change existing shit willynilly in Windows, with the kind of install base and legacy it has, or you'll break things in a way that has been historically unacceptable in Redmond.
> 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?
> 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.
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.
> What exactly are backwards-compatibility goals of Windows? Are they that different from backwards-compatibility goals of POSIX systems?
I can still run software written for Windows 95, without recompilation, with a pretty high success rate. As far as I'm aware, only Linux has that level of ABI compatibility and unfortunately it's completely broken by userspace. Often you can't even run the same binary on two different distributions without recompilation.
I can still run software written for Windows 95, without recompilation, with a pretty high success rate. As far as I'm aware, only Linux has that level of ABI compatibility and unfortunately it's completely broken by userspace. Often you can't even run the same binary on two different distributions without recompilation.
The ABI is only part of backward compatibility. From another POV, you can run software designed for VT100 or other terminal in seventies on any Linux or Unix today, (though it may be recompiled. That legacy mentioned in previous post is that terminal is still considered serial device with specific protocol). There are companies, that do exactly that in production. You would be hard pressed to find DOS-era software that bangs on buffer starting at 0xB800:0000 that still works in 64-bit Windows.
> You would be hard pressed to find DOS-era software that bangs on buffer starting at 0xB800:0000 that still works in 64-bit Windows.
True, though 32-bit editions of Windows still include NTVDM which runs Win16 apps!
Microsoft is pretty fanatical about backward compatibility.
Why? It's the #1 reason most enterprises and many users continue to pay to install/upgrade to Windows.
Breaking backward compatibility with existing executables (not source-code) is a violation of the trust that we've earned with customers for the last 40 years or so.
Of course, some products/features/etc. are discontinued on newer OS', etc. but the core essential platforms are rarely discontinued.
True fact: Windows still runs VB6 apps - millions of them. EVERY DAY!
True, though 32-bit editions of Windows still include NTVDM which runs Win16 apps!
Microsoft is pretty fanatical about backward compatibility.
Why? It's the #1 reason most enterprises and many users continue to pay to install/upgrade to Windows.
Breaking backward compatibility with existing executables (not source-code) is a violation of the trust that we've earned with customers for the last 40 years or so.
Of course, some products/features/etc. are discontinued on newer OS', etc. but the core essential platforms are rarely discontinued.
True fact: Windows still runs VB6 apps - millions of them. EVERY DAY!
> The Windows Console code-base is currently (July 2018) almost 30 years old ... older, in fact, than the developers who now work on it!
It smells like ageism... Did you lay off the original "old" devs?
EDIT: :)
It smells like ageism... Did you lay off the original "old" devs?
EDIT: :)
Surely they have something better for developers with 30 years of experience to do than work on Windows Console.
It's, uh, not the only thing Microsoft works on.
It's, uh, not the only thing Microsoft works on.
I'm hoping this is a joke. Most developers don't stay at the same company on the same team for 30 years...
Lol any original devs retired a long time ago, can you imagine what $MSFT shares from 1989 are worth now?
With the recent surge in MSFT, it must be pretty gratifying for the stock options.
The recent surge? A dev getting a bunch of shares in 1988 would have been filthy rich by 1996, already :)
I don't think any of those devs stayed past 2000.
What the heck is this related to shares? You mean to suggest all original devs are millionaire, and that being a millionaire means you don't code anymore? And you, poor guy, missed out?
Early MSFT employees were compensated heavily with stock options. I think it's also pretty safe to say that few devs from that period are still coders, they've moved on to other roles or retired.
From Show Stopper!:
Technical preferences aside, the success of Windows was a windfall for Cutler and colleagues. Most had received sizable stock option grants on joining Microsoft, partly to compensate for their reduced wages. At other companies such stock grants might return 10 to 25 percent profit to a grateful employee over five to ten years. A doubling of value would be a bonanza. But lately Microsoft's stock had soared-with no limit in sight. Demand for Windows transformed Microsoft from the leader of the software pack into a giant looming over the rest of the industry. The company's net profits were especially impressive; an astonishing 25 percent of sales flowed to the bottom line. Options granted to Cutler two years earlier, while substantial at the time, were now breathtaking. And the stock price seemed a cinch to double over the next few years, given the company's bullish outlook.
Even at the current stock price, Cutler's options now were worth at least several million dollars. Havens and Perazzoli, meanwhile, were assured of clearing high six figures. Even the team's rookie programmer, hired fresh from Princeton the summer before, would reap a few hundred thousand dollars within three years.
From Show Stopper!:
Technical preferences aside, the success of Windows was a windfall for Cutler and colleagues. Most had received sizable stock option grants on joining Microsoft, partly to compensate for their reduced wages. At other companies such stock grants might return 10 to 25 percent profit to a grateful employee over five to ten years. A doubling of value would be a bonanza. But lately Microsoft's stock had soared-with no limit in sight. Demand for Windows transformed Microsoft from the leader of the software pack into a giant looming over the rest of the industry. The company's net profits were especially impressive; an astonishing 25 percent of sales flowed to the bottom line. Options granted to Cutler two years earlier, while substantial at the time, were now breathtaking. And the stock price seemed a cinch to double over the next few years, given the company's bullish outlook.
Even at the current stock price, Cutler's options now were worth at least several million dollars. Havens and Perazzoli, meanwhile, were assured of clearing high six figures. Even the team's rookie programmer, hired fresh from Princeton the summer before, would reap a few hundred thousand dollars within three years.
Most original Microsoft devs are millionaires, yes. I think Microsoft created the biggest group of billionaires and millionaires, out of any company.
Yup, found it:
> The company's 1986 initial public offering (IPO), and subsequent rise in its share price, created three billionaires and an estimated 12,000 millionaires among Microsoft employees.
12k millionaires! Let that sink in :)
Yup, found it:
> The company's 1986 initial public offering (IPO), and subsequent rise in its share price, created three billionaires and an estimated 12,000 millionaires among Microsoft employees.
12k millionaires! Let that sink in :)
I like the post, it seems like they are good guys doing a good work on an unrewarding application.
It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work remotely - the shell and the terminal are not clearly separated: the OS will open automatically a console for some kind of executables / cannot attach a shell to an arbitrary console
It seems to me that it shows a few things.
First, unix design was better as it was more flexible and lasted over time and computers evolution. Windows' design was sort of wrong since the beginning but they didn't change anything and developers were left to use one of their horrible APIs. This is similar to the difference between X Window and Win32 GUI API.
Second, MS does not care about developers except for the user of their flagship product Visual Studio. They put 30 years of developer effort solely on Visual Studio and nothing else. Compare with Apple, they at least cared of implementing an excellent terminal and contributed greatly to the wonderful LLVM compiler infrastructure.
So, okay some improvements might lands on Windows 10 at some moment but I personally don't care. At work we still use Win 7 and I think we will keep using it for a long time. The Windows Console is just horrible to use and propram for and a testament to the MS awful software and APIs that developers are forced to use because of Windows dominance.
It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work remotely - the shell and the terminal are not clearly separated: the OS will open automatically a console for some kind of executables / cannot attach a shell to an arbitrary console
It seems to me that it shows a few things.
First, unix design was better as it was more flexible and lasted over time and computers evolution. Windows' design was sort of wrong since the beginning but they didn't change anything and developers were left to use one of their horrible APIs. This is similar to the difference between X Window and Win32 GUI API.
Second, MS does not care about developers except for the user of their flagship product Visual Studio. They put 30 years of developer effort solely on Visual Studio and nothing else. Compare with Apple, they at least cared of implementing an excellent terminal and contributed greatly to the wonderful LLVM compiler infrastructure.
So, okay some improvements might lands on Windows 10 at some moment but I personally don't care. At work we still use Win 7 and I think we will keep using it for a long time. The Windows Console is just horrible to use and propram for and a testament to the MS awful software and APIs that developers are forced to use because of Windows dominance.
We're certainly not improving the console only because of WSL - WSL has highlighted a lot of functionality that we could improve upon, yes, but we're improving the console because the console needs improving.
I'd say that we're conceding that the linux commandline application model (having two streams of characters) is more portable and cross-platform compatible. The Windows Console API isn't particularly well designed and it's incompatible with *nix terminals, so instead of us trying to force our shitty API on them, we'll just adopt theirs.
I certainly care about developers. I know everyone on my team does. I know that there's not a tom of goodwill between Microsoft and external developers, but there are a lot of people at Microsoft who are working really hard to try and fix that.
I'd say that we're conceding that the linux commandline application model (having two streams of characters) is more portable and cross-platform compatible. The Windows Console API isn't particularly well designed and it's incompatible with *nix terminals, so instead of us trying to force our shitty API on them, we'll just adopt theirs.
I certainly care about developers. I know everyone on my team does. I know that there's not a tom of goodwill between Microsoft and external developers, but there are a lot of people at Microsoft who are working really hard to try and fix that.
So... I think the Windows model is superior in these respects:
Now, not everything is really a file on Unix. There are ioctls for some things -- lots even. And the limited and non-standardized representation of processes as files is obnoxious, but whatever, it works.
The Windows model of console as ioctl-/API-based is simply an utter disaster of calamitous proportions. It's the reason Unix users/devs hate the Windows experience, and it has held Windows back in some ways. The success of Windows as a whole has papered this over, and it's probably the reason that the console got no love from MSFT for thirty years, but the problems are real.
Another thing that is shockingly bad on Windows is the C run-time. The lack of a single C run-time DLL, the fact that the C run-time is statically linked into every DLL, and the total lack of love that MSFT has shown the C run-time, is atrocious. Doing portable code development, where by portable one means "runs on various Unix and Unix-like OSes _and_ Windows", is rather hard, and the hard part is always Windows. Invariably this involves writing C code with lots of #ifdef WIN32 spaghetti. The only good thing about this is that it has forced some memory management discipline on library APIs that might otherwise not have happened.
If there is any chance that you could get MSFT to fund a similar project for revamping the C run-time, that would be fantastic. Because there are so many discrete portions of the C run-time to fix up, such a project could probably scale to more than three developers -- perhaps three core developers, two developers to improve a variety of individual and peripheral functions, and two test engineers. Please mate.
- object handles >> file descriptors
- security descriptors >> {owner, group, mode, [acl]}
- access tokens >> [gs]et[e]?[ug]id(), [sg]etgroups(), initgroups()
Now, not everything is really a file on Unix. There are ioctls for some things -- lots even. And the limited and non-standardized representation of processes as files is obnoxious, but whatever, it works.
The Windows model of console as ioctl-/API-based is simply an utter disaster of calamitous proportions. It's the reason Unix users/devs hate the Windows experience, and it has held Windows back in some ways. The success of Windows as a whole has papered this over, and it's probably the reason that the console got no love from MSFT for thirty years, but the problems are real.
Another thing that is shockingly bad on Windows is the C run-time. The lack of a single C run-time DLL, the fact that the C run-time is statically linked into every DLL, and the total lack of love that MSFT has shown the C run-time, is atrocious. Doing portable code development, where by portable one means "runs on various Unix and Unix-like OSes _and_ Windows", is rather hard, and the hard part is always Windows. Invariably this involves writing C code with lots of #ifdef WIN32 spaghetti. The only good thing about this is that it has forced some memory management discipline on library APIs that might otherwise not have happened.
If there is any chance that you could get MSFT to fund a similar project for revamping the C run-time, that would be fantastic. Because there are so many discrete portions of the C run-time to fix up, such a project could probably scale to more than three developers -- perhaps three core developers, two developers to improve a variety of individual and peripheral functions, and two test engineers. Please mate.
Oh I'm certainly not conceeding that Linux as a whole is better than Windows - there are pros and cons to each. But I've found that writing console applications with VT sequences to be a generally preferable experience to the Console API. Now that we've added support for VT sequences, writing a cross-platform commandline application is pretty trivial - just use VT on every platform.
I feel you pain with the CRT, though I agree with the sibling comment, the uCRT is a way better experience. I know there is a team of pretty talented people working on that, but I think way below the level that's able to influence the allocation of developer resources - otherwise the console would have a lot more than 3 people on it :P
I feel you pain with the CRT, though I agree with the sibling comment, the uCRT is a way better experience. I know there is a team of pretty talented people working on that, but I think way below the level that's able to influence the allocation of developer resources - otherwise the console would have a lot more than 3 people on it :P
Look up the "universal CRT". It's already happening.
I don't think anyone who has suffered fixing their termcap, terminfo and stty settings would think Unix has much to boast about in the terminal space. Even today, whole swathes of key combinations have no distinct escape sequences, forcing a different experience for apps like Emacs that can run both native and in terminal.
FWIW, I worked at Borland back in the day, and it simply isn't the case that MS only cared about VS users.
FWIW, I worked at Borland back in the day, and it simply isn't the case that MS only cared about VS users.
I didn't get the impression that they consider the Console API in itself a flaw. An API for this is much more robust than an in-band text API that's part of your output. For example, no Windows console application has to even think about whether printing a user-provided string can be a problem. They do note that it's an impediment for porting software to Windows, as well as the problem that the API isn't able to be implemented by any other application, e.g. ConEmu. Those applications have to rely on scraping a hidden console window to work instead of just being an alternative console implementation.
I read it not so much as a testament to the perceived superiority of the Unix model, but rather that with WSL users expect certain things to work more Unix-like, just that they don't work like that right now.
I read it not so much as a testament to the perceived superiority of the Unix model, but rather that with WSL users expect certain things to work more Unix-like, just that they don't work like that right now.
The most obvious problem of their design is that there's no serialisation mechanism for their API calls, so apps don't remote over low bandwidth connections. Which is one of the big advantages of terminal apps to begin with.
Microsoft did objects better later on with COM and DCOM: you can imagine a better console API if COM had come first, but even then, DCOM network protocol was not good and had numerous problems that would have meant ssh still beat it. But trying to do OO API in 1989 with their tech stack wasn't a good idea.
Microsoft did objects better later on with COM and DCOM: you can imagine a better console API if COM had come first, but even then, DCOM network protocol was not good and had numerous problems that would have meant ssh still beat it. But trying to do OO API in 1989 with their tech stack wasn't a good idea.
You're conflating two things here:
Remote Procedure Calls have many implementations. CORBA and Java implement RMI, Microsoft implemented DCOM. And for serializing API calls, they do great.
However, what's REALLY hard about remote object systems like CORBA, COM+, etc. is reliably managing object lifetime semantics. It turns out that trying to manage stateful object lifetime via an inherently unreliable network connection is tricky, if not impossible.
All the reliability semantics, security infrastructure, etc. layered on top add considerable processing cost.
By comparison sending text back and forth via networks, and/or tunneling pipes (e.g. ssh) is a piece of cake.
Remote Procedure Calls have many implementations. CORBA and Java implement RMI, Microsoft implemented DCOM. And for serializing API calls, they do great.
However, what's REALLY hard about remote object systems like CORBA, COM+, etc. is reliably managing object lifetime semantics. It turns out that trying to manage stateful object lifetime via an inherently unreliable network connection is tricky, if not impossible.
All the reliability semantics, security infrastructure, etc. layered on top add considerable processing cost.
By comparison sending text back and forth via networks, and/or tunneling pipes (e.g. ssh) is a piece of cake.
X Window has a good design? Only because it allowed competing tool kits on top of it ("Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.")
Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.). The core concept, that of network part is actively being abandoned right now, see the Wayland efforts.
X Window won because its competitors were proprietary, basically. And then it dragged on because every application was compatible with it.
Win32 is also horrible, but you can kind of get why it was that way: the hardware was abysmal when it was conceived and backwards compatibility was super, super important in the early and cutthroat desktop market.
Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.). The core concept, that of network part is actively being abandoned right now, see the Wayland efforts.
X Window won because its competitors were proprietary, basically. And then it dragged on because every application was compatible with it.
Win32 is also horrible, but you can kind of get why it was that way: the hardware was abysmal when it was conceived and backwards compatibility was super, super important in the early and cutthroat desktop market.
I don't think Win32 UI API is terrible. It's basically message passing object orientation before its time.
The API idioms are clumsy to code against, but OTOH it's much more viable to avoid linking libc into your app, whereas in Unix land, the only portable API is defined largely in terms of a C worldview. And some things are just leagues better, like signals vs structured exception handling.
The API idioms are clumsy to code against, but OTOH it's much more viable to avoid linking libc into your app, whereas in Unix land, the only portable API is defined largely in terms of a C worldview. And some things are just leagues better, like signals vs structured exception handling.
> X Window has a good design? Only because it allowed competing tool kits on top of it ("Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.")
Yes only this simple thing made a much better design. It can be used to provide a modern and beautiful desktop environment even 35 years after its creation.
> Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.).
You are not supposed to use Xlibs directly to program user interface. They just provide the primitive APIs to create windows, process events and draw on the screen. It is normal to use a toolkit like Qt that use Xlib as a backend.
I agree that programming Xlib directly is not very sexy but it sort of make sense and is yet better than Win32 programming.
> The core concept, that of network part is actively being abandoned right now, see the Wayland efforts.
The fact that this is a good choice is still to be demonstrated.
> Win32 is also horrible, but you can kind of get why it was that way: the hardware was abysmal when it was conceived and backwards compatibility was super, super important in the early and cutthroat desktop market.
Yes, you can excuse them for creating Win32 at the time but they have no excuse for not providing qnything better after 30 years. Oh yes, you can create beautiful UI if you only use Visual Studio, you get use to all the warts and limitations, if you forget cross-platform, it will works only on windows, if you use visual studio installer and ship all the zillions of DLLs that you may need with the most baroque distribution system.
On windows I am still looking for a decent way of programming UIs without embracing all the MS bullshit.
Yes only this simple thing made a much better design. It can be used to provide a modern and beautiful desktop environment even 35 years after its creation.
> Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.).
You are not supposed to use Xlibs directly to program user interface. They just provide the primitive APIs to create windows, process events and draw on the screen. It is normal to use a toolkit like Qt that use Xlib as a backend.
I agree that programming Xlib directly is not very sexy but it sort of make sense and is yet better than Win32 programming.
> The core concept, that of network part is actively being abandoned right now, see the Wayland efforts.
The fact that this is a good choice is still to be demonstrated.
> Win32 is also horrible, but you can kind of get why it was that way: the hardware was abysmal when it was conceived and backwards compatibility was super, super important in the early and cutthroat desktop market.
Yes, you can excuse them for creating Win32 at the time but they have no excuse for not providing qnything better after 30 years. Oh yes, you can create beautiful UI if you only use Visual Studio, you get use to all the warts and limitations, if you forget cross-platform, it will works only on windows, if you use visual studio installer and ship all the zillions of DLLs that you may need with the most baroque distribution system.
On windows I am still looking for a decent way of programming UIs without embracing all the MS bullshit.
Even when compared against Amiga toolkits and Win16, Xlib with Athena or Motif were anything but pleasant.
X Windows is the main reason of "The Year of Desktop Linux" failure.
It is quite telling that ChromeOS and Android have ditched it.
Also the only UNIX that was actually a pleasure to code for was NeXTSTEP, guess what, it also didn't care for X Windows other than compatibility purposes.
X Windows is the main reason of "The Year of Desktop Linux" failure.
It is quite telling that ChromeOS and Android have ditched it.
Also the only UNIX that was actually a pleasure to code for was NeXTSTEP, guess what, it also didn't care for X Windows other than compatibility purposes.
> X Windows
... doesn't exist, of course.
... doesn't exist, of course.
Funny guy, everyone understood that I meant The X Window System™.
Well, it goes to demonstrating expertise, doesn't it?
Hard to know something if you don't know what it's called, innit?
Hard to know something if you don't know what it's called, innit?
> X Window has a good design?
X does. "X Window" might not, but it probably isn't in widespread use.
X does. "X Window" might not, but it probably isn't in widespread use.
> X Window
X.
X.
When I need more, I just type 'bash'. And bash also starts faster than PowerShell or Hyper.
So I don't see why they now change WIN+X and Explorer to use PowerShell rather than cmd.exe.
Keep improving cmd.exe. But please don't make it bloated.