It annoys me having used Unix in college and now working on the Windows side. What’s the history behind this decision? Anyone know why it worked out this way?
Solution:
Unix introduced / as the directory separator sometime around 1970. I don’t know why exactly this character was chosen; the ancestor system Multics used >, but the designers of Unix had already used > together with < for redirection in the shell (see Why is the root directory denoted by a / sign?).
MS-DOS 2.0 introduced as the directory separator in the early 1980s. The reason / was not used is that MS-DOS 1.0 (which did not support directories at all) was already using / to introduce command-line options. It took this usage of / from CP/M, which took it from VMS. You can read a more thorough explanation of why that choice was made on Larry Osterman’s blog (MS-DOS even briefly had an option to change the option character to - and the directory separator to /, but it didn’t stick).
/ it is recognized by most programmer-level APIs (in all versions of DOS and Windows). So you can often, but not always get away with using / as a directory separator under Windows. A notable exception is that you can’t use / as a separator after the \? prefix which (even in Windows 7) is the only way to specify a path using Unicode or containing more than 260 characters.
Some user interface elements support / as a directory separator under Windows, but not all. Some programs just pass filenames through to the underlying API, so they support / and indifferently. In the command interpreter (in command.com or cmd), you can use / in many cases, but not always; this is partly dependent on the version of Windows (for example, cd /windows works in XP and 7 but did not in Windows 9x). The Explorer path entry box accepts / (at least from XP up; probably because it also accepts URLs). On the other hand, the standard file open dialog rejects slashes.
