Growing up with MS-DOS, I knew its role in today's Windows' usage of \ to separate directories and / for command-line arguments (choices that sound quirk-y in an Unix-influenced world that uses / and -, respectively.)
I never understood why MSFT - a very Unix-aware shop, having released their XENIX a year before MS-DOS - went with such an odd choice, until I looked at the (recently open-sourced) MS-DOS source code.
The files include documentation for computer manufacturers (so they could write compatible BIOS code, customize distribution, etc.), and this piece on MS-DOS 2.0 (which introduced subdirectories) suggests that - as usual in those times - the party behind the odd decision was none other than IBM:
@chesterbr DOS and Windows accept / as path separator, and - works or can easily be made to work as an alternative to / for command line options. It's rarely mentioned, but there clearly was some effort to be compatible with the Unix conventions.
@mansr good point, there are efforts and workarounds in place - although it's hit-or-miss; in my Windows days I would often use some flavour of bash (eg, from Cygwin; guess WSH is the current way to do it) as an intermediary whenever that was an issue, because the underlying default has been (and AFAIK still is) the backslash - and I never understood why it was chosen back then!
@chesterbr Windows "system calls" accept both / and \ equally. Neither is allowed in filenames, so there can be no conflicts. Some applications try to be clever and disallow / in entered paths, but native Windows tools do not have this problem.
One place where everything uses / even on Windows is in C preprocessor include directives.
Add comment