Hacker News Reader

Comment by speeder | Hacker News Reader

In fact a merge happened, windows kernel now is mostly NT based but has DOS era artifacts on it.

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.

"Merge" is overstating it. It is a NT kernel with some very small and inconsequential "fixups" done to it to make certain DOS constructs work.

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).

What is Mac Pro's shell? You mean your shell on OS X? And what did you find so bad with Powershell?

The "terminal" on MacOS X. It has:

- tabs

- cut and paste that actually works

- various ways to focus windows

- hey, search!

... 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).

So all your complaints are against the terminal emulator, which everyone agrees is bad. Use something like ConEmu. Here's Scott Hanselman on ConEmu - http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol...

> PowerShell overshot the mark, and wound up being unusable

You haven't still any points against Powershell and continue to pile up on it.

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.)

You are mixing the shell and the terminal. (But you're probably right that neither of them is good on Windows.)

I think CONHOST/CSRSS is to blame for this not CMD.

As far as I can tell, they're joined at the hip.

You /could/ redo one without redoing the other. No problem. But the result would be poor. :-/

So it isn't a shell. It's more like xterm, then, right?

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.

This is how jokes become urban legends.

Reply on news.ycombinator.com