Hacker News Reader

Comment by fuzzix | Hacker News Reader

I could be pithy and answer "No", but in my maintenance of Windows in various contexts I rely on that shim of DOS emulation, Start -> Run -> cmd.

I feel like I get much of the quick info (e.g. ipconfig, net) I need here faster than I would get it from Control Panel -> Network (something) -> (forget the next bit).

Does Windows still rely on DOS? No. Do I? Sure.

View on HN

But the answer is still no. You are not relying on DOS. You are relying on a command line interpreter that ships with Windows. It likely has nothing to do with DOS unless you are using a very old version of Windows.

Indeed. I first encountered DOS in the 3.2-ish days. I'm pretty sure the manual did not include 'net' or 'ipconfig'...

But the current Windows command line that has taken on the guise of DOS is useful to me.

But there is no reason why it should look so ugly in 2011. Linux and OS X have much nicer versions of DOS, although I don't know why they removed the 'dir' command... </s>

The problem here is using "cmd.exe". powershell.exe (see http://technet.microsoft.com/en-us/library/bb978526.aspx) is really a very nice shell (and I believe it supports "dir").

I'm a regular Linux/OSX user, but recently needed to do some Windows work. I heard the same things about powershell (powerfull, very nice, just like the ones I'm used to)

It's not. It's limited and it looks ugly as hell. Hated it. Please stop telling people it's good

(but yes, it does support both ls and dir (but strangely there were a few things I could do in cmd that I couldn't do in powershell (can't remember what now though)))

I tried powershell. Seems like a lot to learn before it is actually better than cmd.

I mostly just use cygwin's bash as my cli on windows.

Powershell doesn't solve the biggest problem of dealing with cmd.exe: it's still cmd.exe. It's still running in an identical, terrible, interface. Compare the environment in which it runs to iTerm2 on OS X or even gnome-terminal, and it's sadly, sadly ineffective. Hell, my SSH client is a better "console" than the wrapper around cmd.exe/powershell. (And at times I've used it as such, installing cygwin and sshd solely so I could get a sane console in something that wasn't cmd.exe or rxvt.)

The difference between the Windows console and the a Unix one is that you can't fix the Windows console. Some programs, i.e. Console, try, but the Windows CLI is buried way too deeply in CSRSS and ends up depending so tightly on the crap you see exposed in cmd.exe that attempts to build something better have largely failed.

Actually, you just mean the console, not cmd.exe.

cmd.exe is just an command interpreter (like bash) that needs a console/terminal (like xterm) just as any other CLI application does.

In other words, is not cmd.exe that sucks, but the Windows console. If Microsoft improved the console, cmd would immediately become nicer to use (though still hobbled by an inane scripting language).

</pedantry>

No--cmd.exe is very tightly tied to the underlying command line infrastructure. This is a large part of why alternatives such as Console are so bad--they can only access the command interpreter and infrastructure as a stream, which rules our most character-mode applications. (Cygwin/rxvt get around this by not using the Windows infrastructure at all; curses can be built for Windows and works in cmd.exe, but character-mode code written for cmd.exe will break hard in rxvt.)

Sadly, for most definitions, cmd.exe is the console and the interpreter.

nicer versions of DOS?

It's a joke, he/she is playing ignorant for humorous purposes. I smiled. :)

debian still seems to have "dir".

It is an actual binary executable too, and not a script, alias, symlink or builtin like I thought it was.

Try "command" in that field instead. I don't even know if it still ships with Windows 7, but my gut says yes.

Interesting that it still ship/s|ped/.

I am wondering why drive letters still exist. Was there a need for continuity across Windows platforms with different bases (3.1/NT/9x) or was the mania for backwards compatibility such that the model needed carrying forever?

Surely it is trivial enough to abstract \hd0 as C: for legacy applications.

This comes to mind because of the irritation of assigning a drive letter to a SMB map only to have it usurped by some multi-card reader USB thing which nabs drive letters up to H:

Surely a case for a class-based VFS - \hd, \usb, \opt(ical) ;)

edit I had momentarily forgotten about the 8.3 PROGRA~1/ mess. Please disregard any misguided attempt at an elegant "out" ;)

The drive letter mappings are essentially already that - partition letters are totally arbitrary. Under the hood, partitions are addressed via UNC paths.

It is not UNC paths. It is NT device paths.

64-bit Windows 7 has no 16-bit subsystem, so it cannot run command.com, nor any DOS application. Old games and the like need to rely on DosBox or Windows XP Mode or similar virtualization approaches.

Reply on news.ycombinator.com