Why Does Windows Really Use Backslash as Path Separator?
os2museum.com
os2museum.com
Like MS-DOS file names were 8 characters with a 3 character extension however the extension was separated not with a period but a forward slash. Also files could have a password which was separated from the name/ext by a period. Disk drives we're referenced by numbers, 0-7, and separated from the name/ext.password by a colon. For example copying a file from one drive to another could look like "copy ascii/txt.foofum:0 ascii/txt.feefum:1". If you wanted a listing of all the txt files on the current drive the command would be "dir /txt". The file system wasn't hierarchical so there was path separator.
Do you mean the opposite?
I sometimes become nostalgic regarding my TRS-80 Model I but it never involves TRSDOS. TRSDOS was a steaming pile. There were other operating systems available for the TRS-80 but they added features or fixed bugs. They maintained compatibility with TRSDOS as far as file naming went.
But my comment really wasn't a criticism of the choices made regarding naming then but more about the scope of issues that would be faced in naming conflicts between a hypothetical Windows based upon the TRSDOS conventions and unix systems today. It would make the "\" vs "/" issues seem like a walk in the park.
> Note that the odd numbers in square brackets are the TOPS-10 way of specifying directories. Good thing DOS didn’t adopt that one.
DOS did in fact adopt square brackets for specifying (named, not numeric) directories; you see them in square brackets with the '/w' (wide format) option.
Before Microsoft was doing DOS their big product was Microsoft BASIC for the Altair computer. No OS, just load it into memory (from paper tape or cassette tape!) and start it up. Microsoft BASIC was written in 8080 assembler (Bill Gates once pointed this out to me in a meeting). The assembler that was used was called CROSS80 and it ran on both TOPS20 and TOPS10 (DEC10 operating systems for the DEC system that Bill and Paul used at Harvard when writing BASIC)
The TOPS-10 command line manual is here : https://livingcomputers.org/Discover/Online-Systems/User-Doc... and you will see that on page ix in the conventions used, TOPS 10 introduced command options (switches) with the forward slash character (/switch)
The use of / for "options" was a standard part of DCL (the DEC Command Language) here is the document for RT-11 (ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PDU0A-TC_RT-11_Commands_Manual_Aug91.pdf)
Microsoft was copying DEC because at the time DEC was the most successful MINIcomputer company and Microsoft had aspirations of being the most successful MICROcomputer company.
As a result command options (or switches) were preceded by '/' and that gave the parser heartburn if you used forward slash for the path. If you read the RT-11 manual you will see that the COPY command took an option /BOOT to copy to the boot directory, and it was written COPY/BOOT not COPY<space>/BOOT. If a directory was involved it would be FOO/COPY/BOOT and how would you be able to parse that? Bell Labs (also DEC users at the time) switched to using '-' for UNIX to indicate a switch or option because it wasn't a path character.
At the end of the day the desire to be like DEC was what gave us both devices with colon's on the end (LPT: anyone?) and logging into the "active" directory. And DEC used slash for options in their DCL so that is what Microsoft used.
One that always gets me is the overlapping window interface being a neat hack in order to demonstrate the concept of a multi-process gui when you are on a mainframe with monolithic memory in 1970, rather than 'how you are supposed to do things'.
The "Microsoft BASIC Compiler, Version 5.3 July, 1981" manual https://archive.org/stream/BASIC_Compiler_v5.3_1981_Microsof... says: "The compiler operates under the CP/M operating system" "6.3 COMPILER SWITCHES ... must begin with a slash (/)" "MACRO-80 ASSEMBLER ... 2.2.2 Switches ... must be preceded by a slash" "4.2.1 LINK-80 Switches ... must be preceded by a slash (/) . (With the TEKDOS operating system, switches are preceded by hyphens . See Appendix A.)" "5.2 LIB-80 SWITCHES ... are always preceded by a slash"
(The "TRS-80 Manual: BASIC Compiler" https://archive.org/stream/BASIC_Compiler_19xx_Microsoft/BAS... says: "3.2.3 Command Line Switches ... Switches are always preceded by a dash ... -Z-4-T" "Filename extensions must be separated from the filename by a slash mark (/) ... /BAS Basic source file" and does not mention CP/M.)
"Microsoft FORTRAN-80 Ver3.4 Users Manual" https://archive.org/details/bitsavers_microsoftc0Ver3.4Users... also says switches "must be preceded by a slash" for CP/M, but for TEKDOS (Section 4) "the switches are delimited by commas or spaces instead of slashes"!
"Microsoft FORTRAN-80 Users Manual 1977" https://archive.org/details/bitsavers_microsoftc0UsersManual... also already says "Each switch should be preceeded by a slash (/)". "Section 5 Operating Systems" says command lines are supported on "CPM" and "DTC Microfile", but not on "ALTAIR DOS".
"Microsoft COBOL-80 1978" https://archive.org/details/bitsavers_microsoftc978_6774127/... says: "Each switch must be preceded by a slash (/)" (1.1.2 MACRO-80 Assembler, 2.1.2 LINK-80 Linking Loader) "switches are always preceded by a slash" (3.2 LIB-80 Library Manager) "Section 4 Operating Systems" Command lines are supported on "CPM", "DTC Microfile" and "ISIS-II", but not "Altair DOS".
What I see when reading this set of links is that Microsoft really likes slash the the option separator. And while they ran on CP/M neither the CP/M commands[1] or the ISIS commands[2] (both operating systems that Gary Kildall supplied from his company Digital Research.) Used the slash character for options. And that tells me that it wasn't Gary's idea to have slash as an option introducer.
And as mentioned previously, it was DEC's idea to use slashes for options in DCL, which may have been inspired by IBM's Job Control Language (JCL).
[1] "CP/M Operating System Manual" -- http://www.cpm.z80.de/manuals/cpm22-m.pdf
[2] "ISIS-II User's Guide" -- http://bitsavers.trailing-edge.com/pdf/intel/ISIS_II/9800306...
Yes, it actually did exactly what it sounds like!
Chalk one up for DEC and BASIC. What other programming languages support that feature, huh?
Now all you need is a COMEFROM and COMESUB and RUNREVERSE (or NUR) statements, and you can write reversible BASIC programs!
https://en.wikipedia.org/wiki/Reversible_computing
https://en.wikipedia.org/wiki/Counter-Clock_World
DECSYSTEM 20 BASIC User's Guide: LISTREVERSE command
LISTREVERSE
LISTNHREVERSE
LISTREVERSE and LISTNHREVERSE print the contents of the
user's memory area in order of descending line numbers.
LISTREVERSE precedes the output with a heading,
LISTNHREVERSE eliminates the heading.
LISTREVERSE
EQUIV 10:53 13-NOV-75
40 END
35 PRINT "THE EQUIVALENT CURRENT IS",I, " AMPERES"
25 I=E1/R
10 INPUT R
5 INPUT E1
READY
http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-2...
Forward slashes and backslashes have been supported as path delimiters all the way back to MS-DOS 2.0 when hierarchical directories were first introduced. The DOS and Windows file APIs never cared which you used.
It was only command line and GUI apps that (rightly or wrongly) preferred one or the other. The only new thing here is that some of these apps have finally started to recognize either delimiter.
That is a tricky thing for a command line app where the wrong slash may be interpreted in a way the user did not mean. For GUI programs there was never a good reason to not accept both, e.g. in a file path field.
The SWITCHAR option was present to set a value which COMMAND.COM (and other DOS utils) consulted such that one could make it honour '-' as the flag leader, and then accept '/' at COMMAND.COM (and other DOS utils).
Unfortunately not all third party utils honoured that, and so it usually ended up not being worth flipping it in to Unix compatible mode.
That said, one could take advantage of the recognition of '/' in programs one wrote, e.g. C code (so avoiding "directory\\file.txt").
* AL=0, return switch character in DL
* AL=1, set switch character to character in DL
* AL=2, return '/DEV/' setting in DL
* AL=3, DL=0 if '/DEV/' required, DL<>0 if not.
But it worked. I'm still not sure how I feel about it working...
Screenshot: https://1drv.ms/u/s!AqSptDJA-vctqs4OGewT6Qa-PWBvbw
According to the ntfs-3g FAQ, this is expected behavior[1] and is a consequence of NTFS' namespace implementation. Allegedly, such files could be removed via a Samba client, but I've never tried.
I confess that outside mounting the disk under Linux, I know of no first party solution to remove or rename such files; but, I'm also not especially knowledgeable on Windows internals.
[1] https://web.archive.org/web/20090207135653/http://ntfs-3g.or...
I have it installed on my Windows machine. I ought to give it a try.
That was because Macs at the time (1991 or so) allowed you to use slashes (and spaces of course, but not colons, which it used a a path separator), and of course those silly Mac people, being touchy feely humans instead of hard core nerds, would dare to name files with dates like "My Spreadsheet 01/02/1991".
https://en.wikipedia.org/wiki/GatorBox
Unix-Haters Handbook
https://archive.org/stream/TheUnixHatersHandbook/ugh_djvu.tx...
Don't Touch That Slash!
UFS allows any character in a filename except for the slash (/) and the ASCII NUL character. (Some versions of Unix allow ASCII characters with the high-bit, bit 8, set. Others don't.)
This feature is great — especially in versions of Unix based on Berkeley's Fast File System, which allows filenames longer than 14 characters. It means that you are free to construct informative, easy-to-understand filenames like these:
1992 Sales Report
Personnel File: Verne, Jules
rt005mfkbgkw0 . cp
Unfortunately, the rest of Unix isn't as tolerant. Of the filenames shown above, only rt005mfkbgkw0.cp will work with the majority of Unix utili- ties (which generally can't tolerate spaces in filenames).
However, don't fret: Unix will let you construct filenames that have control characters or graphics symbols in them. (Some versions will even let you build files that have no name at all.) This can be a great security feature — especially if you have control keys on your keyboard that other people don't have on theirs. That's right: you can literally create files with names that other people can't access. It sort of makes up for the lack of serious security access controls in the rest of Unix.
Recall that Unix does place one hard-and-fast restriction on filenames: they may never, ever contain the magic slash character (/), since the Unix kernel uses the slash to denote subdirectories. To enforce this requirement, the Unix kernel simply will never let you create a filename that has a slash in it. (However, you can have a filename with the 0200 bit set, which does list on some versions of Unix as a slash character.)
Never? Well, hardly ever.
Date: Mon, 8 Jan 90 18:41:57 PST
From: sun!wrs!yuba!steve@decwrl.dec.com (Steve Sekiguchi)
Subject: Info-Mac Digest V8 #3 5
I've got a rather difficult problem here. We've got a Gator Box run-
ning the NFS/AFP conversion. We use this to hook up Macs and
Suns. With the Sun as a AppleShare File server. All of this works
great!
Now here is the problem, Macs are allowed to create files on the Sun/
Unix fileserver with a "/" in the filename. This is great until you try
to restore one of these files from your "dump" tapes, "restore" core
dumps when it runs into a file with a "/" in the filename. As far as I
can tell the "dump" tape is fine.
Does anyone have a suggestion for getting the files off the backup
tape?
Thanks in Advance,
Steven Sekiguchi Wind River Systems
sun!wrs!steve, steve@wrs.com Emeryville CA, 94608
This is not necessarily true of the "user space" of Microsoft systems. Paths are not only traversed by the "kernel", but also manipulated by applications like the Explorer shell, which may or may not like forward slashes.
Microsoft introduced "extended paths" to accommodate Unicode and paths longer than 260 characters (i.e. "C:\<256-char string>"). These can be prefixed by "\\?\", which sadly does not support slash mixes. Rust's standard library `canonicalize` function, for example, returns "\\?\" paths!
(* EDIT: I originally wrote some historical inaccuracies, see ynik's reply below for the corrections. Thank you ynik!)
From the docs: "File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix." - https://docs.microsoft.com/en-us/windows/desktop/FileIO/nami...
The Windows 10 change in 2016 is something different: if an application opts in (via manifest) AND the LongPathsEnabled registry key is set, long paths will be supported by some (not all) Windows API functions even without the "\\?\" prefix. These new long paths support a mixture of slashes just fine.
And when first implemented it was UCS-2.
According to this[0] the path limit is nearer 32739*2 bytes as a drive like "C:" gets expanded to "\Device\HarddiskVolume1".
[0] https://stackoverflow.com/questions/15262110/what-happens-in...
The Finder apparently lets you use "/" in file names!
I expect you won't believe me, so try it.
Now look at the file in the shell with "ls".
Go figure!
Now who's unholy???
When Mac OS X came around, it included a POSIX API and kernel (so applications expect to be able to use ":" in filenames), but used the same filesystem as Classic Mac OS which didn't allow ":" but did allow the POSIX directory separator "/", which POSIX apps wouldn't try to use in a filename. And so at some layer they were switched around - if you try to create a filename with "/" in the GUI, it's presented as ":" to POSIX; if a POSIX app creates a filename with ":" it shows up as "/" in the GUI.
Classic Macs actually had one despite not having a command line interface, it was ':', with '::' meaning "parent directory" and ":::" meaning "grandparent directory". RISC OS used '.' as a separator, with '@' meaning "current", '^' "parent", and '&' "home"; I can hear the "everything should be POSIX" crowd screaming in agony. RISC OS could also address drives by letter or name.
There's no easy way to fix that. I suppose PATH could instead be split into PATH_1, PATH_2, PATH_3, etc, with a single path per environment variable. I've used such a solution to emulate arrays for both internal and environment variables. But that ship sailed a long time ago: the semantics of PATH are built into the shell, libc (because libc's execvp, etc are what traverse $PATH looking for an executable, not the kernel), countless other programs, not to mention the POSIX standard itself.
However, it also says (emphasis added):
”When accessing a closed file on a volume, you must identify the volume by the method given above, and identify the file by its name in the fileName parameter. FileName can contain either the file name alone or the file name prefixed by a volume name.
(note)
Although fileName can include both the volume name and the file name, applications shouldn’t encourage users to prefix a file name with a volume name.”
So ,that, sort-of, but not fully, confirms your statement.
I don’t remember ever using a path like that, and wonder what the OS did with those volume names: ignore them, and use the volume reference number to determine the volume to use, allow them to override the volume reference number, or check them against the name of the volume with the reference number?
This enabled Mac-like behavior like letting you rename and move around files (even open ones) without apps losing track of them, supporting network share auto-mounting, etc.
You could even use a physical medium label as a volume, and the OS would interactively request (via a dialog box) that the user insert the requested media into any physical drive, so that the system could interact with it; the whole notion of "is this media/physical resource available right now" was something that the OS would abstract away for you! (I think the closest thing to this currently might be RedoxOS's idea of using URLs as generally-applicable path indicators, since URLs too have a base-level resource indicator (the "host" part) and a subpath.)
Program options were dealt with by requiring paths to be entered as strings in quotes in the general case, and disambiguating them only as a last resort. There was no option prefix at all, so you would enter, e.g. `list files` as the equivalent to `ls -l`, and `list "files"` to list only something named "files".
AmigsDOS was an odd bird that used things like df0: (drive, floppy, 0) and dh1: (drive, hard, 1.)
There was no way of knowing in 1982 that UNIX was going to take over the world. That everything from corporate mainframes, to desktop PC's, and even phones would rally around the conventions of this largely academic OS.
Had Bell Labs been allowed to sell it, and history would have turned a very different path concerning UNIX clones and its adoption.
Much to my surprise, it seems to be true that CP/M did not actually use / for flags, even in PIP, although other incarnations of PIP (like that in Heath's HDOS) did use /. The CP/M 2.2 manual is at http://www.cpm.z80.de/manuals/cpm22-m.pdf and documents the command lines of all the standard utilities, including the assembler, PIP, and the text editor. (It also, in passing, documents the full 8080 instruction set and OS API.)
TENEX was born in 1969 but grew up in the 1970s, but the use of / for switches in DEC-land predates it; https://en.wikipedia.org/wiki/Concise_Command_Language is somewhat confused, but it currently describes how the PDP-6 monitor program used / for switches in, presumably, 1964.
DEC operating systems like the ones CP/M aped used / liberally for switches, and third-party programs we used on CP/M certainly did use / for switches. This was not limited to the PDP-10 large systems operating systems; it was also true on OS/8 for the PDP-8, as described in https://www.pdp8.net/os/os8/index.shtml (though, as you can see, some commands used - instead, like the later Unix). The PDP-8 shipped in 1965, but OS/8 might be more recent than that.
I don't think it's accurate to say, "the PDP-8 and -11 OSes would have been inspired by TOPS-10," except in the sense that they were also inspired by the IBM 360 and other systems — ideas did cross-pollinate, of course, but circumstances conspired to prevent especially strong cross-pollination in this case. The PDP-8 predates TOPS-10 by two years, so there is a substantial amount of software for the PDP-8 that could not have been inspired by TOPS-10 — including, I think, early versions of OS/8 — and RT-11 and RSX-11 followed OS/8 rather closely, especially at first. And, as I understand it, inside DEC, the small-systems folks (the PDP-7, -8, and -11) were organizationally separate from the large-systems folks (the -6 and -10), I think in geographically separate locations.
Most basic PDP-8 software was written on '10s using a cross assembler, including the various compilers and interpreters meant for PDP-8 users (Basic, Focal, Fortran II and IV), and OS/8 was made to look much like TOPS-10 externally, though they had nothing in common internally. A line can be traced from TOPS-10 to OS/8 to RT-11 to CP/M to DOS to Windows command lines.
There were some nice features I still miss in OS/8, like the COMPILE command, which would accept a number of source files, figure out from their extensions what language they were, and run the appropriate toolchain (it was normal for each language to have its own assembler and loader).
So basically I was full of shit and TOPS-10 really is the origin. Thanks for the correction, John!
And Windows inherited a lot of DOS baggage.
VMS, which came later and is therefore irrelevant, used . to separate directory names in paths.
I am shamelessly uninterested in poring over the linked TOPS-10 manual to find out, so I'm hoping you know. :D
A lot of early operating systems didn't have hierarchical directories. It was common to have either one single directory for the whole volume (like CP/M and DOS 1.0 had), or else a two-level structure in which each user gets their own directory but no nesting of directories is allowed. TOPS-10 PPN's are like that.
Discussion here: https://bytes.com/topic/python/answers/23123-when-did-window...
Inventing new ways after the typewriter. Tss. These young people :)
Stuff ended up being characterized by what disk it was on (floppy labeled "homework" vs. "games") rather than where it was in a filesystem. Directories were only necessary once Hard Drives appeared and you could centralize your storage.
MP3s can mostly sort themselves, but your pictures ... and then you have the N-layer-deep "old computer" directories, where you copied all the files from your last computer to your new computer.
Have you seen how most non-technical users manage files on their desktop?
With ADFS the files could be put in directories but these were single letter prefixes to file names. You could not change into a directory and, once one's mind was thinking the ADFS way, the idea of a sub directory with further sub-directories was as conceptually difficult as it is to imagine what 5D space looks like.
The way regular users save files to the downloads folder or the desktop with no sub directories is different. What they are doing is quite sensible for their workflow. This is an extension of 'search don't file', which is Gmail ethos for what to do with your mail.
In previous times 'search don't file' wasn't viable for email. You had to create rules and sub folders. Gmail enables you to do that but it is productive for people who don't do that due to the search.
Traditionally Windows was useless for finding files with search, taking too long and showing you some cartoon dog whilst it chuntered through files slowly, with no command line 'grep' power tools. So you had to 'file' rather than 'search'.
ChromeOS and Android are 'post files' systems to an extent. ChromeOS has moved on from desktop computing of old. I am not one to knock casual Windows/Mac users that 'instinctively' work the ChromeOS/Gmail way. Of course I would hang, draw and quarter any programmer that didn't save files the UNIX way, i.e. in folders with no spaces or other weird characters in filenames.
Writing code that isn't able to handle spaces or special characters on pathnames, given that there are even OS APIs for it, is just sloppy coding.
I've worked with many OS's that didn't even have a directory structure, and those that did were only one level deep. And there wasn't a lot of "slashing" going on....DG RDOS for example. Some other OS's had colons (perhaps VMS - I can't remember now.
We're talking about a time back in the depths of history where OS's had their own specific quirks. To assume that folks bumping into computing way-back-when encountered Unix regularly and "used slashes" is based on a deeply flawed presumption. Back in the early 80's (and into the early 90's) cheap computing was to be had by the use of CP/M and MSDOS, not Unix because it was too bloody expensive for non-academic use. I used to look after a bunch of SCO 86 boxes in my time (pre-Linus), for the customer these licenses were not cheap compared to say MP/M.
My first encounter with Unix and the "forward slash" was in fact in 1986, running on a NCR Tower box (and that's some minor exotica I could go on about...) and to me it was just another thing to remember.
So glorifying Unix over its choice of "/" as a directory separator. Really, who cares?
I enjoy Unix and Linux, but this hagiography over its greatness ("/") seriously makes me wonder about how folks choose an OS these days to get work done.
https://news.ycombinator.com/newsguidelines.html
Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
Early in my career I did this from the command prompt while typing a recursive remove command and basically auto-torched a much higher directory tree thanks to my backslash-equals-return typo.
Out of curiosity, if we're describing the two characters, which would logically be "down slash" and "up slash"?
Downslash \
Upslash /
We could've just as easily ended up in a world where options are introduced with \ and path separators are commas, or any number of other combinations. It's a little funny to think that the TOPS-10 developers probably spent less than a day in total deciding on the character, far less than the time spent by everyone else since then thinking about why they did it that way.
TOPS-10 subdirectory separators were commas, but the path was enclosed in [] so it was always clear which part was a path and which part was something else.
UNIX and DOS/Windows made a big mistake by removing the enclosing characters, and TOPS-10 was a 6.3 file system that never used them to their full extent.
The (back) slashes and switches weren't the biggest problem. Spaces in file paths were - and sometimes still are - hard to deal with.
A standard pair of enclosing characters would have eliminated a lot of unnecessary and unreliable escape character logic, and would also have allowed almost all other characters to be used without problems.
Windows allows you to enclose paths in double quotes, which deals with the space problem.
Off the top of my head, I don't recall if Linux has the same behaviour?
pip /li
DOS just copied Unix, right down to the | piping, and < > redirection, and . and .. directory links which are fake.
Navigation of a path requires that the parents be traversed before children. For instance resolving /usr/bin/ls means we locate the root directory node, then navigate through usr and bin, finally resolving to ls. The components are written in order of traversal, and that order is left to right because English is written left to right. When /usr/bin/ls is passed to the kernel, it's in a character string which is referenced by a pointer to its beginning: it's pointing at the / in /usr. It is natural to process it in that order: visiting the characters in / u s r / b ... order just requires incrementing the pointer byte by byte from the starting value.
There are other reasons to have the most major part near the beginning. A telephone number's country code and area code details coming first allows the network to begin make appropriate switching decisions before the dialing is complete.
Imagine you had to dial someone's "extension 42" before the company phone number. That extension would have to be stored somewhere, until the company's PBX picks up the call, because that extension only makes sense in the context of that switch.
Also, if we collect the absolute path of every object in the file system, and then sort it lexicographically, the parent to child order means that things in the same directories end up nicely listed together.
Also "." was extremely common, used on large DEC systems (RSX, VMS) and Tandem/NonStop as home systems like RISC OS.
Multics and VOS use '>' as the separator (and '<' to indicate the parent).
The Multics-style paths really are the cleanest, in my opinion.
Edit: We run the Public Access Multics system at https://ban.ai/
Imagine if Internet domain names are arranged as file paths. To reach the BBC web site, I'd have to type in "uk.co.bb" before the computer can auto-complete. As it is, all have to do is type the letter B.
Imagine if file paths were expressed in reverse. You want to edit xorg.conf. As soon as you enter "vi xor" the shell would know enough to auto-complete it to "vi xorg.conf/X11/etc". As it is, organizing files into a logical structure actually makes them harder to find.
> in<TAB>
index.html@.
init.sh@..
index.html@foobar@..
...
inputrc@etc@/
Come to think of it, that also breaks option escaping in glob et al:
./--kill=everything
vs
--kill=everything@.That's not a universal rule. It completely depends on the language. For example in Farsi (Persian) that is exactly how addresses are expressed.
Completion cannot be anchored to one end of the URL; users would find that frustrating.
When users are searching for a URL by means of a keyword embedded in that URL, it could be anywhere in that URL.
> When written in Japanese characters, addresses start with the largest geographical entity and proceed to the most specific one. When written in Latin characters, addresses follow the convention used by most Western addresses and start with the smallest geographic entity (typically a house number) and proceed to the largest.
[0] https://en.wikipedia.org/wiki/Japanese_addressing_system
I could technically say "10 to 7 in the evening on the 24th day of May" but everyone would look at me like I'm nuts.
Most European countries follow that order of precedence. Intriguingly so did technical reports for the US DoD, dropping the ordinal suffix for clarity even when spoken: 24 May.
And then ISO says 2019-05-24 18:50
The old Sendmail had to rewrite addresses as mail was passed around (via uucp, often) to accommodate the Brits insistence on driving on the contrary side. But they invented computers, so who could tell them they were wrong?
ISO 8601 dates are formatted this way, from biggest period to smallest (e.g. 2019-10-31). It makes them universally easy to parse, and removes any confusion over the date and months parts (common issue between US and UK).
Don't you mean easy to sort?
If not, what makes YYYY-MM-DD any easier to parse then MM/DD/YYYY?
The problem with MM/DD/YYYY is that outside of the US it may be perceived as DD/MM/YYYY.
EDIT: Apparently:
https://stackoverflow.com/questions/1976007/what-characters-...
This was probably around the Windows 98 timeframe, but I remember several instances when extracting zips (probably WAREZ) where the file that was written contained characters that Explorer couldn't handle correctly. It wouldn't allow moving those files to the Recycling Bin, but would typically allow renaming the portion before the extension. I had a collection of `zzzz.???` files for a long time.
It was really common back then to put dates in file names, and names could be 32 characters long. Furthermore, you didn't need an extension because every file had a separate 4-byte (binary, but usually ASCII anyway) type.
Please turn JavaScript on and reload the page.It would be even nicer if the web were designed with a semblance of sanity.
As well as a lot of sites, period.
unless you're willing to pay them with your data and eyes, they won't let you see the site.
not that I agree with this.
Sometimes scripts can be used to implement something, but just to display text and so on, should not need a script; it should just have the text. (Often they like to put in so many pictures, styles, scripts, etc, that you do not need. Just put the text!)
(Some things might be other protocol and try to make a HTML interface to it, but even then the protocol should be documented without requiring such scripts to read it and you can access it directly and don't have to use their implementation. For example if they use gopher or NNTP or telnet then you can just use those directly and the URL should link to them directly rather than requiring the HTML.)
One thing to do for web pages that use specific scripts is to define a new attribute to specify the unversal ID of a widget or program so that you can more easily substitute your own implementation or use it in web browsers that do not implement JavaScript.
Nothing on that site needs JS. Nothing on that site should need any more than a browser that can display text and images. This isn't a fancy "web application" or other JS-based thing.
https://virtuallyfun.com/wordpress/2019/05/15/os-2-museum-ba...
Source traced back to DEC TOPS-10, which MS founders were exposed to. Then a conservative manager (piece blames IBM) chose backwards compatibility over consistency with Unix, thereby dooming billions of regular folks to need an explanation what a backslash is compared to a slash.
Taking lumps for a few months when the userbase was miniscule compared to what it is today sounds more reasonable now.
"compatibility with unix" didn't matter in those days.
There were many, many OS's, all running on computers so expensive (for whichever micro/mini/mainframe segment) that most people didn't expect to replace them, ever.
cpm vms tops10 tops20 unix multics rsx11 mvs os/360 gcos apple dos etc etc etc.