Why does Windows use backslash as path separator? (2019)

https://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/

by lproven • 2 years ago

72 148 2 years ago

mholt2• 2 years ago

I would just like to take this opportunity to complain about Windows file paths and especially parsing them in cross-platform software like a web server that joins request paths that always use / to Windows filepath roots that may or may not use \. I also hate that Windows paths are limited to 260 characters !?

Seriously, in Caddy, I have some of the most bizarre special code paths for Windows. For example: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

Can someone who understands and appreciates the way Windows does files please help me appreciate it too?

This article did not help me have gratitude for Windows: https://www.fileside.app/blog/2023-03-17_windows-file-paths/

we realise that we can construct an almost unlimited number of different path strings that all refer to the same directory.

hgyjnbdet• 2 years ago

I also hate that Windows paths are limited to 260 characters !?

Easily changed in the registry/ with group policy, though 256 should not be the default today.

mkoubaa• 2 years ago

Can you assume your users do that?

jonathanlydall2• 2 years ago

Was going to say the situation with path lengths on Windows is mostly gone today, but it does still pop up on the odd occasion.

For example the built in .zip file support can’t extract long paths (7-zip however has no issue).

Also my Git client of choice (TortoiseGit) doesn’t fully handle long paths.

But day to day long paths on Windows is fortunately not really an issue any more and they’ve been steadily improving support over the years.

Despite generally being a fan of Windows, before Windows 10 the long path situation was infuriating, they even had a blog post acknowledging it’s a problem, but also stating it was going to be very non trivial to fix and as such they didn’t have any particular plans to fix it.

I suspect that WSL made the limitation more regularly painful enough that they could convince managers that it’s something that had to get fixed.

Windows Terminal was probably also motivated by WSL.

nullindividual5• 2 years ago

MAX_PATH used to be 260 characters but was changed fairly early in Windows 10 life to 32k.

NTFS has always supported 32k characters in the path with each part being no more than 255 characters.

Office, OTOH, does not respect/observe MAX_PATH. Do not exceed ~240 characters in the path + filename for an Office document as Office will be unable to open it.

alkonaut2• 2 years ago

Coding with file system paths means accepting just a few difficult facts.

- a path is not a unique identifier of a file system object. They don’t have canonical names.

- don’t make any assumptions about case sensitivity, what file names are valid, or what the longest possible path is.

- avoid baking paths from strings as as much as possible. Use constructs like PathBuf (Rust) that prevent footguns like duplicated or incorrect dir separators. Never use a literal path separator char ‘/‘ or ‘\’ in code is a good rule of thumb.

agumonkey• 2 years ago

I remember one article about someone porting code from *nix to windows and having almost no issue due to the author leveraging pathlib. Just a side note.

candiddevmike• 2 years ago

Personally, I don't see the value in building server/tooling software for Windows these days. The market share just isn't there, and it ends up requiring a lot of work and testing to maintain.

Dalewyn2• 2 years ago

I would peruse such software.

I can rely on Windows to still be running nice and happy a year later with no attention paid.

I can rely on Linux to die to a stiff breeze.

