"Windows: A 64-bit extension to a 32-bit patch for a 16-bit GUI shell running on top of an 8-bit operating system written for a 4-bit processor by a 2-bit company who cannot stand 1 bit of competition."
Unfortunately, no longer really true since they switched from the DOS based Windows to the Windows NT branch. (At least I think so.)
The snide about competition has also become somewhat hollow. Microsoft would love to go back to the monopoly days of the late nineties. But those days are gone.
This is made up. The design of NT was such that you could plug in "subsystems" such as Windows, POSIX, OS/2 etc. The Windows subsystem has had the most development, sure, but there is no "DOS" in the kernel.
When I had access, I decided one afternoon to read the source to the CMD interpreter.
It was about as bad as I thought it would be.
About an hour into using my Mac Pro's shell, I wanted to weep in relief. Microsoft does not get it. (Or if they do, it gets perverted into something like PowerShell, which I recently wasted a week on).
... and a bunch of other stuff. While CMD.EXE has its feet firmly rooted in 1982 or so.
Yeah, I know you can buy more whizzy shells. But MS really has no excuse for letting the NT console system rot as much as it has. Given that their programmers use it /all the time/, I find it hard to believe that someone hasn't written something better. (PowerShell overshot the mark, and wound up being unusable).
ConEmu can't fully replicate the CSRSS terminal behavior. It breaks pretty grossly when using advanced console functionality that works correctly in CSRSS's own terminal.
Aside from good cut&paste behaviour, one of the biggest problems with cmd.exe is you cannot resize the window horizontally larger than its set size by dragging on the window side. I do this when I see wrapped text from the output of a command. And if you experience wrapped text in a window smaller than its max size, enlarging the window doesn't reflow the text! Oh I see the same problem happens in Powershell too. :-(
Powershell and the command prompt use the same underlying console subsystem, that handles character-mode programs running and displaying their output in a window. It's a core part of Windows, rather than something supplied by each program.
The console system doesn't provide a TTY, as in Unix, but instead uses a CGA/MDA text mode metaphor: a matrix of (character,colour) pairs. This leaves no information about the text that's been printed, per se - it's more like the text equivalent of a bitmap. No carriage returns, no tabs, just an arrangement of characters that happened to have been put in the right places. If you widen the screen, there's not much Windows can do except for leave the new area blank, because it has no idea at all which line breaks are significant and which were just wrapped. (And indeed, if you resize the buffer in the console window's properties, this blanking is exactly what it does.)
There's sort-of nothing wrong with this system, in that it makes sense for a certain style of text-mode GUI console program, that were at one point exceedingly popular in MS-DOS - but unfortunately, it's not so hot for the TTY style of console program that everybody uses these days :)
(Fingers crossed for a much-needed shakeup, but this nonsense has stuck around for so long - I don't think that console properties dialog has changed one pixel since Windows NT 4 - that it's probably a bit late now. Meanwhile, one solution might be to run cmd.exe with a better class of terminal emulator - emacs will do this.)
Yes. In fact it's called Terminal.app; it's just a terminal emulator, but one that doesn't particularly suck. The shell is ordinary bash (or ksh or zsh or whatever; I forget what the default is).
The Powershell interpreter is made for the Powershell ISE. They just can't touch the CMD interpreter for the same reasons you found, Someone depends on that awful for console apps and god knows what.
So all the work went into the ISE instead of fixing CMD. Powershell console and cmd run powershell are just compatibility layers to make it more familiar.
Ah, my favorite problem with Win9x in fact was how Caldera was able to continue to sue MS based on the fact that it was based on DOS. I mentioned it in my blog article on the MS OS/2 2.0 fiasco and it should be obvious why.
