Since when does Windows support forward slash as path separator?

Question

Historically, Windows used CR/LF and backslash, first for new lines, second for path separator.

But it turns out that it supports forward slashes as well:

Note that Windows supports either the forward slash (which is returned by the AltDirectorySeparatorChar field) or the backslash (which is returned by the DirectorySeparatorChar field) as path separator characters, while Unix-based systems support only the forward slash.

So, when did Windows start supporting forward slash as a path separator?

Unfortunately, the forward slash does not work always. :-( I yet have to find the pattern. — the busybee, Jan 27 '24 at 16:36
I have a vague memory that (forward) slashes were always reserved in Windows, as MS was (at the time) trying to convert to Unix style path names. Since DOS 2 the system wide path separator could be queried to be used in any parsing ... ofc, not many non MS applications did so. Edit: Found a Win 1.0 resource file containing forward slashes in path names. — Raffzahn, Jan 27 '24 at 16:55
@wizzwizz4 No, as I have no real source to cite. this could have been just for the development environment - after all, MS was using Xenix to develop windows. I also peeked thru the Win 2.0 developer documents, but couldn't find any location to cite. So it's not really an answer to the question asked. — Raffzahn, Jan 27 '24 at 17:22
Windows is not a monolithic thing. One thing is the NT kernel support. The support in the “Windows Subsystem”, Windows core apps (e.g. Explorer) and 3rd party applications, in the face of 40-years of backward company constraints, is a different matter entirely. Looking forward to a well-documented answer. — Euro Micelli, Jan 27 '24 at 18:32
@EuroMicelli The question is about Windows and 'first', so the topic starts waybefore there was any "NT kernel support". — Raffzahn, Jan 28 '24 at 01:30
https://stackoverflow.com/questions/38428561/difference-between-forward-slash-and-backslash-in-file-path/38428899#38428899 — PC Luddite, Jan 28 '24 at 04:02
It doesn't look like it's very well-supported on Windows 11. Tab completion is buggy, and some valid folders are claimed to be "invalid" when you try to change into them. — Martin Argerami, Jan 28 '24 at 21:28
There is an excellent deep-dive into the converse question of this one on the OS/2 Museum from 2019, here: https://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ By converse, I mean not "why does Windows accept / in paths?" but "why does Windows use \ for paths?" — Liam Proven, Jan 29 '24 at 12:30

score 38 · Accepted Answer · edited Jan 29 '24 at 09:34

TL;DR: Windows did not explicitly support both, but DOS did since 2.0

The answer is rather a clear "yes but" (*1):

DOS 2.0 and later supported both ways, thus all DOS functions will work properly either way.
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.

The Long Read

Since when does Windows support forward slash as path separator?

This depends quite on the viewpoint taken. After all, early Windows is a GUI on top of DOS, originally using DOS and adding a layer to it, not replacing it. DOS in turn supported both slashes as path separators since 2.0. (*1)

The MS-DOS Encyclopedia notes on page 284 regarding path names:

Names in pathnames passed to Interrupt 21H functions can be separated by either a back slash (\) or a forward slash (/). (The forward slash is the separator character used in path names in UNIX/XENIX systems.) For example, the pathnames C:/MSP/SOURCE/ROSE.PAS and C:\MSP\SOURCE\ROSE.PAS are equivalent when passed to an Interrupt 21H function.

Thus all DOS functions that take a path name - and all Windows function that forward a path name to DOS - will support both ways (*2) since Windows 1.0 (*3)

This can easily be tried online using PCjs with a Windows 1.01 image (*4)

(Thanks to DL444 for the idea :))

Opening Notepad with a full filename using forward slashes.

This results in Notepad opening that file and showing the path name in its title bar:

Resulting opened file in Notepad

Except, the title line is a bit strange. Normally Notepad shows, like all early windows applications, only the file name, without path or drive (*5), as seen here when navigating with the open dialog:

Opening the test-file using the open dialog box.

