Why Does Windows Use Backslash as Path Separator? (2019) | Hacker News Reader

Why Does Windows Use Backslash as Path Separator? (2019)

os2museum.com

120 pointssusam65 comments

The article is slightly misleading about the usage of the forward slash in CP/M.

It is true that the CP/M operating system itself did not use the forward slash, but the only reason for that was that the operating system included only a handful of executable programs, the main being the equivalents of the later "COMMAND.COM", "DEBUG.COM" and "COPY.COM" of Microsoft.

The very few executable programs provided with the OS did not have any command-line options. A few of the most common file operations were shell built-ins, not separate executable programs.

On the other hand, most CP/M executable programs (which were bought from third parties, not from Digital Research, the vendor of CP/M) had command-line options and, without exceptions, they used the forward slash for command-line options, instead of the hyphen used by UNIX.

It would have been absolutely impossible to use CP/M without being aware of the convention that the forward slash is used for the command-line options.

The article is completely correct that the use of the forward slash for options was not introduced by CP/M, but it was taken from the operating systems of the DEC Corp., which, during the seventies, were much more widely used than UNIX, which was an alternative for them only on PDP-11, and it was not yet used much outside the Bell Labs.

Nevertheless, all the programs ported to MS-DOS 1.0 (e.g. MS BASIC, Turbo Pascal, WordStar, dBASE and so on) had not been ported from programs written for DEC OSes, but from programs written for CP/M.

There is no doubt that the forward slash of MS-DOS 1.0 is directly inherited from CP/M. It was used by the same programs, for exactly the same options, so they must have kept the command-line parser without changes. I have used many of the same programs both first for CP/M and then for MS-DOS, so I can be certain about this.

I have also used the DEC RSX-11M operating system on PDP-11, and indeed the RSX-11M utilities, for example PIP (Peripheral Interchange Program, a file transfer program with many options, somewhat like UNIX dd), used the forward slash many years before CP/M and most programmers for CP/M should have been familiar with this convention, so they have reused it, but the relationship from DEC OSes to MS-DOS 1.0 is indirect, via CP/M.

There is no COPY.COM.

If you are wondering why this comment is downvoted, DOS 1.0 certainly did have COPY.COM. I suspect the commenter misread the 2nd paragraph and thought the three programs mentioned were CP/M program names.

Nope:

https://github.com/microsoft/MS-DOS/blob/04a3d20ff411409ab98...

You meant NOSMOKE.COM?

http://www.lachances.com/Humor/NoSmoke.html

> The very few executable programs provided with the OS did not have any command-line options

PIP was part of CP/M – it was an external executable rather than a command processor builtin, what in MS-DOS terminology is called an "external command", in CP/M terminology a "transient command" – and PIP did have command line options. It didn't use either hyphen or forward slash, instead it put switches (which it called "parameters") in square brackets, for example:

PIP LPT:=X.ASM[NT8U]

Prints the X.ASM file on the LPT: device (line printer). Option "N" means line add line numbers, "T8" means expand tabs at every 8th position, and "U" means convert lowercase to uppercase. [0]

This is different syntax from DEC operating systems, such as RSX-11M [1] or OS/8 [2], where PIP indeed used slash as an option character.

