Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Why is the DOS path character "\"?

Why is the DOS path character "\"?

Rate This
  • Comments 54
Many, many months ago, Declan Eardly asked why the \ character was chosen as the path separator.

The answer's from before my time, but I do remember the original reasons.

It all stems from Microsoft's relationship with IBM.  For DOS 1.0, DOS only supported floppy disks.

Many of the DOS utilities (except for command.com) were written by IBM, and they used the "/" character as the "switch" character for their utilities (the "switch" character is the character that's used to distinguish command line switches - on *nix, it's the "-" character, on most DEC operating systems (including VMS, the DECSystem-20 and DECSystem-10), it's the "/" character" (note: I'm grey on whether the "/" character came from IBM or from Microsoft - several of the original MS-DOS developers were old-hand DEC-20 developers, so it's possible that they carried it forward from their DEC background).

The fact that the "/" character conflicted with the path character of another relatively popular operating system wasn't particularly relevant to the original developers - after all, DOS didn't support directories, just files in a single root directory.

Then along came DOS 2.0.  DOS 2.0 was tied to the PC/XT, whose major feature was a 10M hard disk.  IBM asked the Microsoft to add support for hard disks, and the MS-DOS developers took this as an opportunity to add support for modern file APIs - they added a whole series of handle based APIs to the system (DOS 1.0 relied on an application controlled structure called an FCB).  They also had to add support for hierarchical paths.

Now historically there have been a number of different mechanisms for providing hierarchical paths.  The DecSystem-20, for example represented directories as: "<volume>:"<"<Directory>[.<Subdirectory>">"FileName.Extension[,Version]" ("PS:<SYSTEM>MONITR.EXE,4").   VMS used a similar naming scheme, but instead of < and > characters it used [ and ] (and VMS used ";" to differentiate between versions of files).  *nix defines hierarchical paths with a simple hierarchy rooted at "/" - in *nix's naming hierarchy, there's no way of differentiating between files and directories, etc (this isn't bad, btw, it just is).

For MS-DOS 2.0, the designers of DOS chose a hybrid version - they already had support for drive letters from DOS 1.0, so they needed to continue using that.  And they chose to use the *nix style method of specifying a hierarchy - instead of calling the directory out in the filename (like VMS and the DEC-20), they simply made the directory and filename indistinguishable parts of the path.

But there was a problem.  They couldn't use the *nix form of path separator of "/", because the "/" was being used for the switch character.

So what were they to do?  They could have used the "." character like the DEC machines, but the "." character was being used to differentiate between file and extension.  So they chose the next best thing - the "\" character, which was visually similar to the "/" character.

And that's how the "\" character was chosen.

Here's a little known secret about MS-DOS.  The DOS developers weren't particularly happy about this state of affairs - heck, they all used Xenix machines for email and stuff, so they were familiar with the *nix command semantics.  So they coded the OS to accept either "/" or "\" character as the path character (this continues today, btw - try typing "notepad c:/boot.ini"  on an XP machine (if you're an admin)).  And they went one step further.  They added an undocumented system call to change the switch character.  And updated the utilities to respect this flag.

And then they went and finished out the scenario:  They added a config.sys option, SWITCHAR= that would let you set the switch character to "-".

Which flipped MS-DOS into a *nix style system where command lines used "-switch", and paths were / delimited.

I don't know the fate of the switchar API, it's been long gone for many years now.

 

So that's why the path character is "\".  It's because "/" was taken.

Edit: Fixed title - it's been bugging me all week.

 

  • several more tidbits to this story:

    IBM made us chose a path separator that was unshifted on the original PC keyboard. Tim and Z and friends chose "\" because most of the other unshifted characters already had meaning to command.com. there was lots of discussion at the time about ":" for example, which was used in some other heirarchical file systems. it's the drive separator but not hard to disambiguate. IBM nixed it because it requires a shift key to type.

    the mechanism that became "SWITCHAR" was originally put in because they wanted to prove that it would be easy to disambiguate the path separation function from the command line switch function. this was entirely correct and nearly all command line apps support both "-" and "/" seamlessly. but IBM refused to buy it.

    Much effort was made to keep the fact that SWITCHAR was in shipping systems a secret because it was suspected that when IBM found out they would make us take it out. this suspicion was proven correct. It took them almost 5 years to find it though, and none of the original DOS crew was still working on it. Eric made the change, as I recall.

    the Tops-10 ==> CP/M ==> DOS genealogy someone else mentioned is correct. Tops-20 was very late in the story and not really relevant.
  • Crikey - I'd almost forgotten I'd asked that ... 8)

    many thanks for the explanation - this was one of those little things that I have wondered about every now and then - and it is very nice to have an answer (and a pretty comprehensive one to boot).

    This has made my day!

    Declan Eardly
  • Another 'undocumented feature' in MS-DOS that I used a lot was that the API calls that used drive letters did not validate the character for a drive letter - this let you use things like "#:/HIDDEN" and get away with it...although I am now hazy about what actually happened, I remember that I used it several times.
  • I used CP/M as a young punk, then VMS in college, and DOS later in college. I found my user experience to be fairly consistent across all of these. (I still have trouble with VMS directories, I must admit.)
  • I remember being very annoyed when I went from using Visual C++ 1.52 to a 5.0 (both on Windows NT 4). 1.52, being 16-bit, used the 16-bit file dialogs, which could grok a typed path containing forward slashes. 5.0 used Explorer file dialogs which couldn't (I don't know if this has been fixed in later Windowses).

    Do we get a matching retrospective on the function that moved all the special files into \DEV (sorry, /DEV)?
  • "It doesn't even support changing the current path to a UNC share, which is a HUGE limitation of both CMD.EXE and any future shells."

    4NT (from http://jpsoft.com/) supports CD to a UNC path. Just type CDD \\myserver\myshare\ and there you are... At the root of a share! :)

    (I even suspect it was I who suggested this to JPSoft many years ago)

    --
    Rune
  • HtmlEncoding fixed? Looks OK in the comment posting form... let's see how it looks once it's posted...
  • This is interesting bit of information.
  • Ancient History: The origins of '\'

  • Explicación (en ingles) de por qué se elegió el caracter (backslash) como el separador de ruta para Windows.

  • PingBack from http://warpedvisions.org/2007/02/11/why-is-the-dos-path-character/

  • Larry Osterman tells the entire story: simply because slashes were already used for parameters before DOS even knew what a path or a directory is. Nice read and a trip down memory lane.

  • PingBack from http://gen5.info/q/2008/05/13/tame-sql-with-multiline-quotes-in-c-and-php/

  • PingBack from http://billgatos.wordpress.com/2007/02/22/la-barra-inversa-de-ms-dos/

  • PingBack from http://www.keyongtech.com/4605205-using-inquire-to-test-if

Page 2 of 4 (54 items) 1234