(Note: I'm probably cursed.)

Atomskun• 2 years ago

How in the world is your rant in linked file supposed to work?

* It seems you decide whether to execute a file by its extension, e.g. `.php`

* You are complaining that Windows is stripping away spaces, so `.php ` becomes `.php`

* And supposedly this could lead the file being served as static text if you didn't have a Windows workaround?

It rather seems to me that POSIX accepting `.php ` as a filename, and this not being picked up by a `.php` check is problematic here.

mholt2• 2 years ago

No, look at the associated unit test: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

If that test fails we could serve PHP source code instead of having it be evaluated, a potential security flaw.

tredre32• 2 years ago

The high level Win32 API does this to be helpful because a trailing space is usually not what the user wants. You can argue it's stupid if you want, but the OS supports files that end with dots and spaces just fine if you call the right APIs.

I guess Go hooks into too high level of an API. But you can prefix all your paths with "\\?\" to "force it" to be evaluated as is.

Consider the following program:

    package main
    import "os"
    func main() {
       os.Mkdir(os.Args[1], 0777)
    }

Invoking test.exe c:\test... will create c:\test Invoking test.exe \\?\c:\test... will create c:\test...

See: https://learn.microsoft.com/en-ca/windows/win32/fileio/namin...

The link also explains why the file path length limit and details how to disable the limit.

NayamAmarshe4• 2 years ago

Windows has caused us a lot of issues with Upscayl (https://upscayl.org).

I personally do not use Windows but most of our errors are reported by Windows users where sometimes path parsing is a problem or the drivers mess up vulkan configuration.

The fact that node takes a different approach to windows paths and sometimes the need to store these paths in storage and re-use them in external spawned processes makes it difficult to work with Windows' different and not so ideal path standards.

harles• 2 years ago

Windows has caused us a lot of issues with Upscayl

I’d turn that around. Sounds like Upscayl has caused a lot of issues for Windows users. Not developing on and doing little testing on Windows sure sounds like the problem to me.

indymike• 2 years ago

First, I love Upscayl. Just used it to make about a decade of early lower resolution digital family photos 90s and early 00s printable and beautiful on HDPI screens. It's fantastic software.

Not developing on and doing little testing on Windows sure sounds like the problem to me.

Most open source developers are not going to switch to "developing on" Windows because of posts like this. Nor should they. Upscayl is on GitHub and would probably appreciate some testing and fixing on Windows.

As a developer, I don't use Windows at all. When I make cross platform software, dealing with MS-DOS anachronisms isn't interesting or fun. For paid work, yeah, OK I'll do it. But for free stuff, I can see where a developer might not want to put a lot of effort there and focus on the interesting part of their project.

NayamAmarshe4• 2 years ago

I'm just saying how Windows increases the development time compared to Linux and Mac when using technologies that utilize Mac/Linux standards.

Being a cross platform application, Windows gets the same stack but is the cause of more unnecessary issues.

It is true that we don't have enough testing for Windows but that's because I do not have a Windows machine and Upscayl won't work in a VM so I have to rely on community feedback most of the time.

jonathanlydall2• 2 years ago

Our desktop product built using Electron and .NET runs cross platform.

Originally it was on Windows only and I personally did the work required to make it work cross platform once .NET Core became mature enough, so I’m very familiar with the path separator challenges.

It was a bit of a pain, but not a huge deal. The trick was to just use forward slashes all the time, except for display or storing an absolute path.

Windows doesn’t seem to care when you use forward slashes for everything even if looks wrong.

Admittedly the Node code dealing with paths is limited as most of the heavy work in our app is done in a .NET background agent, but there are things like file selection dialogues and config loading that is in the Node part.

Based on the fact I can’t remember exactly what I did for paths in Node leads me to believe it was pretty much a non-issue, I probably used forward slashes and it just worked.

It took a lot more work for the .NET aspect where we’re doing a lot more stuff on the file system, I had to find and replace most path usages with a utility function to convert the separators appropriately.

lm411• 2 years ago

I'd never heard of Upscayl before. Very impressed!

Works great on my Mac.

NayamAmarshe4• 2 years ago

Thank you! Glad you like it :D

alkonaut2• 2 years ago

The path separator needed to be a key that does not require Shift to type

Give these people a Nordic keyboard (it’s Alt+Gr plus one of the keys that is hardest to press while holding Alt+Gr).

glandium3• 2 years ago

It's AltGr+8 on French keyboards. I think the backslash is not available without modifiers on most keyboard layouts, but US-centrism in decision making was strong back then.

Joe_Cool5• 2 years ago

I switched to EURKey since I figured I type code more than emails in languages that use umlauts or accents. It takes some getting used to (even more when coming from AZERTY) but it makes me so much more productive. No more cursing at CTRL+] hotkeys.

It's included in most Linuxes and KDE and the homepage has a download for Windows and Mac as well as a nice keymap: https://eurkey.steffen.bruentjen.eu/

euroderf• 2 years ago

On Scando Mac it's Shift-Option-7. Gives new meaning to "three-fingered salute".

garciansmith• 2 years ago

I don't understand the last bit about the Model F Keyboard playing a role. Neither the slash nor backslash keys require shift to be pressed. Unless they just mean that the slash already had another role and therefore the only other free key was the backtick?

jtotheh4• 2 years ago

I've seen some discussion of this, I believe that DOS got some ideas from a DEC OS (not VMS) that they were familiar with from using PDP-10s. Or something like that. Also, they had started using forward slashes to signify options to commands. Although I was a card-carrying Linux stan and Windows hater, starting with NT they have done a good job, overall. M$ makes backward compatibility a priority, and thus will not dump bad ideas that have become entrenched. I do think Jobs was right that M$ has "no taste". I am helping teach Intro to CS to HS students (ironically, through a M$ program) and even the teacher did not know why the C: drive is the letter that it is. AFAICT we're all condemned to live with choices made in a cheap clone of CP/M.... Of course other technologies have their bad choices as well (UNIX/C null-terminated strings, maybe, for instance?)

bena• 2 years ago

It's C: because A: and B: were already taken by your main drives, your floppy disks.

jtotheh4• 2 years ago

I know, but when did you last see a floppy disk?

doublepg23• 2 years ago

I’d be all for a GoboLinux revolution but it seems unlikely from a “if it ain’t broke…” POV.

pixelesque• 2 years ago

The article mentions your first few sentences...

In the early DOS days, you didn't always have hard drives, but you'd always have floppy disks to boot from, and those letters were used first alphabetically.

lproven8• 2 years ago

I've seen some discussion of this

Look, this is not a personal attack, but the reason I posted the link was that it answers the question... and your comment seems to indicate you didn't read it before commenting.

So why comment at all then?

And did you not think "hey, if I comment without reading and immediately indulge in speculation I will make it plain to everyone that I didn't read it and I am just guessing"?

ape4• 2 years ago

One of the many problems is the need to escape it in C/C++ code - like

    LPSTR path = "C:\\Program Files";

They really should fix it. Better late than never.

Tempest1981• 2 years ago

Or use C++ raw string literals and experience inner peace:

https://www.geeksforgeeks.org/raw-string-literal-c/

TillE2• 2 years ago

Or use fs::path with the / operator. If you're doing anything with file paths in C++, that class is a godsend.

https://en.cppreference.com/w/cpp/filesystem/path

PaulHoule2• 2 years ago

It's a little known fact that most of Windows works just fine with "/" as a path separator, for instance if you make a system call to open a file or something.

The major system that won't accept this is cmd.exe so if you are passing parameters to a .bat file that has a filename with a "/" in you will have trouble.

coldpie3• 2 years ago

Yep. Drives me nuts when I see people fiddling with platform-specific path separators. Just use /, it works everywhere.

PaulHoule2• 2 years ago

I am really in the habit of using pathlib in Python and similar facilities in Java so I just write

  path = HOME / "cards" / f"{card_id}" / "card.yaml"

Zamicol• 2 years ago

It's been years since I've had to work on a Windows system, but I'm suspicious of that. Days of my career at the State of Colorado has been spent fixing / problems. Is this something on newer Windows systems?

RedlineTriad• 2 years ago

This sadly isn't quite the case as this post demonstrates[0]

- The path is limited to MAX_PATH (260 chars)
- Unless you prefix the path with \\?\
- However using \\?\ disables automatic conversion of / to \ in the path (and some other normalization)

See previous discussion[1]

[0] https://mastodon.gamedev.place/@AshleyGullen/111109299141510...

[1] https://news.ycombinator.com/item?id=37632232

simonblack• 2 years ago

Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M

     FORMAT C: /S /U

The option-indicator in UNIX-like systems was the dash/hyphen '-'

     ls -al

Joe_Cool5• 2 years ago

thats why it also works without any spaces

  DIR C:/p/s/w

Doesn't do what you might expect.

glandium3• 2 years ago

And the article points out it's NOT a carry-over from CP/M.

dirkt• 2 years ago

And I am not sure if their argument holds water. CP/M is clearly influenced by DEC usage [1], and various DEC OS and tools had slashes for tool options as a standard. Those then got carried over to CP/M (e.g. PIP), so that was the standard way to define options everyone CP/M used would have known.

It's really really hard to imagine the usage for slashes as arguments was not a carry over. And for anyone old enough to actually remember the transition from CP/M to MS-DOS (like me), it felt very natural.

[1] https://en.wikipedia.org/wiki/CP/M

skissane5• 2 years ago

Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M

It wasn't a carry-over from CP/M itself. The utilities shipped with CP/M itself didn't use slash as an option character. PIP put options in square brackets.

It was a carry-over from Microsoft's programming tools for CP/M. And, as the article points out, Microsoft appears to have borrowed that syntax from DEC TOPS-10, where it originated

lproven8• 2 years ago

[Article submitter here]

a carry-over from CP/M

No, it wasn't, and I posted this correcting someone else on HN sharing this disinformation.

CP/M does not have command switches as standard. There is no standard separator because it didn't support switches. (Some programs did on their own.)

Didn't you RTFA before posting this -- gods, I hate the term -- fake news?

zabzonk2• 2 years ago

“CP/M got the slash from VMS”, which is simply not possible because CP/M is older than VMS

surely not - i used cp/m 1.x back in the late 1970s and by that time VMS was a well-developed and sophisticated OS, unlike cp/m which was something you could have knocked up in a week or so.

InfamousRece• 2 years ago

CP/M was released in 1974 while VMS was around 1977.

zabzonk2• 2 years ago

you are right. still, i don't think cp/m was used so much until the very late 70s, simply because microcomputers were not used so much until then. and at that time vms was far more powerful. i remember the first time i used vms compared with cp/m on a z80 - no contest.

atombender• 2 years ago

According to Wikipedia, CP/M was released in 1974, and VAX/VMS was "announced" in 1977 (presumably means it was available a bit later than that).

ewgoforth• 2 years ago

I always thought DOS got the backslash from VAX/VMS, a question which this article seems to avoid asking.

Alupis10• 2 years ago

I find these sort of articles so very tiring...

I realize this is from the OS/2 Museum and not Microsoft - but the result is the same:

Article written about a poor engineering decision made decades ago, which for reasons that perplex everyone still live-on today. Then the Microsoft apologists come out of the woodwork to explain how easy it is to live with these poor engineering decisions and how smart Microsoft Engineers are, and how it's literally all other operating systems that somehow are lacking, blah blah blah.

Backwards compatibility is usually the smoke screen apologists deploy during these discussions. As-if in the past few decades Microsoft couldn't have written a simple '\' -> '/' converter... Hell, if you look in the Explorer address bar, Microsoft even hides the path separator - opting to replace it with arrows instead.

Let's not even start on the CRLF thing...

Yes, Windows owes it's origin to OS/2, and OS/2 used '\' instead of '/' - so we should never correct a decision inherited from an OS that died 22 years ago...

asveikau10• 2 years ago

With respect, what the hell are you talking about?

Win32 file APIs can actually use either '/' or '\\' as a path separator. The stuff this is talking about is mostly around DOS command line tools and the successor, cmd.exe, which yes is mostly meant to run scripts written for DOS.

'\\' was selected by DOS, specifically DOS 2.0 per TFA, several years before OS/2 existed.

Alupis10• 2 years ago

When you open Explorer and click in the address bar - what path separator is displayed? How about when you install software - what path separator does it show?

Win32 file APIs can actually use either '/' or '\\' as a path separator.

Fantastic - so why are we still entertaining this idiotic file separator everywhere within the OS itself?

'\\' was selected by DOS, specifically DOS 2.0 per TFA, before OS/2 existed

Fine - so why the hell are we still doing things like a dead, defunct OS did and literally nobody else did because, you know, it was unintelligent?

itslennysfault• 2 years ago

As a long time *nix user who briefly worked at Microsoft (and therefore on Windows), I was very happy to learn that Powershell is perfectly happy with forward slashes in paths. If you tab-complete it switches them to backslashes (which is "fine"), but you can type commands using forward slashes without issue. Also common linux commands (ls, cd, mv, cp) all work in Powershell. It really makes the transition painless.

Alupis10• 2 years ago

I personally have found PowerShell to be obnoxious. It doesn't seem to know what it's supposed to be and tries to be everything all at once. The syntax for commands is super "Microsofty" if you know what I mean.

I get around by using Git Bash (which is actually quite good for being a bundled afterthought), cygwin, or lately even WSL containers.

Nihilartikel• 2 years ago

I work a lot in powershell, and I want to like it. It is built around good ideas.. but oof, every time I have to special case on a return value being either a list or a single item depending on the result-len==1 or not, I die a little inside.

naikrovek6• 2 years ago

Windows itself is fine with forward slashes as a path separator, as well, though LOTS of userland Windows applications weren’t aware of this and enforced backslashes themselves.

Command lines, graphical shells, OS save and open file dialogs do not care if you use slash or backslash, and the Win32 API has never enforced backslashes as a path separator.

wglb3• 2 years ago

This is also true if you e.g. write a C program to create a file whose pathname contains a slash. This is deep within the OS, likely due to posix compatibility

mardifoufs• 2 years ago

Why is / better than \ ?

OsrsNeedsf2P• 2 years ago

Apart from the fact \ is used as an escape sequence?

Alupis10• 2 years ago

For starters, `\` is used for escape sequences for just about everything... meaning you now have to do the `\\` dance everywhere you need to write this path separator.

Yes, it's true modern languages have things like `Path.separator` and stuff to abstract this away, but you cannot always use them in all contexts.

It's small friction that adds up to a sore bum after a while...

dekhn4• 2 years ago

I use forward and backward slash on Windows all the time. I think it's less of a problem of spaces in filenames, which makes a lot of pipe-related stuff harder to do (see find -print0 and xargs -0).

asveikau10• 2 years ago

Spaces in filenames in the command line on Windows is a horror in part because there is no kernel level equivalent of argv. In the eyes of the Windows kernel, the command line is an unparsed utf-16 string, and it's up to the application or C library to tokenize it. This means there is no standard way to tokenize it. Ultimately, this means there is no standard way to escape a shell command's arguments, as you would need to do for spaces. Most people just put it in double quotes but this is pretty much the honor system.

canucker2016• 2 years ago

Windows used many of the MSDOS services, like file system access. Windows was built on top of MSDOS in the beginning.

Windows predates OS/2 (OS/2 development started in 1985 according to Wikipedia)

How is it a poor engineering decision?

What about the original Mac OS using colon as a path separator? Or Lisa OS using the hyphen as a path separator?

see https://retrocomputing.stackexchange.com/questions/17069/why...

TillE2• 2 years ago

Yeah I think it's far more interesting to view this as a series of people making probably the best possible decision at the time, and winding up in a slightly unfortunate, suboptimal place.

That's hardly uncommon! Examine the history of basically anything.

naikrovek6• 2 years ago

Microsoft reportedly wanted to use the forward slash as path separator, but IBM nixed the idea because it would have created an incompatibility with DOS 1.x, which already used the forward slash as a switch character, separating command options.

It isn’t a poor engineering decision, that guy just didn’t read the decision criteria.

Also, according to spec, CRLF is the proper sequence for a newline, and both Unix and MacOS chose incorrectly.

Joe_Cool5• 2 years ago

Japanese DOS had ¥ as the path separator or more specific at 0x5C. It still causes headache with the MS Mincho font. Japanese users are used to seeing ¥ at the DOS prompt so some Windows Console fonts just replace the backslash.

Since you never know if it's a backslash or an actual Yen sign. Total fun.

naikrovek6• 2 years ago

Windows existed before OS/2, though, and MS-DOS (where Windows’ path separator comes from) is of course even older.

It’s ok to hate Microsoft, but hate them based on facts, and not whatever nonsense you have in mind.

tracker13• 2 years ago

If you're using anything resembling modern Windows, you can use forward slashes for path separators and it works fine pretty much everywhere.

skissane5• 2 years ago

Let's not even start on the CRLF thing...

CRLF is actually the Internet standard. It wasn't something Microsoft came up with, it was something they inherited from DEC

Yes, Windows owes it's origin to OS/2, and OS/2 used '\' instead of '/' - so we should never correct a decision inherited from an OS that died 22 years ago...

That's not what the article actually says though. DOS 2.0 decided on '\' instead of '/', and both OS/2 and Windows inherited that decision from DOS.

dunham• 2 years ago

The MSDOS 2.0 source code blames IBM:

Most of these are due to last minute changes to achieve a greater degree of compatibility with IBM's implementation of MS-DOS (PC DOS). This includes the use of "\" instead of "/" as the path separator, and "/" instead of "-" as the switch character.

https://github.com/microsoft/MS-DOS/blob/80ab2fddfdf30f09f0a...

jtotheh4• 2 years ago

MS-DOS didn't exist prior to PC-DOS, initially. "IBM's implementation of MS-DOS (PC DOS)" was the gold standard.

all of it came from QDOS, a CP/M-like OS M$ bought based on hiding their plans, and that IBM made PC-DOS from. PC-DOS shipped with the original IBM PC.

MS-DOS only became a thing once there were "IBM PC compatible" clones. It was very smart of M$ to see that coming. They kind of rode IBM's coattails into dominance in the market. Back then, personal computers were oddities and when IBM entered the game, their reputation gave them credibility.

skissane5• 2 years ago

all of it came from QDOS

I don't think 86-DOS (aka QDOS) itself had slash-based options. At least, in a quick skim of the 86-DOS 0.3 user manual I couldn't see any. [0]

But they were there in PC-DOS 1.0, which suggests Microsoft added them after licensing 86-DOS.

[0] https://web.archive.org/web/20160409042609/http://www.paters...

Why does Windows use backslash as path separator? (2019)

Related Stories