We should all just be grateful they didn't copy the file and drive conventions from TRSDOS which was the operating system for Tandy's TRS-80 line of computers.
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.
Like the article says, hindsight is 20/20. If it was 1977 and TRSDOS was the only thing that transformed your expensive brick into something capable of copying a file from one drive to another you might be more of a fan.
In 1977 the drive on my Tandy provided expensive brick was a tape drive but in 1979 I built a LNW System Expansion which added a floppy controller and TRSDOS became what transformed my expensive brick into something capable of copying a file from one of my newly acquired drives to another.
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.
Whoa, let's not go crazy! Just because the naming conventions, which weren't crazy for the day, would cause issues today doesn't mean you get to call my first child, I mean computer, a "Trash-80". I didn't stand for it then and I won't now.
It is amusing how this sort of stuff evolves over time.
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.
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
>It is amusing how this sort of stuff evolves over time.
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).
It should be noted that Windows can use either forward or backward slashes nowadays. In fact, even File Explorer allows you to use an unholy mix of the two.
Interestingly, "unholy mixes" of slashes only always work properly in old Windows paths! I found this out when debugging an open source project where '/file.txt' (hardcoded as a forward slash) was appended to a "\\?\" path.
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!)
The "\\?\" extended-length paths have existed for a long time; I think since Windows 2000 at least.
The Windows kernel and NTFS have always supported paths up to 32k characters; only the Win32 path normalization logic was limited to MAX_PATH. The "\\?\" prefix skips the normalization logic, thus allowing apps to use the full path length.
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.
Thanks for pointing these out, very interesting! I amended the parent so others aren't misinformed (with credit to you). I discovered this because the Rust standard library's `canonicalize` function actually returns paths in extended-length path syntax. With credit to Rust, their docs actually point out that you must append paths that are backslash-delimited: https://doc.rust-lang.org/std/fs/fn.canonicalize.html
Indeed. Although technically it's UCS-2 as the low level stuff doesn't understand modern unicode; it just treats it all as a stream of wide chars. It's up to applications to interpret it.
According to this[0] the path limit is nearer 32739*2 bytes as a drive like "C:" gets expanded to "\Device\HarddiskVolume1".
Except if it's a compound emoji, which takes multiple codepoints -> more than 4 bytes.
So really the takeaway is that "character" is highly ambiguous nowadays and shouldn't be used anymore, use one of these instead:
* UTF-n code unit
* Unicode code point
* Grapheme Cluster
* Extended Grapheme Cluster
For the latter one also needs to specify the version of Unicode they're talking about, since every new compound emojis changes the definition of "Extended Grapheme Cluster".
As I recall, so could / would DOS - at the Int21 syscall level.
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").
INT 21h, function 37h could be used to get and set the switch character for MS-DOS, in addition to requiring the use of '/DEV/' for device filenames:
* 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.
Okay, why do I remember this stuff? I haven't programmed MS-DOS for over 25 years!
Every Microsoft operating system going back to early versions of MS-DOS can use / as the separator.
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.
It's partially the opposite. Some system calls only accept backlash, but user space programs and libraries may abstract this. E.g. LoadLibrary, which is similar to execve/dlopen.
Indeed. "Windows API" is very broad; it encompasses all sorts of user-space middleware, some of which could very plausibly munge paths in ignorance of forward slashes.
I accidentally typed the a mix once and noticed it when I hit enter. I honestly expected a blue screen... and I probabbly would have accepted that as the proper outcome of crossing the streams.
But it worked. I'm still not sure how I feel about it working...
Not sure. I'd expect the "foo\bar" created on that NTFS volume while mounfed from Linux to be effectively unreachable when accessed from windows (at least while the command line?).
Or not. Surprise me.
You can create file names containing special characters from ntfs-3g that make it nearly impossible to access or remove from within Windows (such as those containing a "?" character). I'm sure there's a way, but neither the command prompt nor Windows Explorer know what to do. Opening such files from a variety of test applications seems to fail as well.
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.
There used to be a bug in the GatorBox Mac Localtalk-to-Ethernet NFS bridge that could somehow trick Unix into putting slashes into file names via NFS, which appeared to work fine, but then down the line Unix "restore" would totally shit itself.
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".
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
Apparently Sun's circa 1990 NFS server (which runs inside the kernel)
assumed that an NFS client would never, ever send a filename that had a
slash inside it and thus didn't bother to check for the illegal character.
We're surprised that the files got written to the dump tape at all. (Then
again, perhaps they didn't. There's really no way to tell for sure, is there
now?)
I'd forgotten about Cygwin! Next time I think about it, that might be capable of removing said files as well (although, I guess that qualifies as a 3rd party tool).
I have it installed on my Windows machine. I ought to give it a try.
I think the intention was that 'foo/bar' and 'foo' would be in the same directory, therefore when typing C:\foo/bar into the file explorer you would have an ambiguous path. Perhaps I misunderstood.
It's useful to distinguish between command line and GUI apps vs. the operating system itself.
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.
Classic Mac OS allowed filenames to contain every character except the directory-delimiter, ":".
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.
It should also be noted that you should NOT get in the habit of doing this because the command prompt is not really amused by you doing this. (Try running foo/bar.exe.)
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.
AmigaOS actually did use : as a volume marker and / as a path separator below the volume level. "Volumes" on AmigaOS were actually more like generally-usable filesystem namespaces; the feature covered not just "hardware" volumes like DF0: or DH0: (equivalent to A: or C: in MS-DOS) but "logical" ones as well, which worked a bit like chroots in a modern OS.
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".
That's because the only special characters in file paths in Unix are / and NUL. You can't pass NUL through environment variables, both because of the C API for manipulating environment variables and how the environment is passed to the host program by the kernel--environment variables are delimited by NUL, as are argv arguments, and the argv and environ lists are delimited by a double NUL. So the shell had to pick some random delimiter, and whatever it chose would conflict with existing path semantics. Fortunately, it only effects the semantics of PATH--the colon is irrelevant everywhere else, and PATH isn't strictly necessary for anything, not even in the shell.
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.
Not all “Classic Macs”. MFS, the file system used on the original Macintosh, didn’t support subdirectories (the folders that the Finder showed were illusions created by the Finder) (https://en.wikipedia.org/wiki/Macintosh_File_System), so it didn’t have path separators.
”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?
I remember in a conversation with a school friend taking about the superiority of Macs and how Windows had the reserved forward slash, and he replied that Macs had reserved the colon. I was shocked, I had never come across it before and immediately tried to or colons in my file names.
AmigaOS would have both a name for the physical device like df0: and dh1: above but also a label or volume name which could be work: or something and those would mostly be interchangeable from the shell to refer either to "any volume named foo:" or "whatever disk is in drive0 right now".
Correct. While it was possible to use file paths, it was highly encouraged to use file system references and store alias structures.
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.
Nope, most Mac filesystem APIs would interpret : in a name as a path component. There was even an equivalent to the current working directory. No system-supported :: traversal syntax though.
Honestly, it actually DOES make sense to use separate characters for directory-delineation versus option switches.
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.
They wrote papers too (Bell Labs was, after all, a research lab), took sabbaticals, and lectured at universities. I think one of the group (Kernighan?) took a sabbatical at Berkeley that was one of the events that gave rise to BSD?
UNIX was academic, because Bell Labs were forbidden to make profit out of it and thus licensed it via a symbolic price to universities alongside source code tapes.
Had Bell Labs been allowed to sell it, and history would have turned a very different path concerning UNIX clones and its adoption.
It's because CloudFlare gates access to half the internet and get to decide whether you're considered a good actor deserving of access to a website (someday, they hope, the internet) or not.
Aparently I'm a bad actor, because the "checking" page never redirects to anything. Guess the author doesn't want people to read his site. I'll comply.
This is almost correct, but MS-DOS derives from the DEC small systems line (the PDP-8 and PDP-11), not the large systems line that ran TENEX, which took the name "TOPS-10" in the DEC Witness Protection Program (the PDP-6 and PDP-10). TENEX's only real descendant in modern computing systems is the command-line editing (and filename completion?) in bash and zsh.
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.
You've conflated TOPS-10 and TOPS-20. TENEX was developed externally by BBN, took advantage of BBN-built add-on paging hardware, and was quite different in both look and feel and its internals from TOPS-10, which had originated on the PDP-6 and was simply called "Monitor" at first. The name TEN-EX referred to its ability to run TOPS-10 executables in compatibility mode, as BSD variants could once run Linux executables. When TENEX was brought in-house by DEC, it was renamed "TOPS-20", since the Monitor had already been renamed "TOPS-10". The only difference between the PDP-10 (or DECsystem-10) and the DECsystem-20 computers was the color scheme and the OS supplied with it.
The author argues that the people at Microsoft were very familiar with TOPS-10 (which is not TENEX btw) and in any case the PDP-8 and -11 OSes would have been inspired by TOPS-10, so you're back to TOPS-10 again.
Well, it's certainly true that Gates and Allen developed Altair BASIC on a PDP-10 (under which operating system I don't know, but it could have been TOPS-10, and you are right that TOPS-10 is not a version of TENEX), but they didn't write MS-DOS; Tim Patterson, at Seattle Computer Products, did. And it's a straight copy of CP/M, not of TOPS-10. (Nor of TENEX.) Later development of MS-DOS happened at Microsoft, but I don't think Gates and Allen wrote any code for it; the last product Gates wrote code for was the BASIC interpreter for the TRS-80 Model 100, which shipped in 1983.
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.
The PDP-6 Monitor came out in 1964 and TOPS-10 was its lineal descendant (the result of progressively modifying the codebase to support different PDP-10 models), whereas the first PDP-8 model came out in 1965. OS/8 first appeared in 1971; I haven't been able to determine when its direct ancestor PS/8 was released. I ran some PS/8 programs under OS/8 V1, but I never ran PS/8 itself.
I appreciate the correction. Do you mean it was the first in the sense that "TOPS-10" was the new name for the PDP-6 monitor program as it was developed moving forward, and that all the PDP-7 and PDP-8 operating systems came long after the -6, or more literally that TOPS-10 itself is where the inspiration for OS/8 came from? Or do you not consider OS/8 an OS?
I have to say I'm not an expert on the DEC OSes, so I won't pretend to know the exact timeline, but the PDP-6 was not a very popular machine, only 23 or so sold. So I would assume it's really PDP-10 TOPS-10 that was the inspiration. OS/8 itself is from 1971 according to wikipedia, but its predecessor is PS/8. And that same article mentions how the interface was patterned after TOPS-10.
Talked to a friend of mine who spent a lot of time on PDP-8s at the time, and basically it seems like I was full of shit, and TOPS-10 really was the origin of all this stuff. More details to come.
My friend John Cowan (also known by his hacker name "John Cowan") explains:
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!
Wow, this is a great revelation, and I feel like the lede is almost buried here, namely that DOS seems to have been influenced by TOPS-10 to such a great amount. I wonder how many other DOSisms were in reality TOPS-10isms that had been replicated.
Because DOS used the slash as a switch specifier, aping popular DEC operating systems of its day, but did NOT adopt DEC's approach to specifying paths and subdirectories, opting for a more Unix-like approach in DOS 2.0.
How did TOPS-10 handle directories? The article says "Note that the odd numbers in square brackets [27,5434] are the TOPS-10 way of specifying directories," but doesn't give any more detail.
I am shamelessly uninterested in poring over the linked TOPS-10 manual to find out, so I'm hoping you know. :D
The numbers are a "project programmer number", or PPN. The "project number" is like a bit like a GID, and the "programmer number" identifies the user within the project (so a bit like a UID).
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.
Intergalactic Digital Research's CP/M was a very close copy of DEC RT-11, though not quite as close a copy as MS-DOS was of CP/M, so CP/M had a great deal to do with DEC.
VMS, which came later and is therefore irrelevant, used . to separate directory names in paths.
Not usually one to plug stuff - but the Wayback Machine browser extension is very useful for "This is down, would you like to see a snapshot" (or "This is up now for now, would you like it snap-shotted"... or my favourite "I can't believe they put this up, let me ensure this is preserved for evidence if somebody decides to re-write history")
I use it, but I've been considering uninstalling it due to frequent false positives where I get redirected to the archive when the original is not actually down.
It's from a time when the media was so small there was no need to categorize anything because the entire directory listing fit on a single screen in most cases.
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.
And now we're kind of coming out the other side, where storage is so large and can contain so many items that organizing it all into a hierarchical structure is a full time job in itself.
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.
These days every desktop environment integrates an increasingly featureful fast search feature front and center because they know you aren't going to be able to keep up.
It was hard to understand hierarchical file systems if you started out using non-hierarchical file systems. I write from experience using Acorn ADFS on the BBC Micro. You get into a way of working with what you have.
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.
I might actually upset some folks by saying....who cares, it's just a character?
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.
...did you even read the article? Nowhere does it claim greatness of one over the other, it's simply an interesting piece about a bit of computing history that plenty of people love to learn, because we LOVE trivia.
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."
Done to avoid errors, then we proceed to put the "\" key directly above Return/Enter and incur errors for decades to come. :)
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.
Oldschool Macs used colon ':' as the separator. It was not ideal for commandline use because you need to hold shift to type a colon, but in the strictly mouse oriented world of old Finder it wasn't an issue for end users.
Heh, in the Finnish layout ':' is actually the easiest of the three to type. Still requires shift but at least you don't have to reach or use both hands. The layout (like most European ones I guess) is pretty horrible for technical work of any sort, there's so much reaching to the number row while holding shift or AltGr...
Ultimately it's essentially an arbitrary choice, but the reasonable set of characters would exclude letters and numbers (too widely used for filenames already), be already available in the character sets of the time, and not too awkward to type nor look at. That means it'll be one of the special and non-paired (like parentheses) characters, and beyond that any single one would do. Beyond that, any one is as good as the others.
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.
I doubt it was a day. I'd be surprised if it was more than a minute or two.
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.
Thompson and Ritchie, who carried it over from Multics to Unix. They worked on Multics, and that OS introduced the hierarchical filesystem.
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.
The computer can easily traverse in either direction. I don't know see any technical reason to list identifiers in that order. No linguistic reason either. We don't do that for addresses in the real world. We don't say "United Kingdom, London, Westminster, Downing Street 10."
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.
It's funny that you should say that about addresses because that's exactly how they work in Japan [0]:
> 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.
It's funny you should say that about domain names because that is how they really appeared, for the longest time, in UK e-mail addresses.
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?
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.
It feels natural to me, but of course that may well be because it's all I've known.
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).
But general tendency is to go from specific to the general. That's because single name is often enough to uniquely identify something in a given context. If I say "10 Downing Street", you'd know that I'm referring to the British PM's office even if we were sitting in Palookaville Kansas. In a filesystem, that's even more true. We aren't going to have dozens upon dozens of files named "xorg.conf".
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.
I'd say that's a bit of an edge case. Consider editing a file named README, index.html, .htaccess, or any number of other files which occur in many places with the same name.
The problem I see is this makes it hard to have domain-specific or optional address interpretation. Eg "foo.png=FILE?get@example.com[http]" or... something to that effect.
Because Windows has made \ so common that many normies now consider it the forward slash. In the encounters with them I fail to evade, I often hear them referring to the slashes in URLs as "backslash". Shudder.
IIRC, different APIs in Windows handle special characters for filenames differently.
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.
It would also be nice if we didn't have to read complaints about being unable to view websites from users that disable browser features that they clearly understand will break a lot of websites.
The more I see comments like this, the more convinced I am that there is some sort of conspiracy to restrain and otherwise beat into submission users by forcing them to use hideously overcomplex software that can execute arbitrary code, and which is controlled by effectively two large organisations (one of which already has immense power over the Internet), just to view a website that is nothing more than a static document.
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.
It would also be nice if browsers didn't by default auto-execute malware served by any random website, to the point that people think it isn't the website's fault that it breaks when said auto-execution is disabled.
No, you should not intentionally hide text from those who prefer to disable JS. Disabling JS improves site load speed and reduces memory consumption. As a side effect, most of ads and trackers also stop working.
My organisation has a requirement that we build to work without JS. If we need to use JS for something then we also need a non-JS alternative, the result may be less pretty/fast/require an extra call but it works regardless of your JS choices
I agree the user should decide to run the code or not, as well as for the user to replace the code with their own if they want to modify it.
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.
Because "/" was already used as the command switch character in DOS 1.X which didn't yet have folders ((boggle)).
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.
"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.
I know we all love bagging on Microsoft, but insisting on backwards compatibility with the system you're directly replacing is not an unreasonable decision, especially since changing it could well have made DOS 1.1 scripts silently destroy data when run in DOS 2.0.
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.