But when using a path a command line argument the drive is gone but the path still visible. Doing the same with forward slashes shows a result like using the opening dialog:

Now with back slashes

Using back slashes gives the same output as using the dialog box:

Now it only shows the file name, no path

Ergo, the (DOS?) file function used work with either slash (*6), but applications like Notepad did not at all care about a forward slash. Despite presumably being written by the very same team that did Windows and for sure according to all guidelines at the time.

Many Years Later (Win10)

Using Win 10 CMD to start Notepad using forward slashes works better than expected:

Obviously Notepad has learned a bit within the last 38 years :))

Conclusion: It Does, But it's Incoherent.

The DOS/file system parts of Windows always did and still do support both separators, other parts may or may not (*7) - although they did improve over time.

*1 - BTW: The item has already been asked and answered.

*2 - That's why slash is a forbidden character in file name entries - and a known way to obfuscate software.

*3 - Windows 1.0 requires DOS2.0 or later - but then again, there are no path names prior to 2.0, so that's moot anyway :))

*4 - All following screenshots and observations taken with this setup of PCjs, DOS 2.0 and Windows 1.01.

*5 - And all uppercase.

*6 - Starting with 3.0 DOS itself uses an internal function (INT 2Fh function 1204h) to convert slashes. Interestingly using a WCHAR - I would assume to support MBCS.

*7 - Which in turn is not exactly unusual for Windows

According to this video on XEDOS, it's a remnant of Microsoft's original idea to upsell people from DOS to XEDOS and then to XENIX, with DOS 2.0 effectively become DOS 1.0 plus all the XEDOS features they could roll into it when they changed their mind. (eg. subdirectories, switchable path separators, APIs more UNIX-like and less CP/M like, etc.) — ssokolow, Jan 28 '24 at 11:38
Some pathnames, particularly those with spaces, need to be quoted to support forward slashes. — Davislor, Jan 28 '24 at 18:11
One thing I note is that DOS (and now Windows) usually uses / for command line switches. So starting a parameter with / would usually not be interpreted as a file name on the root folder of a drive, but starting one with \ would. — trlkly, Jan 29 '24 at 17:50
And the same test works on Windows 95. You can give notepad a path with a / and it works. And the Save As dialog box displays the amusing error message "Not enough memory to perform this operation". — Joshua, Jan 30 '24 at 02:47
For NT, kernel and filesystem support of '/' would be useful for the Posix subsystem, avoiding the need to translate pathname strings. I had always (before this answer) believed that NT had originated support of '/' for this reasons. — dave, Jan 31 '24 at 16:45

score 14 · Answer 2 · answered Jan 27 '24 at 20:32

14

A quick experiment in 86Box made me believe that this is supported starting from the very beginning with Windows 1.0. At least notepad and its standard file open dialog would accept paths delimited by either \ or /.

Screenshot of notepad opening a file with forward-slashed path in Windows 1.0. See the title bar for confirmation.

answered Jan 27 '24 at 20:32

DL444

311
1
5

2

I'm not sure there was such a thing as a "standard" file open dialog before Windows 3 -- rather, each program would have to implement its own from scratch. – john_e Jan 28 '24 at 12:55
1

@john_e No, But: While there was no single function to call for a file dialogue like in GEM, Windows provided a set of functions to handle all elements of such a window, allowing a way more flexible configuration. It also had the advantage that such a box would be an ordinary resource like any other. So while such windows could look quite different, their elements would work the same. Not to mention that most programs simply copied the example provided with the SDK. – Raffzahn Jan 28 '24 at 20:40

Mark Williams · Answer 3 · 2024-01-29T21:27:33.997

11

Since MS-DOS 2.0:

From https://en.wikipedia.org/wiki/Backslash#Filenames

MS-DOS 2 copied the hierarchical file system from Unix and thus used the forward slash, but (possibly on the insistence of IBM) added the backslash to allow paths to be typed into the command shell while retaining compatibility with MS-DOS 1 and CP/M where the slash was the command-line option indicator. For instance, in a Windows command shell, you can add the "wide" option to the "dir" command by typing "dir/w", yet you can run a program called "w" in a subdirectory "dir" with "dir\w". Except for COMMAND.COM, all other parts of the operating system accept both characters in a path, but the Microsoft convention remains to use a backslash, and APIs that return paths use backslashes.

Further, the question asks about Windows APIs. The DOS kernel, on which early versions of Windows are based has accepted forward slash as a path separator since before Windows was invented, so Windows APIs have always accepted forward slash. However, the Windows 3 API function openfile has a bug when the first character of a filename is a forward slash.

Windows NT and onward have maintained this for backward compatibility, even though internally they will normalise paths to regular backward slash notation.

edited Jan 29 '24 at 21:27

answered Jan 27 '24 at 16:27

Mark Williams

4,062
1
23
50

4

The quotation doesn't answer the question. In the default configuration, dir/w doesn't run the program w, so / is not acting as a path separator. Also, your quotation is from this Wikipedia article, not the author of that article. – wizzwizz4 Jan 27 '24 at 17:11
1

@wizzwizz4 this question only asks about the character used for path separator, so this answer does address the question that was asked. As you point out, making real-world use of file paths is also entangled with the command-line option delimiter character, so a useful answer is more complex than the question that was asked. Still, per the question that was asked, the support of / as file path separator has its earliest origin in MS DOS / PC DOS v2.x, which pre-dates Windows. – Sotto Voce Jan 27 '24 at 22:16
1

@SottoVoce But the question asks about Windows - after all, DOS supporting it doesn't automatically mean Windows would DOS let do so :) – Raffzahn Jan 28 '24 at 01:29
"so Windows APIs have always accepted forward slash" I fail to see any reasoning why this has to be true. Windows maintains it's own set of file access functions, to be called by windows applications. Those may or may not restrict usage to either form of separator - unless its guaranteed to be only forwarding. Is there any source suggesting that guarantee? – Raffzahn Jan 28 '24 at 22:24
@Raffzahn I have linked to some contemporary evidence that suggests the Win16 openfile() was intended to handle forward slashes in paths. The fact it fails suggests that it does it's own processing. – Mark Williams Jan 29 '24 at 21:28
2

@MarkWilliams I fail to see any evidence in the linked/copied parts about Windows explicitly handling both. The bug report is as well not conclusive. – Raffzahn Jan 29 '24 at 22:00
One thing you haven't mentioned is that in MS-DOS 2.0 there was a switchchar option in config.sys. You could change the switchchar to something else such as - and then / would work as a path separator in command.com. I remember trying it in MS-DOS 3.22. My recollection is that it generally worked, but that some programs did not respect the change and continued to use / as the switchchar. – David42 Jan 30 '24 at 14:17
@david42 yes I put that in previously, but took it out again. It was removed after Dos 3, so was less relevant to Windows. – Mark Williams Jan 30 '24 at 18:15
2

@David42 Yes, there was an option in CONFIG.SYS called "SWITCHAR" where you could set the "switch" character to something other than "/", such as "-". This was only in DOS 2.0 and was later removed. I remember trying it because I had come to DOS from the Unix world, so I would try to set it to "-" and could use "DIR -P". This worked generally in COMMAND.COM but the problem was that many third party programs did not make the DOS function call 3700H to get the switch character when writing their own command line parsing code and assumed "/". So it was hit or miss and not worth it. – mannaggia Jan 31 '24 at 12:29
@mannaggia Yes, exactly. In MS-DOS 3.22 you could still set the switch character with a DOS function call (3701H I think). It worked about as well for me as for you. I have the vague idea that the DOS call to set the switch character may have been nooped in a later version, but I am not sure. – David42 Feb 12 '24 at 16:45

Since when does Windows support forward slash as path separator?

3 Answers3

TL;DR: Windows did not explicitly support both, but DOS did since 2.0

The Long Read

Many Years Later (Win10)

Conclusion: It Does, But it's Incoherent.