Why CP/M didn't have directory separators, and what if it had got them?

[liam_on_linux]

CP/M did not support subdirectories, so it did not have a directory separator.

Its design was derived from a multiuser minicomputer OS (or several of them, principally DEC OS-8) and so it had user areas instead:

A1:

B6:

C3:

 

I suppose it's fairly natural to assume from the POV of the 3rd decade of the 21st century that computers from 50 years ago had basic facilities like hierarchical directories... but not all of them did.

Big ones like high-end minicomputers did. I learned on VAX/VMS at university in the 1980s, and it did.

Cheap low-end minis didn't, and nor did the early 8-bit machines whose design was inspired by low-end minicomputers.

The main influences on CP/M were DEC OSes: OS/8 and TOPS-10.

The 2nd is mentioned in Wikipedia's history of CP/M.

I have never used either -- I'm not that old -- and I am not sure but I don't think either supported hierarchical subdirectories.

The closest thing that evolved into something that did was the DEC OS RSX-11, which influenced VMS. They used a filesystem called DEC Files-11. So that did end up supporting hierachical directories, but there isn't a "directory separator" per se. That's a UNIX-ism that MS-DOS 2.0 copied.

A VMS file in its folder might have been called something like:

VAXA$DKA100::[USERS.LPROVEN.SOURCE.FORTRAN]WUMPUS.FOR;42

In other words, devices had multicharacter names that had meaning (e.g. what type of controller board, then which controller, then which disk), possibly after a cluster node name, then in square brackets a folder path separated by dots, then a filename, then another dot, then a 3-letter extension, then a semicolon, then a version number.

Looks baroque compared to the dead simple UNIX name style...

/home/lproven/source/fortran/wumpus

Every time you save a file, the version number increments automatically. And path specs combined with device names and cluster names mean that the filename could point to another disk on this controller, or another disk on a different controller, or a disk on another node in the cluster, or a disk on any node in a named cluster.

You can't do that so easily with the Unix naming system. So the sysadmin has to mount folders from other machines into this one's filesystem, and that means also setting up some kind of distributed authentication like NIS or YP or LDAP, and then some PAM modules or something... and it all gets very complicated.

In other words, the simplicity of the UNIX design doesn't take complexity away: it just hides it. It's still there but it becomes someone else's problem.

Whereas the DEC way of doing things sort of puts the complexity right there in front of you, but in return, you got rich facilities right there.

Much less need for Git when files are versioned and you can go back to an older version before you broke something just using info encoded into the filename. Much less need for NFS mounts when the filesystem knows about controllers and networking and clusters and lets you address them. Much less need for bolted-on fancy authentication when that's built into the OS because the designers thought about stuff like networks, clusters, and authentication, when all that got taken _out_ of UNIX and then had to be bolted back on later.

So, yeah, the UNIX way is simpler, but OTOH that also means it's poorer. Poorer as in less rich. As in the DEC system was richer: being richer lets you do more.

CP/M evolved into multitasking multiuser OSes in time, but DR didn't get to re-invent all this stuff.

Maybe if DOS had never happened, DR would have prospered and bought DEC instead of Compaq buying DEC, and this stuff would have made it into PC OSes.

Who knows...               

Comments

[history_monk]

DOS or CP/M needed a better way of managing files as soon as hard disks appeared for PCs. The simplicity of using UNIX-style directory trees was likely important in the era from MS-DOS 2.0 in 1983 to the advent of Windows 3.0 in 1990. So if DR were the dominant PC OS supplier, they'd have had to provide some kind of hierarchical directory system in the early 1980s.

Even if DR had prospered and become the alternate-history equivalent of Microsoft, I doubt they would have bought DEC. Well-run software businesses don't buy ailing hardware manufacturers, especially ones with such a baroque range of outdated hardware as DEC had in the 1990s. More recently, Oracle's purchase of Sun has been quite unsuccessful, although Oracle were saved by the success of their cloud offerings.