Note that the OEM README[1] for MS-DOS 2 (the first version with a hierarchical filesystem) suggests that it was at IBM’s insistence that MS-DOS used backslash for directories and slash for options, rather than slash for directories and hyphen-minus for options (even though Microsoft’s own programs for CP/M apparently used slash for options due to DEC influences, instead of the brackets used by CP/M itself[2], so this is a bit of a tangle). The documentation and examples for CONFIG.SYS[3] also bear an evident Unix influence, note in particular AVAILDEV and SWITCHAR. The MS-DOS-specific calls for file descriptors (as opposed to CP/M-compatible calls for FCBs) are called “XENIX file calls” in the source[4]. (All DOS system calls for files accepted either separator, but the option parsers would retrieve SWITCHAR[5] and give it precedence.)
Yep, there was a (brief) period of time -- before MS-DOS became wildly popular -- when Microsoft was pitching Xenix as the future operating system for the PC.
(Also worth noting is that MS-DOS 2.0 was a nearly complete rewrite of the 1.x codebase...)
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.
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.
MS-DOS did have a function to change the option character (INT 21h, AH=37h) [1], and the "kernel" always accepted both '\' and '/' as a path separator (and that is still the case today; the shell however, is another story). The same call can also change MS-DOS to require "/DEV/" before device names. [2]
[1] Documented for MS-DOS 2.0; documentation removed for MS-DOS 3.0; still available (according to my source) through at least MS-DOS 3.30
[2] God, why do I still remember this information thirty years later? Sigh.
CP/M does not use forward slash as the CLI modifier.
Examples - from the standard CP/M utilities (CP/M 2.2)
ASM FILE.ABC
.ABC encodes options. Source file for ASM is always .ASM
STAT uses $ - STAT FILE $R/O sets file to read-only
PIP A:=B:[G0] - PIP (copy, "peripheral interchange program"), uses [ for options, as do later Digital Research programs (like the linker). Basically /no/ Digital Research use of / as option separator.
Microsoft used / - for example the command line L80 FILE,FILE/N/E - which means link FILE.REL (relocatable), naming the output FILE.COM, and link and exit.
CP/M 2.2 introduced "user areas" - a disk could be divided into 16 user areas (USER 0 to USER 15). There was no "searching" until CP/M 3. CP/NET (Digital Research networking) used [ as a separator. Examples (from CP/NET documentation)
A>RMAC SNIOS
A>LINK SNIOS[OS]
LOGIN {password}{[mstrID]}
LOGIN secret[01]
would log in to server 01, with password secret
NETWORK B:=D:[F]
assigned B: to server 0F, drive D:
The lack of directories was not such a loss, as the maximum disk size for CP/M 2.2 was 8MB. Remote drives with CP/NET could be much larger (I have used up to 1TB).
Forward slash as a modifier prefix was IBM's desire because it was what they used in Mainframe OSes at the time. A lot of MS-DOS things were for "compatibility" with IBM Mainframes at the time. Supposedly, Microsoft was lightly against the forward slash as command argument because they preferred Unix machines at that point as development mainframes and liked the POSIX defaults for forward slash as directory separator. (Which is why MS-DOS even from the early days of the file system often supported both for directory slash in first party commands, even if individual app argument parsers from third parties did not.)
> Forward slash as a modifier prefix was IBM's desire because it was what they used in Mainframe OSes at the time. A lot of MS-DOS things were for "compatibility" with IBM Mainframes at the time
Not true. On IBM mainframes, options are generally specified in a NAME=VALUE or NAME(VALUE) format. For example, here is a TSO command to allocate a dataset: ALLOCATE DATASET(ALLOC.FILE1) NEW DIR(4) TRACKS SPACE(2,3) DSORG(PO) RECFM(F) LRECL(80) BLKSIZE(800) CATALOG
VM/CMS uses an open parenthesis to introduce options instead, for example: LISTFILE (LABEL
The forward slash option style does not come from IBM mainframes.
Nor (despite what many people think) does it come from CP/M – CP/M's own option style was to put options in square brackets: PIP B:=A:*.COM [G9 V]
Not sure exactly where CP/M gets that from, but may be very vaguely inspired by IBM mainframe conventions (especially VM/CMS), with square brackets replacing parentheses for whatever reason, and using single characters to save memory and typing.
What I actually believe happened: forward slash comes from DEC via Microsoft. Microsoft's development tools for CP/M used that option style, which Microsoft got from DEC, because they didn't like CP/M's native option style. QDOS/PC-DOS/MS-DOS 1.0 copied that Microsoft option style.
Yes, IBM did tell Microsoft not to change it from / to - between PC-DOS 1.0 and PC-DOS 2.0. But that was simply because IBM cared more about backward compatibility between DOS 1.0 and DOS 2.0 than Microsoft themselves did. It was nothing to do with mainframes.
The only thing about DOS which shows any strong direct IBM influence, in terms of actual syntax/terminology/concepts/etc, is code pages.
MS-DOS did not have directories at first either. It was a feature in version 2.0, when hard drive support was added.
Directories seem to have been a foreign concept among early home computer operating systems and I suspect its adoption was driven by the adoption of hard drives. For example, the Apple II did not gain directory support until ProDOS was introduced and the Macintosh only gained folders with the introduction of HFS. I don't recall directories existing for the Commodore 64 either.
Directories just weren’t worth it on discs that stored less than 200k. You organized stuff by putting the floppies in the right place in their storage boxes.
Technically, the original Macintosh filesystem supported folders as "an illusion maintained by the system software"[1] in spite of its flat directory structure.
Oooo, question for those that might know a little more about this.
I had an Amstrad (CPC6128 running CP/M) and I found that if I did cat to list disk contents without a disk in the drive enough times in a row it would eventually list out really random contents. Anyone know what might have been going on.
CAT would have been AMSDOS, not CP/M (it was DIR in CP/M). Not sure what was happening in that case though - it sounds like a bug, but not one I ever recall encountering!
Oh interesting. I swear it was cp/m; cat I’m more hazy on (though I feel like I didn’t use dir until ibm dos).
I had to really hammer on the command, and it would actually be trying to read either the hardware. I wonder if it was actually a physical issue that triggered it.
Sounds like whatever check that was used to determine whether a floppy was present or not had some small probability of giving a false positive. Maybe because without a floppy, the head would read random data that could pass some integrity check by chance.
