MS-DOS and derived systems use backslash \ for path separator and slash / for command parameters. Unix and a number of other systems used slash / for paths and backslash \ for escaping special characters. And to this day this discrepancy causes countless woes to people working on cross-compilers, cross-platform tools, things that have to take network paths or URLs as well as file paths, and other stuff that you'd never imagine to suffer from this.

Why? What are the origins of this difference? Who's to blame and what's their excuse?

  • 3
    While your question is perfectly reasonable, your phrasing seems to imply that you think the UNIX approach was already a de facto standard and MS-DOS was unique in deviating from it. See, as a counter-example, how the Macintosh OS used : as its path separator until MacOS X introduced POSIX APIs. This question goes into the history of that decision and answers point to : and . as path separators predating UNIX's use of /.
    – ssokolow
    Commented Aug 1, 2022 at 20:10
  • @ssokolow UNIX was there with its forward slashes long before MacOS and DOS were created.
    – SF.
    Commented Aug 2, 2022 at 8:13
  • 1
    @SF. And, as the answer phuclv linked says, DOS got it from CP/M, which got it from VMS. I don't know why VMS chose \ when UNIX chose / seven years before VMS's first release (going by Wikipedia dates), but it wasn't a settled thing. Other designs were using : and . in the mid-60s, half a decade before UNIX decided on /, and UNIX broke from Multics's > because they wanted to use it for shell piping.
    – ssokolow
    Commented Aug 3, 2022 at 5:31
  • Use of UNIX back then wasn't nearly as ubiquitous as it is today. Almost all of industry and many schools used manufacturer-written and -supplied operating systems, especially from DEC. And within the more well-known CS schools (not that it was called "CS" then) there was also a lot of use of homegrown OSes. So the influence of UNIX wasn't as pronounced as it is today, as well - that took many years to develop.
    – davidbak
    Commented Aug 3, 2022 at 16:51

2 Answers 2


PC/MS-DOS 1 used the slash (/) as the command line switch indicator (like DEC's RSX11 and DG's RTOS before), so when DOS 2.0 introduced subdirectories, they did need a new one. Backslash (\) came somewhat natural - at least on US keyboards.

With 2.0 IBM/Microsoft also tried to reverse that decision and introduce a syscall (INT 21h function 3700h and 3701h) and a CONFIG.SYS option (SWITCHAR=) to set a different switch indicator. All manufacturer supplied commands would obey that new char. Set to a hyphen (-) would make the syntax more like Unix.

In fact, in paths, the OS didn't care. All dedicated path names, like in syscalls, can be written with either slash. It's only within the command line scan of each command, that simple slashes get interpreted as switch indicators. The idea was that people could/should migrate to a Unix-like style, but that didn't catch on.

With DOS 3.0 the SWITCHAR= option got removed fom CONFIG.SYS, but the syscalls are still availabe up to today.

  • 5
    Re the SWITCHAR syscalls, DOS 4 ignored them, and from DOS 5 onwards / is hard-coded (so the syscall still works, but it always returns /). There are several TSRs which restore functioning syscalls, and alternative command processors which honour them (e.g. 4DOS, IIRC). The use of / was indeed based on the DEC operating systems (at least, that’s what The MS-DOS Encyclopedia says). Commented Sep 9, 2017 at 13:28
  • 1
    @Raffzahn wow my memory of CP/M is not as good as I thought... though I used it in school at the same time as RSTS/E and DCL and I guess it's all merged...
    – mannaggia
    Commented Sep 10, 2017 at 1:58
  • 1
    @mannaggia - I also have memories of CP/M that disagree here. But I think what's happening here is that after official CP/M-80 development stagnated, 3rd party add-ons may have extended or replaced the shell with more DOS-like versions. This summary of CP/M 3 commands dates from 1984, but the era I was using CP/M in was closer to 1988, and it may well have been a substantially different dialect by then.
    – Jules
    Commented Sep 10, 2017 at 4:22
  • 1
    Just because, here's Larry Osterman of Microsoft's recollections on the issue which are congruent with yours. (Looks like his blog post's title got munged through various blogging platform transitions.)
    – Dranon
    Commented Sep 11, 2017 at 2:22
  • 2
    ...and according to this video by VWestlife, MS-DOS 2.0 was originally intended to be a middle-ground in a migration pyramid between MS-DOS and XENIX named XEDOS. Among other things, that helps to explain why MS-DOS 2.0 introduced APIs that enabled more UNIX-like and less CP/M-like approaches to things like I/O.
    – ssokolow
    Commented Aug 1, 2022 at 20:04

The README.txt file in the MS-DOS 2.0 source code, which was apparently intended to guide OEMs on how to build custom DOS builds for their hardware, indicates that the decision to use backslash was requested by IBM: Microsoft had been originally intending to use forward slash, and the change happened late in the development process. This is probably why the kernel ended up supporting the use of either character -- it was, presumably, too late to change over fully.

The user manual contains some significant errors. Most of these are due to last minute changes to achieve a greater degree of compatibility with IBM's implementation of MS-DOS (PC DOS). This includes the use of "\" instead of "/" as the path separator, and "/" instead of "-" as the switch character.

  • 2
    This is true, but very widely misinterpreted – the forward slash as an option character did not come from IBM, IBM's own operating systems (mainframe and minicomputer) never used that syntax. What IBM objected to, was Microsoft's proposal in DOS 2.0 to change it from slash to dash – IBM cared about backward compatibility. But IBM wouldn't have had a problem if Microsoft had made it dash all along, starting with DOS 1.0; IBM didn't care what the syntax was in the initial version, but they didn't want it changed in a subsequent. Commented May 26, 2023 at 1:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .