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?

  • 13
    Unfortunately, the forward slash does not work always. :-( I yet have to find the pattern. Commented Jan 27 at 16:36
  • 4
    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
    Commented Jan 27 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
    Commented Jan 27 at 17:22
  • 1
    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. Commented Jan 27 at 18:32
  • 1

3 Answers 3


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

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:

Notepad having opened the file using forward slashes and showing the path including forward slashes 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

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:

Opening the test-file using back slashes

Now with back slashes

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

Opened test-file now without the path name

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:

Once Again:)

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

  • 4
    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
    Commented Jan 28 at 11:38
  • Some pathnames, particularly those with spaces, need to be quoted to support forward slashes.
    – Davislor
    Commented Jan 28 at 18:11
  • 3
    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
    Commented Jan 29 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
    Commented Jan 30 at 2:47
  • 1
    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
    Commented Jan 31 at 16:45

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

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

  • 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
    Commented Jan 28 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
    Commented Jan 28 at 20:40

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.

  • 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
    Commented Jan 27 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
    Commented Jan 27 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
    Commented Jan 28 at 1:29
  • 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
    Commented Jan 29 at 22:00
  • 3
    @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
    Commented Jan 31 at 12:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .