4 ms·

Since MS-DOS 2.0 :)

by chungy 3y ago

Since MS-DOS 2.0 :)

chrisandchris 3y ago
The exact answer is more like > Newer Windows Versions (NT and later) copied that behaviour > Windows applications did not always follow and may or may not accept either when parsing for filenames. Meaning it _may_ work but it also may not.
- chungy 3y ago
  That's basically the story of every file name rule on Windows :)
- JdeBP 3y ago
  There are two answers saying that, and one is sourced to Wikipedia whilst the other has screenshots of tests being run. Just copying Wikipedia to Stack Exchange isn't a good idea in general. In any case, there are plenty of contemporary 1980s discussions of SWITCHAR in CONFIG.SYS to be had, that go over the pathname separator characters as well. This has been well-known as a semi-official thing for 4 decades. Heck, one could even cite Peter Norton on the pathname separators, writing the The dissection of DOS 3.0 article in his column in the 1984-10-30 edition (volume 3 number 21) of PC magazine.
- skissane 3y ago
  > 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/

Since MS-DOS 2.0 :)

by chungy 3y ago

Since MS-DOS 2.0 :)

The exact answer is more like > Newer Windows Versions (NT and later) copied that behaviour > Windows applications did not always follow and may or may not accept either when parsing for filenames. Meaning it _may_ work but it also may not.

chungy 3y ago
That's basically the story of every file name rule on Windows :)
JdeBP 3y ago
There are two answers saying that, and one is sourced to Wikipedia whilst the other has screenshots of tests being run. Just copying Wikipedia to Stack Exchange isn't a good idea in general. In any case, there are plenty of contemporary 1980s discussions of SWITCHAR in CONFIG.SYS to be had, that go over the pathname separator characters as well. This has been well-known as a semi-official thing for 4 decades. Heck, one could even cite Peter Norton on the pathname separators, writing the The dissection of DOS 3.0 article in his column in the 1984-10-30 edition (volume 3 number 21) of PC magazine.
skissane 3y ago
> 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/