The sad thing is Microsoft never wanted the backslash. It's all IBM's fault.
DOS 1.0 had no subdirectories. There was no slash: you didn't type A:\FOO.TXT, you typed A:FOO.TXT, and the prompt wasn't A:\>, but rather A>. Incidentally, this still works today, and sometimes DOS boots with a A> prompt.
In DOS 2.0, Microsoft decided to add UNIX-style directories, with . and .. for navigation, / as the separator, cd to change directory and so on. But there was a problem.
DOS 1.0 had used / for flags (e.g. DIR /W). Microsoft's solution to this was to switch to - for flags, but IBM didn't like this change. So Microsoft compromised on using \ as the directory separator and kept / in use for flags.
However, Microsoft clearly didn't like having to make this change. How do we know this? Well, DOS nonetheless also supported / for directories (and thus its successors, including Windows NT do), and, at least for a little while, contained a setting which let you use - as the flag character.
I used VMS for a while (I never became a power user), and it always felt really weird to me. But I'm not sure if it actually IS weird, or if it just seemed that way because I was already so familiar with Unix. On the one hand, directory separation characters are kind of arbitrary. But my brain insists that "/" is more natural than . (or ":" on MacOS).
Well VMS also had this nonsense for fully qualified paths, NODE"accountname password"::device:[directory.subdirectory]filename.type;ver everything except filename.type is optional based on the users current DEFAULT (pwd in unix parlance). And required extensions and used the "." separator making it overloaded and confusing to read at a glance.
MS didn't use / for directory separators before. They wanted to in DOS 2.0, but that would mean they had to change / in front of options to something else. So to keep backwards compatibility they used \ instead. It's true that they were ok with breaking that backwards compatibility, but IBM convinced them not to
So the thing is, low-level Windows APIs (such as CreateFile) have supported forward slashes for a long time. And since libc/posix-ish stuff like fopen() is implemented with that API on Windows, nearly all programming languages are magically forward/backslash agnostic on Windows. As a programmer, this means that in places where it really matters, you're usually just fine with forward slashes.
Many UIs get confused on forward slashes though (file open dialog, stuff like that), and given that the vast majority of people, worldwide, that understand what files and directories are, believe backslashes are the way to go, I doubt MS is ever going to change this.
But from personal experience - I've programmed cross-platform stuff on Windows for very many years, and I never bothered about backslashes. In all honesty I never understood all the open source stuff that comes with DIRECTORY_SEPARATOR global constants or eslint rules that tell you to use path.join() instead of `dir + "/" + subdir`. The forward slash just works, and it has worked for ages.
The only "problem" is that at times you end up concatenating paths together and end up with stuff like
C:\Temp/mydir/2/..\file.txt
That's a bit quirky in log file and in the debugger. But fopen eats it just fine.
Sure there might be cases where this is a problem, probably the libraries I've seen code around backslashes have good reasons, but really for end-programmers it's no biggie.
Now, MAX_PATH, that's something else. That should die in a fire and it blows my mind that it hasn't been addressed yet.
> the vast majority of people [..] believe backslashes are the way to go
Not sure you got that right. I'm certain there are more people that use forward slashed in a browser (every OS+mobile) than people who type backslashes in Windows.
My mother has used Windows for years and doesn't even know where the backslash character is. She can type URLs though.
I've seen URLs printed on paper, posted on signs, and even printed on the side of napkin dispensers, that use backslashes instead of forward slashes. For a long time, the automated message on my university's services number (admissions, etc) started off by spelling out a URL, complete with two mentions of "backslash".
The phone message error is different though, they mistakenly think '/' is named backslash. I've heard people say this in person multiple times and when I've had a chance I confirmed that when they said "backslash" they were referring to the '/' character.
I still hear "backslash" invoked in URLs once in a while, and it still bugs me to no end. It's 2016! You are a radio announcer! You should know how to pronounce URLs by now! So frustrating.
Do you have a source on "vast majority of people ... believe backslashes are the way to go"?
And if you do, do you have a source on why?
Also, yeah, can anyone clarify what the deal with the max path length is? And why it's possible to create a path above the max length but not to simply delete it from the filesystem?
And how many of those 1B+ Windows users were present at the vote on backslash vs. forward slash?
Honestly, 99.99999999% of people use one or the other because that was what the platform they are on used. Very few people were involved in the back vs. forward slash decision.
A lot of users open Explorer and looks at the path or copies the path. Nowdays the path is shown with arrows instead of slashes but when you klick on it to edit or copy it will use backslashes. This means a lot of users might have seen them and used them. Even 10% of 1B users is till 100 million users.
Another problem is all Windows applications that don't handle forward slashes well. To make minimal inpact on the users all those applications would have to be updated. That will probably never happen.
Most windows users who know how the filesystem hierarchy works probably never see a file path. Windows explorer doesn't show the slashes, it shows some kind of graphical blocks by default. They do see slashes in their web browser though. Maybe they never look at those, but when they print a webpage, they see the url obnoxiously present at the bottom of the page.
I first encountered this issue when helping new developers get started with NPM on Windows; older NPM versions produced deeply-nested node_modules trees that could easily overflow the limit.
I keep running into Windows code from Microsoft that still doesn't work with /. It'll probably be there forever.
The code I write is regularly ported between OSX, Linux, and Windows, and I routinely make it work with both, as well as being agnostic about line endings.
The opposite problem, Linux programs not working well with CRLF, is there as well. I find git to be more or less unusable with CRLF source files, so I run a 'tolf' utility on all checkins. Linux programs ported to Windows tend to run poorly, like being case sensitive on filenames in some places but not in others.
I knew I could get away with using forward slashes in Perl and PowerShell, but I had assumed these were hacks in Perl and Powershell respectively, in order to make Unix-people feel slightly more at home.
> Now, MAX_PATH, that's something else. That should die in a fire and it blows my mind that it hasn't been addressed yet.
In a way, it has. AFAIK, internally Windows can handle paths that are far longer than MAX_PATH, but since so many applications have been written with the assumption that a path can never be longer than MAX_PATH, apparently Microsoft felt if somebody passed a longer path to an API function, that probably indicated some programming error, a buffer overflow or something like that.
But apparently, if you write a path like \\?\C:\Some\Really\Long\Path\With\Lots\Of\Nested\Subdirectories\And\A_Ridiculously_Long_Filename_In_It.RandomLongFileExtension then the path can be fairly long. I think there still is a limit of something like 64KB, but that should, as they say, be enough for anyone. ;-)
Still, I agree, MAX_PATH and network shares have given me a lot of pain - if you have have file server with a folder like D:\Network_Shares\Accounting that is mapped to, say, the drive E: on some client, the client can create files whose local path on the server will exceed MAX_PATH, causing e.g. backup software to choke.
And this happens quite a bit, because our project engineers store project-related files in an elaborate, very deep folder hierarchy; I appreciate they want to organize their files, but sometimes I just want to slap them.
DIRECTORY_SEPARATOR might just as well exist because of Mac OS which used : as path separator. With the transition to OS X and the Unix filesystem layer above HFS that morphed into /, but in the filesystem it's still : afaik.
Isn't there an issue with starting subprocesses on windows if using one slash or the other? I seem to remember this as a problem many years ago but I might be wrong
CR LF is the Internet standard, however. TELNET, SMTP, FTP, and most significantly HTTP/1.1 all specify CRLF is to be used as the line terminator (not LF). Many popular implementations will accept a bare LF as well, but messages containing a bare LF are strictly not standards conforming.
Given this is fixed in RFCs, it is unlikely to ever change
This is not why Windows uses CRLF, nor is it some original reason that is now obsolete. It was standard for both DOS' predecessors and early internet standards because teletypes considered carriage return and linefeed separate commands, and both were built to operate with those things.
None of that stopped UNIX from getting away from it, and the internet is basically built on UNIX. What transformations the C FILE stream implementation makes to linefeeds has nothing at all to do with TELNET, SMTP, FTP, or HTTP. These are very separate areas of concern. In Windows if you're writing socket code you have to explicitly write the \r and the \n, just like on any other platform.
"the internet is basically built on UNIX" is an odd thing to say. In the early days of the Internet (early 1980s, 1970s if we want to include ARPANET as the current TCP/IP-based Internet's predecessor), it was a very diverse place, with lots of DEC operating systems (TOPS-20, VMS), IBM mainframes, and various other mainframe and minicomputer vendors, with Unix by no means predominating. The Unix monoculture (and later Unix/Windows biculture) grew through the 1980s and was well-established by the 1990s. Major protocols such as IP, TCP, UDP, TELNET, FTP and SMTP were all developed prior to that Unix monoculture taking hold. FTP in particular shows the pre-Unix heritage very clearly, with support for record-oriented filesystems (STRU R, MODE B, MODE C) for DEC and IBM operating systems, support for systems that don't use 8-bit bytes (e.g. TYPE L36), built-in ASCII-EBCDIC translation (TYPE A and TYPE E), support for ASA carriage control (TYPE A C and TYPE E C), and support for TOPS-20 paged files (STRU P). (These are all features pretty meaningless on Unix systems, which is why Unix FTP clients and servers largely do not implement them.)
Feel free to insert "as we know it", because I do not believe that the pre-1980s internet is recognizably the same thing. I will not strongly argue the point since I wasn't there.
But to clarify on the salient part, I was trying to say that UNIX diverged (successfully) from what came before it, and the CRLF behaviour was from the teletype era that the early internet started in. My point about UNIX being a building block of the (modern) internet was more about pointing out that if UNIX could diverge from that and be a key component of the internet, it's absurd to think that Windows could not.
I can definitely understand how you got where you did from what I said, though.
But the internet as we know it grew out of the BBN networking code that was added to BSD 4. Prior to that, the patchwork connection between machines was via UUCP, mostly.
The current TCP/IP Internet began on flag day, 1 January 1983, when ARPANET switched from the old NCP protocol suite to TCP/IP. That was the point at which TCP/IP first entered production use. 4.2BSD was released in August 1983, which was the first production BSD version to include BBN's TCP/IP stack. 4.1a BSD was a pre-release integrating BBN's TCP/IP stack, in 1982. But that was just what was happening in Unix land; other folks at the same time were working on TCP/IP stacks for non-Unix operating systems. In particular, I understand that BBN's TCP/IP stack actually started life on TOPS-20 and was ported to BSD from there. TCP/IP began on non-Unix platforms and was only later ported to Unix.
There is a talk by Kirk McKusick on YouTube[1] where he tells about that time, and IIRC, Bill Joy got his hands on an early version of BBN's code, started hacking on it and put it into BSD. BBN and DARPA were not very amused, but by the time BBN's stack was finished, the BSD version had better performance and/or lower packet loss, so it stuck.
Apparently Mike Muuss compared the two implementations, and his recommendation to go with Bill Joy's code was the decisive factor.
CRLF comes from DEC operating systems. DOS was inspired by CP/M which was inspired by DEC operating system conventions. (CP/M operates remarkably like RT-11. DIR, COPY, etc., all come from DEC.)
CRLF is a security hole. I've actually seen this happen. Proxy interprets line ending one way, like CR CRLF as CRLF CRLF and ignores body. Server sees CRCRLF and treats it as CRLF, reads proxy-ignored bits as headers. "Oops."
Though this is more of an artifact of terrible specs and the IETF's silly love affair with "free" text formats. They actually take delight in showing off how crazy the encoding can be.
I recently had to deal with this for writing a file format that mandates CR LF line endings regardless of platform. Thankfully, Python 3 makes it painless to deal with, once you track down how. For anyone who's been spared so far:
While we're at it, we can kill that double-byte UCS-2 nonsense that microsoft retconned to be UTF-16.
Microsoft must have thought to themselves in the early 90's: "Gee, we should support unicode... that means we need wider characters, right? Two bytes ought to be enough. Ship it!" Then when it became clear that two bytes wasn't enough, they didn't want to replace all the types for those win32 API calls, so they said "Well, let's just pretend that the two-byte encoding was actually UTF-16 all along", which is both variable width (which has all the problems UTF-8 has with invalid encodings), and it's wasteful in size (all ASCII text is stored with two bytes per character). It's literally the worst of both worlds.
> Microsoft must have thought to themselves in the early 90's: "Gee, we should support unicode... that means we need wider characters, right? Two bytes ought to be enough. Ship it!"
Except it was Unicode which was a 16-bit code back then which got changed into 21 bits with Unicode 2 which also morphed UCS-2 into UTF-16. This happened in 1996, when Windows NT already existed. Blaming Microsoft (and Sun, and Netscape, ...) to follow a standard is a bit out of place. Heck, while UTF-8 everywhere would be nice, things are still messy and various different encodings are rampant. At least UTF-16 is immediately recognisable, as opposed to all the legacy encodings.
I suppose that's right. It's really the Unicode 1.0 standard itself that's to blame here, but the point still stands. It took them between 1.0 and 2.0 to actually include any implementation guidelines, but by then it was too late; the Microsofts and Suns of the world have already implemented a dead-end way of encoding the standard.
But at least in Unicode 2.0 in 1996, the definitions they finally gave were UTF-7 and UTF-8. UTF-16 didn't become standard until 3.0 in 1999, when it became apparent that they couldn't take the first 5 years back, and too much software was already written assuming 16-bit characters.
My point is that UTF-16 is a completely worst-of-both-worlds hack that nobody would implement in a vacuum, short of a need to maintain compatibility with a 2-byte character API. The only reason it exists is because people (the Consortium included) truly for a brief period thought a 2-byte character set would actually be enough, and then had to figure out a way to preserve compatibility later.
Meanwhile the UNIX world thankfully seems to have gone straight from ASCII to UTF-8 without any awkward dead-end in the middle [1], because if you need to maintain backward compatibility with anything, it's a lot more useful (and space efficient) for that something to be ASCII.
[1] Sure, there exists wide-character versions of all the posix standard APIs, but in practice all the other API's you're likely to use in UNIX land have converged around wrapping the 8-bit character versions.
Just be grateful that it's only CR LF and not CR LF RUBOUT.
That would really have been too much skeuomorphism in our text file format.
What is RUBOUT? It's a character with all 1 bits. On a paper tape, a punched hole represents 1 and lack of a punch is 0. So a RUBOUT character has all the holes punched out.
And by convention, RUBOUT is ignored when a tape is read.
If you made a mistake punching a tape, you would type BACKSPACE RUBOUT. BACKSPACE wasn't a character itself; it would physically back up the tape by one character position. RUBOUT then punched out all the holes, in effect erasing that character.
To go to the next line, you would punch RETURN to return the print carriage to the beginning of the line, and LINE FEED to feed the paper to the next line. But unless you were daring, you'd follow these with a RUBOUT to give the machine a little more time for all this mechanical movement.
Ya that I too agree with this, pretty much all applications can now deal with \n just fine. Having CR LF (2 Bytes) is not only wasting storage space but also wasting bandwidth when transmitting.
While at it, I also wish if Linux distros could get done with case sensitiveness in filenames. Is there any advantage to allowing both Filename.ext and filename.ext? The only time I seen this is when a malware is trying to stay hidden. Also some naming conventions would be nice, when you can have any character including '/' and '.' as a filename, it gets annoying to deal with them in a cli.
> Is there any advantage to allowing both Filename.ext and filename.ext?
Sorting by ascii order put capitalized files to the top of the list. Exactly where you should look for important stuff like README and Makefile.
Case preservation without case sensitivity is just dumb. Why bother, because it's pretty? Also, what's up with spaces in filenames? And furthermore, what are all these kids doing on my lawn?
> not only wasting storage space but also wasting bandwidth when transmitting
Such an utterly minuscule amount though (especially in the modern times when storage and bandwidth are cheap and ubiquitous), I think you typing that sentence has wasted more storage and bandwidth.
I think a better reason is to avoid issues when working with code files across systems and version control. This actually causes major annoyance.
And it's still minuscule, even added up, even a billion times over.
My point is that there's no shortage of digital storage space and bandwidth is only getting better. And if CRLF does cause a shortage of storage and bandwidth, I'm sure MS would address it.
It's not a Linux distro thing, all Linux, BSD, Solaris, etc systems are case sensitive because it's the 21st century.
The only widely used file system without case sensitivity is HFS[1]. NTFS to its credit is case sensitive, but Win32 is not, for legacy reasons (same reason as why MAX_PATH still plagues Windows).
And if you actually go out of your way to try and use the case sensitive HFS+ on a Mac, you have a pretty good chance of getting tripped up by user space software that doesn't like it, like Photoshop[1].
The BOM has to be one of the stupidest things they've done. Such a terrible idea. Yes, I know they wanted an easy way to detect encoding, but corrupting data is just beyond bad.
Except that U+FEFF is specified to be only used as byte-order indicator when appearing at the start of a text stream and does not belong to the text content. It does not corrupt data because it's not part of the data for any conforming application. Non-conforming applications doing wrong things because they don't bother to follow the standard is hardly surprising, then.
Yes, Unicode is messy and could have been better designed (it was designed so that there is an easy conversion path for any pre-existing encoding – thus concerned itself more with making it easy to convert content in legacy encodings to Unicode, instead of making it easy to implement applications in a way that they support Unicode), but it's still orders of magnitude better than anything that came before it when it comes to representing text in general. And it's mostly complicated because languages and scripts are complicated.
OK, then I cat two files together. Somehow thinking that one can unilaterally declare every application in the world as "non-conforming" is just sticking your head in the sand.
Well, the notion that text can be safely treated and manipulated as binary data and still make sense is what doesn't work here. It's the wrong tool for the job, then. That's kinda the same as reversing text byte by byte and complaining that all diacritics are wrong.
Yes, cat comes from simpler times, but if cat cannot be changed for compat reasons, then it should no longer be used to concatenate text files. At least if the result is somehow important. Text and binary data are simply two very different things and both need to be processed accordingly. Sure, there are a bunch of other operations that are immediately recognisable as not making sense on text at all and superficially concatenating files is not one of them, but in my eyes that's a bit shortsighted. You can safely use methods for binary data on text iff you know exactly what your text contains and that the operation is safe. Otherwise you may mangle things.
A terminal does (kind of) emulate a teletype. Certain formatting operations would be easier if a line feed character meant exactly “line feed”. Ditto vertical tab. I agree it doesn’t really belong in a storage encoding, though.
Forward slash has worked just fine on Windows for a LONG time. Backslash will probably still be around in the year 3,000 for backwards compatibility though.
I hate that reimplementing the open dialog is an acceptable practice on Windows. I have one dialog in Acrobat, another one in AutoCAD, another for AGI32, and (I think the standard one) in Chrome. Probably others that I'm forgetting.
Each of these has its own special list of "favorites" on the left, so if I want to add a shortcut to a commonly used folder, I find myself doing it in 8 different places. Or in some cases I can't; Acrobat has a sidebar with large icons of Recent Places, Desktop, Libraries, Computer, and Network. If you wanted to add somewhere more useful, you're shit out of luck.
Anyone know why this happened? Was there a period around Windows XP where the built in dialog was just godawful and everyone said "Fine I'll make my own" and then they never went away?
Compare to OS X where any time someone rolls their own dialogs for system features (especially Open and Print), I immediately assume the developer is an asshole. And for the most part, nobody does it. The only one I can think of off the top of my head is printing from Chrome, and theirs even includes a "Print using system dialog…" button.
It's been one of my many pet hates about Windows since first having to use it regularly, around NT or 2000. Windows isn't even consistent with itself over the look of things bringing elements of previous and future versions of Windows to your desktop.
To add to the sibling comments...
From MSDN "Windows continues to support the old-style Open dialog box for applications that want to maintain a user-interface consistent with the old-style user-interface"
No, no and thrice no. If I'm on Win 7, everything should look Win 7 consistent. Likewise if I'm on 10 it should all look 10, perhaps with necessarily reduced functionality if it's a deprecated call.
If I'm running Visual Studio on 7, I don't want all my icons, and GUI to be of 10. No matter how diligently you upgrade, there is always something visually out of step. Even with only MS software.
I suspect it was the very late arrival of a Windows Style Guide made a lot of developers get the habit of doing their own thing. Then they'll start faffing around with variations so you can have preview in open. Hell, might as well do our own everything. The rules didn't say you shouldn't.
Mac always had a pretty tight, and extensive, Style Guide with apparently thought down to individual pixels; Windows seemed not to care, or not understand when it did care. Around XP Windows started caring more about UX, but probably far too late.
Here's the real reason Windows didn't just switch every app over to the new style open/save dialogs automatically: a large number of apps hacked these dialogs to add extra controls to them. It was very common to see a file open/save dialog with some checkboxes or other options added at the bottom.
This was easy to do: after opening the dialog but before it was displayed, you just walked through its child windows to add your own controls where you wanted them, and increased the dialog height to make room.
But Windows didn't know you would be doing this until it was too late. The modifications were done after you called the Windows API to create the dialog.
If it weren't for this compatibility issue, Microsoft would have been delighted to just replace the old dialogs with the new ones wholesale.
More than a decade ago, MS used to kind of have that, and mostly consistent at the architecture level, but I think it was only by chance (win 3.1 programs still had all their legacy dialogs, including open file), because they just did not have had the time yet to implement 1000 different graphical frameworks for example, or to evolve dozens of ribbon interfaces from various unrelated teams. Now it is nothing else than an absolute mess: Win32 programs are very different from UWT stuff (and not just the drawing of the control, the whole interaction model is completely different), and you've also got layers of unrefreshed designs inherited from the guidelines (or informal practices) of the day of the version of windows the component was first introduced in, with inspiration flowing from other teams (or even other systems) but with no common technical framework continuously shared between them, so for example Office also has its very own stuff.
This is a big difference, and in the end a classical one, in the way companies typically work compared to open source projects (not just open source code, I'm really talking about the whole project being open): in companies teams or individuals just don't collaborate as much, because projects are often extremely closed even within the companies, with all kind of access rights. And also some app team might want to support really old OS (who uses a Linux distro of 2009 today? Well, OTOH tons of people are using a Windows version from 2009...) for a few more years and that OS certainly won't add any kind of support for the UI the app guys want, and the app guy might not want to use loads of resource to make their app look neatly graphically integrated in old OSes.
In summary, for proprietary stuff, this is an hard problem both at the technical and at the organizational level, especially if you like to change your graphic experience so often like MS does. And now everybody is used to seeing widely inconsistent stuff on the same screen anyway, so old on new / new on old / different on different cases will remain, I guess. Plus converging UI from vastly different devices is also a hard problem in itself, and UWP is actually not bad at it -- but the price is obviously that it must be irrecoverably different from old Win32 programs.
That's true, I'd forgotten. Win 2k was fairly consistent about things, and even XP had a fairly decent classic fallback mode.
I understand a lot of the baggage they're carrying for keeping compatibility and suffering 20 year old choices etc. I can't help but feel that 7 or 8 should have drawn a hard MacOS/OSX like line under things and given us a modern windows with newer choices. Add a VM for running your old XP app. Throw cmd and dos away entirely.
I actually respect MS for being brave enough to experiment with the GUI as much as they have, yes and get it terribly wrong sometimes. A classic fallback, or a 7 fallback for 8 would have made the 8 fail easier to bear.
Not entirely sure the company / open comparison is the whole story. Someone somewhere designed metro (or 7, or 10), figured out a UI and design language, and had some principles behind it. Those could be made the contract for the team's software being seen in the world. Again Windows has it more complex as so much of the GUI ends up in the .exe, so what you see is when it was made not what it runs on.
I think you're right in that having got where we are, it's unlikely to easily improve.
The existence of a thorough HIG is one of the things I love about elementary OS as a Linux distro [1]. They take some of flak for looking very similar to OS X, but other distros have taken plenty of cues from Windows in the name of familiarity. At least it's consistent.
That consistency is phenomenally important for the user.
I had a quick skim, Elementary talk good sense. It's this apparent trivia that makes the experience. Like can dialogue text be copied, or how a menu opens, and why. Or what shortcut keys to use and when. Or always use the default file open as it'll automatically upgrade visuals and at least some capability when the next OS release comes along. :)
Play along and the user will know how to print, open, copy, preview and a hundred other things on the first ever use of your new program leaving them just to learn the unique new thing.
I kept my Amiga Guidelines phonebook[1] for years after the machine was effectively dead as the principles and explanations were still sound. The Apple Guidelines[2] were worth owning whether you used a Mac or not, again for the principles, and would often get recommended. I had a copy years before I ever touched a Mac! Life got simpler when they were all online.
I don't think it matters where you take cues from, so long as you are internally consistent, and apps carry on that consistency.
In the olden days the standard was the "Common File Dialog" [0], I think this existed on both Windows 2000 and XP. The CFD evolved over time.
Then Windows Vista came along and we were introduced to the "Common Item Dialog" [1] which is now the recommended way to File Open/Save.
> Acrobat has a sidebar with large icons of Recent Places, Desktop, Libraries, Computer, and Network.
Possibly your version of Acrobat is either older, or Adobe haven't bothered themselves to get with the present and implement the Common Item Dialog, or if they do they're customising it...or even worse it's a subclassed franken-dialogue. But I feel and appreciate your pain.
These two (fairly old) blog posts discuss the maddening situation with Windows file dialogues:
Personally, I can't stand the file selection dialog that is tiny and makes you expand the file tree one step at a time to find the file you want. Anyone know why that one even exists?
Oh god, I forgot about that one. If I'm remembering right that's also one of the scattered legacy bits of Windows that doesn't support DPI scaling. So not only is it a terrible UI, it's also awkwardly pixelated.
There are some commands where it doesn't work, in some cases '/' is interpreted as an option prefix and the failure is obvious, for other commands failures are not so obvious (copy IIRC, cost me half an hour some time ago)
This is the most frustrating part. cd? Fine with forward slashes! mkdir? Shits a brick! robocopy? No problem with either. xcopy? Better have backslashes. There is no consistency and sometimes, yes, the failures aren't an immediate error or will produce strange behaviour (especially if they look like flags).
So the path forward should be: MS goes bash only in its documentation, to the point that people forgets about cmd with the exception of those that really have to deal with legacy stuff. But what about powershell, does it need \ or can it use / safely?
Many Windows commands use "/" to introduce options (much like most Unix commands use "-"). Since the default command shell doesn't require whitespace after the command name and permits options to follow other arguments, it would be difficult to use "/" as a directory separator in all cases.
It would be nice if we could get Windows internally to use paths like / for the C drive and then use /mnt/d for the D drives, and use Bash as the default shell instead of cmd.exe. I suspect it will take some time, but if they do so, it would make Windows a first-class POSIX development setup.
I can only imagine the difficulty of something like this, given all the legacy code and backward compatibility issues. Perhaps intelligently rollback to C:\ style paths when apps use backslashes. For Program Files, they might as well continue using /Program Files/ since it's not all too different from /opt.
You can mount drives at empty directories in other drives, just like Unix. I have C: on an SSD and mount a HDD at C:\Stuff
I remember one installer that didn't understand this (I think it was Steam) and concluded it wouldn't install to C:\Stuff\foo because there was insufficient disk space under C: - it was looking at the free space of C: (the SSD) instead of C:\Stuff .
There's also plenty software out there that confuses volumes with drives and tries to enumerate the latter when it should be enumerating the former.
I thought this was about people still misreading URLs more than 20 years since the popularization of the web as "example-dot-com-backslash-tour"
I've never understood that. The only way I could explain it in the 90s was because "computers use backslashes" due to the ubiquitousness of DOS and Windows paths. Now, who types a path on their local machine besides developers using a command line?
I don't even have a working Windows image to try the new bashy goodness, but this was my first thought when it was announced: what about the slash/backslash difference? But even twenty years ago, bouncing back and forth between DOS/Windows and some flavor of Unix, I wished MSFT would get with the program and ditch the hard-to-reach backslash.
Windows already does accept forward slash in paths and has for a while. The back slash still lives for legacy applications and unfortunately probably will for a long long time.
How is it possible I didn't know that? Thank you. Does anyone know the history of it? I did a little research:
* I found someone asking the same question as me in 2005 (!) [1]
* Per someone on Stack Overflow: "/ can be used as a path separator at the API level, but you aren't calling the API directly. You're using cmd.exe, and cmd.exe parses the / as a command line option" [2]
* Later in the same Stack Overflow discussion someone performs a series of tests on Vista, with some inconsistent results. [2]
* Here's a history by veteran Microsoft developer Larry Osterman, which takes us back to the developers of MS-DOS and also mentions other undocumented ways MS-DOS can/could be made Unix friendly. [3]
[begin quote] Here’s a little known secret about MS-DOS. The DOS developers weren’t particularly happy about this state of affairs – heck, they all used Xenix machines for email and stuff, so they were familiar with the nix command semantics. So they coded the OS to accept either “/” or “\” character as the path character (this continues today, btw – try typing “notepad c:/boot.ini” on an XP machine (if you’re an admin)). And they went one step further. They added an undocumented system call to change the switch character. And updated the utilities to respect this flag.
And then they went and finished out the scenario: They added a config.sys option, SWITCHAR= that would let you set the switch character to “-“.
Which flipped MS-DOS into a nix style system where command lines used “-switch”, and paths were / delimited. [end quote]
We're trying different things, I think. I was doing notepad i:/whatever on the command line and you're using the file open dialog within notepad, which doesn't work. Sorry for the confusion.
Not true: They must be less than 2^15 characters long. If you use the standard file APIs on Windows (most applications do) there exists a limit of 260 characters for the path. To access longer paths you have to use the Shell API (only few applications do):
Uhm, Shell APIs are necessary when you're dealing with shell objects, but all filesystem APIs can work with paths longer than MAX_PATH iff you use the Unicode API (e.g. CreateFileW) and prefix the path with \\?\ [½].
They can't retroactively change MAX_PATH because it's a constant that's compiled in every application that uses it. Well-written applications these days will just do the \\?\ thing and be done with it. The downside of that is that you can get paths Explorer doesn't like. And I'm guessing Explorer explicitly doesn't allow you to create paths longer than MAX_PATH to prevent people complaining about »I created a folder in Explorer and copied a file there, but now I cannot open it.«. Keep in mind that (usually) developers can be expected to find solutions, but making it easy to frustrate regular users (of which the OS has at least a few hundred million) is not the best strategy to keep them using the OS.
Of course, there are also heaps of software that cannot use above method to allow for longer paths because they don't use the Unicode APIs. Maybe because some developers think supporting Windows 98 is a good idea nowadays, or because they just don't know any better. And in that heap there's a lot of poorly-ported open-source software, too.
The problem is deeply nested directory structures and sanely named directories. I got around this limitation at one job by mapping a drive deep into the directory structure, but it meant people going to the root on the network file server couldn't access the content I could (I used this work around because someone else had already done it and was cleaning it up).
The directory structure made some sense, that is, it was sane and rational. But it should've been split across several network drives to keep things shallower given the limitation.
Click on (or open in a new tab) the comment timestamp link of the comment you wish to reply to and you'll see the reply link. I think HN stops showing the reply link after three levels into a thread to discourage possible flamewars/threads going off the reservation
> The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
Yes, I need more. Is that defined as 260 bytes or 260 characters? The following paragraphs do mention Unicode normalization and storage (USC-2 probably, given Microsoft's penchant for backwards compatibility), but not how that affects the path length.
Are combining characters counted separately for MAX_PATH purposes? Do surrogate pairs count as one or two characters?
This is 2016, we really shouldn't need to be asking these byte-vs-character questions any more :(
I think this post is a little bit confused, since it talks about Bash in Windows, but I've seen no evidence that Bash supports backslash as a path separator in Windows. I agree it's unfortunate that backslash paths are still around, but I guarantee you that won't be the most annoying issue with running Linux userspace tools on Windows.
The really sucky thing about working on Windows is the paths. On Linux my applications are in /opt or /usr/apps. On Windows the path names seem super long and include all sorts of parens and spaces and such.
DOS 1.0 had no subdirectories. There was no slash: you didn't type A:\FOO.TXT, you typed A:FOO.TXT, and the prompt wasn't A:\>, but rather A>. Incidentally, this still works today, and sometimes DOS boots with a A> prompt.
In DOS 2.0, Microsoft decided to add UNIX-style directories, with . and .. for navigation, / as the separator, cd to change directory and so on. But there was a problem.
DOS 1.0 had used / for flags (e.g. DIR /W). Microsoft's solution to this was to switch to - for flags, but IBM didn't like this change. So Microsoft compromised on using \ as the directory separator and kept / in use for flags.
However, Microsoft clearly didn't like having to make this change. How do we know this? Well, DOS nonetheless also supported / for directories (and thus its successors, including Windows NT do), and, at least for a little while, contained a setting which let you use - as the flag character.