[dmethvin]

Yes, and several C/C++ conventions and types seemed to make that a safe choice, for example wchar_t. Let's face it, collectively we really screwed this one up. It's the biggest mistake since Microsoft chose the backslash as a path separator in DOS 2.0.

[magic_haze]

It was actually IBM's fault: they used '/' to denote CLI args in the apps they wrote for DOS 1.0, which didn't have any concept of directories. From Larry Osterman's blog [1]:

> Here's a little known secret about MS-DOS. The DOS developers weren't particularly happy about this state of affairs - heck, they all used Xenix machines for email and stuff, so they were familiar with the *nix command semantics. So they coded the OS to accept either "/" or "\" character as the path character (this continues today, btw - try typing "notepad c:/boot.ini" on an XP machine (if you're an admin)). And they went one step further. They added an undocumented system call to change the switch character. And updated the utilities to respect this flag.

[1] http://blogs.msdn.com/b/larryosterman/archive/2005/06/24/432...

[dmethvin]

Larry has that wrong, IBM wasn't to blame.

IBM licensed DOS from Microsoft. Microsoft bought DOS from Seattle Computer Products QDOS. That software got its command line switches using "/" from CP/M for compatibility reasons; originally, both CP/M and MS-DOS were available for the IBM PC.

CP/M borrowed the convention primarily from RT-11, the OS for the PDP-11, although it wasn't consistently followed there. Programs on RT-11 were responsible for parsing their own command line args, and not all of them used the same convention.

Inside Windows itself, most APIs accept either forward or backward slashes in paths (even both in the same path) without any special incantation. The problem is mainly at the application level where the whole forward/backward slash thing gets messed up because technically you should accept either one from user input and most app code expects one or the other.