Why does Windows use backslash as path separator? (2019)

Original Article ↗ Hacker News Discussion ↗

Windows’ use of backslashes in file paths, rooted in early DOS design and IBM compatibility requirements, continues to frustrate many developers working on cross‑platform tools. Commenters describe problems with path parsing, legacy limits like MAX_PATH, inconsistent handling of forward slashes, and quirks around command‑line argument parsing on Windows. Others note that modern Windows APIs generally accept both separators, praise Microsoft’s strong backward compatibility, and argue that many issues stem from third‑party software or insufficient testing on Windows rather than the OS alone.

Historical reasons for \ on DOS/Windows

  • DOS 2.0 adopted \ as directory separator because / was already used for command switches (e.g., FORMAT C: /S /U), influenced by earlier systems and IBM compatibility.
  • Article and commenters stress this was not directly from CP/M itself (whose core tools didn’t use / for switches) but from Microsoft’s own CP/M tools and DEC traditions.
  • Some dispute or are skeptical about exact lineage (CP/M vs VMS vs DEC), but the consensus is: DOS 2.0 + IBM constraints fixed \ early.

Forward slash actually works (mostly)

  • Many Win32 APIs and the OS core accept / as a path separator; you can often mix / and \.
  • Major exception: cmd.exe and some older tools, which interpret / as option prefix.
  • Newer shells like PowerShell handle / paths well and even accept Unix-like commands (ls, cd, etc.).

Long paths and \\?\ quirks

  • Historically MAX_PATH was 260 chars; NTFS itself allows ~32k chars.
  • Windows 10+ can remove this limit via registry/group policy, but some tools (Office, built-in zip, some Git clients) still misbehave on long paths.
  • Prefixing paths with \\?\ disables normalization: no /→\ conversion, no trimming of trailing spaces/dots, and enables long paths.

Cross‑platform and tooling pain

  • Many devs complain Windows paths complicate cross‑platform software (especially when joining URI-style / paths with Windows roots, handling UNC, escaping \ in strings).
  • Others argue the real issue is insufficient Windows testing and reliance on string-concatenated paths instead of path libraries (PathBuf, pathlib, C++ std::filesystem::path).

Backwards compatibility vs “fixing it”

  • One side: sticking with \ and line endings like CRLF is a legacy burden that should have been abstracted away in UI and tooling long ago.
  • Other side: backward compatibility (running old DOS/Windows apps unchanged) is core to Windows’ value; changing separators would break scripts, tools, and user expectations.
  • Some note that since Windows already accepts /, the main remaining annoyance is UI convention and shell quirks, not the kernel APIs.

Related issues: escaping and newlines

  • \ conflicts with escape syntax in many languages, requiring \\ in strings.
  • Debate over CRLF vs LF: some call CR unnecessary legacy; others note CRLF is standardized in Internet protocols and historically matched teletype behavior.