> Meaning it _may_ work but it also may not. The Windows API has always supported forward slash, going back to Windows 3.x, probably even back to 1.x and 2.x.

> Meaning it _may_ work but it also may not. The Windows API has always supported forward slash, going back to Windows 3.x, probably even back to 1.x and 2.x. For example, if you run NOTEPAD.EXE in Windows 3.1 [0], and type a path like c:/windows into the File>Open dialog box, it is accepted just as c:\windows would be However, COMMAND.COM doesn't support forward slash, because of its use as an option character. (Unless you used the undocumented SWITCHAR setting to change the option character to a dash/hyphen, but that setting was disabled in DOS 3 onwards.) CMD.EXE partially has the same problem, although it can be worked around with quoting, which COMMAND.COM doesn't support. Applications have always been a mixed bag though – including under that label Microsoft products, and even utilities included with DOS/Windows. Although, nowadays it is rare to find applications with that problem, but I'm sure if you go back far enough it would have been much more common. The explosion in popularity of the web and also of Linux and macOS has made Windows app developers (and even users) much more forward-slash-aware than they used to be. [0] https://www.pcjs.org/software/pcx86/sys/windows/3.10/ https://www.pcjs.org/software/pcx86/sys/windows/3.10/