Does Windows still rely on MS-DOS? - Super User | Hacker News Reader

Does Windows still rely on MS-DOS? - Super User

superuser.com

23 pointsivoflipse25 comments

Well, when I upgraded to OS X Lion the installer failed because of a problem with the BOOT.INI file on my Windows partition. Imagine my surprise at seeing "BOOT.INI" in the Mac OS X installer logs. For a split second I thought that OS X was just a shell on top of MS-DOS.

"BOOT.INI" was actually introduced in Windows NT: http://en.wikipedia.org/wiki/NTLDR#boot.ini

I'm planning to upgrade this weekend, hope I don't have a similar issue!

If you do, just clear the "read-only" and "system" flags from that file.

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.

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.

If I were explaining this to someone who didn't want a long story, I would actually say that newer versions of Windows don't rely, at their core, on an implementation of DOS; instead, they rely on an implementation of VMS. :)

The long story: http://everything2.com/title/The+similarities+between+VMS+an...

Windows may no longer have DOS code in it, but it certainly has DOS characteristics and limitations in it. Most significantly: drive letters, backslash path separators, and 260 char file name limits. Also the pathetic batch file system. There are a few other limitations that come from DOS days.

The Win32 subsystem certainly does enforce, at least in a default install, a lot of conventions that allow the system to maintain backwards compatibility with a long, long, MASSIVE legacy of software. Many, though not all, of them can be changed or disabled. That includes the command processor that interprets the batch language. If you think thats the only shell interpreter that is available for Windows, you should have a look at PowerShell. It's not too shabby.

There are important reasons why filenames can't be safely made longer for older apps. One of the best things about MS is how well they've focused on backwards compatibility ahead of "technically correct" that works well for nobody but pedants. But for applications that want to opt in to longer paths, they can use '\\?\' prefixes on their absolute paths, and have up to 32K UTF-16 characters.

Reply on news.ycombinator.com