This "switches in square brackets" convention was used by other commands as well, for example the LINK linker [3]. This convention is (obviously to me) influenced by the IBM CMS mainframe operating system, [4] albeit with the parentheses of CMS replaced by square brackets. We know Gary Kildall used CMS at the Naval Postgraduate School, and it also (I'd say) influenced CP/M's use of drive letters A-Z (as in CMS file modes) instead of the multi-character disk device names generally used by DEC operating systems.

Square brackets is CP/M's native convention for command line switches. Forward slash is something not native to CP/M, but a convention spread by certain ISVs. I think the linked blog post is likely right that Microsoft introduced this convention in its products, and I'd say it likely spread to other ISVs due to the widespread adoption of Microsoft's development tools. The fact that many larger ISVs used DEC minicomputers as a cross-development platform, not just Microsoft, was likely also a factor. While IBM mainframes influenced Kildall personally, and through him CP/M, IBM mainframes were much less likely to be used by CP/M ISVs than DEC minicomputers, because they were a lot more expensive.

[0] http://www.tramm.li/i8080/cpm22-m.pdf page 1-33 (PDF page 40)

[1] http://www.bitsavers.org/www.computer.museum.uq.edu.au/RSX/A... page 5-2 (PDF page 70)

[2] https://www.grc.com/pdp-8/docs/OS8_System_Reference_Manual.p... page 65 (PDF page 73)

[3] http://bitsavers.org/pdf/digitalResearch/cpm_plus/CPM-Plus_U... page 83 (PDF page 96)

[4] see for example https://www-40.ibm.com/servers/resourcelink/svc0302a.nsf/pag... page 42 (PDF page 66)

Are there contexts where the backslash is still required? I've been using the forward slash in Windows for years. It works from Python, it works from the command prompt, it works in Explorer. But I don't know if that means it's completely redundant or if some places still require it.

It doesn't tab complete the path if you use forward slash in windows batch. I think forward slash works right in PowerShell, but I might be mistaken.

it works just fine in PowerShell and the new Windows Terminal but yeah, I doubt CMD will do auto-complete for you w/ forward slash

It will not. It completes out of the current directory when trying to TAB-complete following a slash.

Powershell will autocomplete forward-slash paths and convert them to back slashes.

At the API level, both '/' and '\' have been accepted since sub-directories were added to DOS.

It was only ever at the UI (command prompt), and in how some programs converted inputs and outputs where '\' was necessary, as the knowledge about '/' being usable wasn't all that widespread.

What used to peeve me was C source on DOS development environments with lines like:

  #include "path\\to\\file.h"

When the following always seemed to work (with the compilers I used):

  #include "path/to/file.h"

Or at least it did with Borland compilers.

This post isn’t about file paths but command line arguments

Because the forward slash is used for command line flags, there can be ambiguity when using forward slashes in paths that does not exist if using backslashes. Consider a directory on your root C: drive called "D". In a command prompt:

cd \D <-- This takes you to the C:\D\ directory.

cd /D <-- This is an error because /D is a flag.

True, but quoting the path will work: cd "/D"

How? Wouldn't the program's argv see the same string with and without quotes? Or is that just a *nix thing?

cd is a built-in of the shell / cmd, not an application, it does not use argv, AFAIK.

It should, as you said, not work for normal applications

nope. I read an article about this when i accidentally broke the arg parsing for wildcards. worked fine in linux, but not on windows :(

In Win32, argv is not part of the OS process API. The processes get the entire command line as a string, and have to parse it themselves - or, more commonly, leave it up to the C runtime.

But in this case, I don't think it matters.

This is interesting regarding args. https://nullprogram.com/blog/2022/02/18/

No, it doesn't. Try it and see for yourself. Make sure you're using Command Prompt and not PowerShell.

I made a typo while checking this, and amusingly while neither cd /D nor cd "/D" work, cd "/D? does.

I think \\?\ paths require backslashes.

They are still needed in UNC paths like \\server\...\.

UNC paths like //server/share/ are perfectly fine.

I tried it in Windows Explorer on Windows 10, and it just launches the browser for me instead of opening the folder.

CMD and Windows Explorer don't like that. Powershell handles it fine.

Also, the Registry.

And BTW .reg files need to double the backslash because it is parsed as an escape character.

It's required when passing a path as argument to Explorer. That is, when you type "explorer C:/" in the Run box or on the command line, Explorer opens in the default folder instead of in C:\. That's probably because Explorer also accepts URLs, so "explorer file://C:/" does work. For some reason, the Explorer address bar behaves differently.

Any / that occurs in an unquoted command line argument is going to be treated as a separator, so you've effectively invoked "explorer C: /".

That depends on the application’s argument parser.

That's the de facto standard for command line apps that ship with Windows itself.

The RT-11 OS for the DEC PDP used the forward slash for options and didn't have the concept of directories. The filename format for RT-11 was a three character device specifier, 6 character file name and 3 character extension

CP/M borrowed most of its structure from RT-11 and also didn't have directories, just devices. The filename format was 8.3 instead of 6.3.

MS-DOS in 2.0 (which introduced directories) defaulted to using the forward slash as the command options separator, but had an option in CONFIG.SYS for SWITCHAR that if you set to something other than forward slash, allowed you to use the forward slash as a directory separator.

> Both Windows 9x and NT were directly or indirectly derived from DOS and OS/2,

False, or perhaps only true for "Windows NT" before Dave Cutler and his team developed it while working for Digital. After Cutler arrived at Microsoft and took over development of NT there (i.e. replaced it with the OS he developed at DEC at... not sure NT 4.x? ), Windows NT was no longer derived from DOS, rather, DOS was ported to Cutler's OS. The last OS derived from or based on DOS may have been Windows ME.

Yea Windows NT is really VMS evolved and there is the joke that WNT is VMS++.

perhaps even more explicitly -- S+1=T ; M+1=N ; V+1=W ;

Holy shit! Never realized this!

upvote me! you fool! :-D

Now do the same for HAL.

Okay... IBM--

It's funny because it's true.

I think the author is referencing how IBM and Microsoft originally went in on developing OS/2 as a joint venture, but then when they split ways, MS allegedly* took it's work on OS/2 and used it as a starting point for NT.

I say allegedly because this was just passed around as sort of 'common knowledge' in OS/2 community groups back in the late 90's. I've never seen it actually verified.

I imagine some OS/2 tech got into NT, but I think, in general, this is, in general, false that Microsoft turned OS/2 into their flagship OS, untrue. Windows as we know it didn't technically exist before Cutler and his team developed it at Digital. Somewhere at Digital in the middle 1990's Cutler and team invented an OS and Digital wasn't interested in it. Cutler took his work and his team to Microsoft in late 1998, and the work he brought with him from Digital became Windows NT4.x (not sure when assimilation was first completed) and 2K, XP, Server, 7, 10, etc. The Windows that Microsoft developed prior to Cutler's arrival only bears visual resemblance to previous Windows versions. Windows 1,2,3,95,98 & ME were the products of that previous development, while late NT4, 2K, XP, Server(s), 7, 10, & 11 are instead the direct descendants of the OS Cutler developed at Digital.

>Windows as we know it didn't technically exist before

That's weird way to put it, kernel was swapped but Win32 was designed to be mostly source compatible with Win16. (and it was available both on WinNT and Win9x)

Something is not quite right there because I used Windows NT 3.1 and 3.5 before upgrading to 4.x and while it had the new Next/95 GUI it did not become a different operating system.

Cutler’s Wikipedia page puts his move to Microsoft in 1988, not 98, which makes the timeline clearer. He was directly involved with the creation of the Windows NT project, which started well before 1998.

Aside from the backslash history, Windows is very impressive in preserving backward compatibility. I still use a few programs over 20 years old (including JASC Paintshop Pro 7 from 2000, the 10 year old anniversary edition) and they still run on Windows 10.

Oh hey there. I'm still running Paint Shop Pro 8 which I purchased around 2002 or 2003 :-)

Another difference from Unix is that Windows does not always normalize multiple consecutive backslashes or slashes to a single one. A path like "foo\\bar" (or "foo//bar") gets you "The file name is not valid" in File Open dialogs, for example.

This isn't completely accurate. The Windows file dialog will not but the Win32 api does. Specifying a path such as foo\\bar in the shell for example will work.

The exception is if the multiple slashes appear at the beginning of the path. Windows accepts UNC paths which begin with double slashes. It will not normalize multiple slashes into double slashes at the beginning of a path but any following multiple slashes will be normalized to a single slash.

Some programming language(s?) seem to have taken over this strange characteristic: PHP. While most other languages use the backslash as an escaping symbol, in PHP you have it as a path separator in imports. It is not so nice.

Isn't it used for namespacing in PHP?

I'd be hard pressed to find anything nice about PHP

Deployment is easier than anything.

If I throw a dart randomly at the Big Board O' Language Features:

It is the only optionally typed language in common use whose types are checked at runtime.

Or:

Its type system has notation for 'the concrete type of `this`', what Rust calls `Self`, and no OO language in common use other than Swift has.

It's actually pretty easy to find something nice about PHP.

Types being checked at runtime seems like a bad idea, because it wont help you discover mistakes before the program runs. Ideally it would check types before the program runs and give an option to have checks at runtime in parts, for when you cannot know at compile time.

The type system also does apparently not provide a common Object kind of type. So Object cannot be used to work around the lack of generics. Making it difficult (impossible?) to create abstract data structures and making sure, that the functions for that ADT only accept things that adhere to some interface. This makes the type system rather less useful in general.

I guess it all stems from the earlier days of PHP, where OOP was added badly and in hindsight. It still shows.

Types are checked both statically and at runtime. Having only static checking like TS does means that when someone fits untyped code in via a type hole, they stand the same chance of getting it wrong as the untyped code did. I was convinced of the merits of this by dealing with nonnullable code in Kotlin vs C# - the former checks at runtime too, the latter does not, the latter makes it far harder to find and debug the lingering NullReferenceExceptions.

There is a common type, `mixed`. A common superclass fills that role in some OO languages, and not in others. The practical purpose of a common superclass is to provide builtin functions like C#'s object.ToString(). You don't need to do that when working with generics, and __toString is a magic function instead. So `mixed` fills that role perfectly fine.

They've already used the more common separators such as "." and "::" for other purposes, so "\" was the only one still available that was already used for something vaguely similar.

> The ergonomics of non-US keyboards were naturally not considered, which caused the path separator to be ridiculously difficult to type on some national keyboards (e.g. German), perhaps as a perverse reminder that ergonomics do matter.

The more I've shifted towards a keyboard-centric workflow, the more I'm feeling this lack of consideration regarding non-US layouts. When using a Spanish keyboard, the placement of characters like forward slashes, backslashes, tildes, pipes, etc. can be physically painful after an extended typing session. I'm considering either getting a US keyboard, or doing some serious keyboard map tweaking.

It's somewhat amusing to think that my current ergonomic predicaments are essentially the result of operating system and keyboard design choices and conventions that are over half a century old at this point.

I have a fairly keyboard centric workflow as well, and I didn't notice this until a few months ago I got a laptop with a US keyboard.

Suddenly all those key bindings and symbols made sense, or at least were somewhat reachable without contorting my hands. I never noticed how terrible DE keyboards are for programming before but I don't want to go back.

German backslash is very easy.

It's one of the reasons why, if you ask programmers from other countries what they think about programming languages with "native" keywords, the response tends to be overwhelmingly negative. Code is particularly punctuation-heavy, especially with the modern trend of C-style syntax. US-English keyboard layout has all of the needed things readily accessible - of particular importance is that ".,;" all require a single keypress. But then you have to stick to ASCII for identifiers and keywords.

And now most dev tools on windows have no problem to accept both slashes, but most Linux tools shit themselves when they see backslashes, different line endings or whitespace in paths. I am so annoyed by the Linux luddites.

Next: a history of why HFS used colon as its separator.

The author of this article tends to stay on the PC side, so I doubt he'll look into that. But others have written about it:

https://retrocomputing.stackexchange.com/questions/17069/why...

Paths were, and to a certain extent still are, not readily visible on Macs.

Reply on news.ycombinator.com