One interesting thing about CP/M is that it didn't have subdirectories.
"CP/M 2.2 had no subdirectories in the file structure, but provided 16 numbered user areas to organize files on a disk. To change user one had to simply type "User X" at the command prompt, X being the user number."
In 1982, Digital Research released CP/M-68K for the Motorola 68000. This was initially written in Pascal following DRI’s acquisition of the MicroSYSTEMS company in Solana Beach. This port was originally made for the Atari ST, but Atari chose to go a different way
Odd, I hadn't heard the Pascal bit before. And the C/assembly source for CP/M 68k is out there to see (e.g. https://github.com/dwildie/cpm-68k)
Further, while Atari did go a different direction, it wasn't that different. DR's "GEMDOS" is like a fusion of MS-DOS and CP/M 68k, designed to play the same role on the 68k that PC/MS-DOS did for GEM on the 8086. There's I think bits in there that came from the CP/M architecture and codebase (program loader, for one). GEMDOS not only ran on the ST but was built first on the Apple Lisa (and some Motorola VME machines too, I believe.)
Past discussion: https://news.ycombinator.com/item?id=39368972
My major experience with GEM was Xerox Ventura Publisher.
Ventura and Aldus Pagemaker were the two desktop publishing contenders on the PC. Pagemaker used Windows. Ventura ended up going to Windows as well (no surprise there).
Notably, back then you couldn't get GEM on a PC without it being bundled with another program.
Atari shipped a PC clone that came with GEM + GEM Desktop
But that was the 2-window GEM desktop, right?
The Atari involvement wasn't until August 1984 or after. We never saw any Pascal source code for CP/M-68K (it had been ported to C by then, I suppose).
CP/M-68K was awful, GemDos was a little better (written largely by Jason Loveman at DRI), but it had its own issues. The new program loader was one of the improvements we wanted.
Thanks for chiming in. Always appreciate your recollections.
... and the open-source clone (EmuTOS) has been widely ported since.
MS-DOS (and PC-DOS) also didn’t have subdirectories until version 2.0.
These were floppy disk oriented operating systems, and at 360 kB per floppy, directories were not really that useful.
Hard disk support made it more urgent to offer Unix-style directories. Since the forward slash was already used for CLI parameters in the CP/M style, it couldn’t be used as the path separator. So Microsoft chose the backslash instead, and it persists in Windows today.
> Since the forward slash was already used for CLI parameters in the CP/M style, it couldn’t be used as the path separator. So Microsoft chose the backslash instead, and it persists in Windows today.
It's a bit more nuanced than that: https://www.os2museum.com/wp/why-does-windows-really-use-bac...
And see also https://learn.microsoft.com/it-it/archive/blogs/larryosterma... for the SWITCHAR option, which would configure DOS 2.0 to use "-" as a parameter and "/" as a path separator.
And arguably more file loaders than operating systems as such. I long thought it a sort of interesting question how things could have turned out differently if one of the many 16-bit operating systems (or Unix of course) kicking around in the minicomputer world had been more widely used on early PCs.
Some of the products mention on that piece were true operating systems.
MP/M and its derivatives (MP/M-86, CCPM, CDOS) were all multitasking, multi-threading, multi-user, multi-terminal/console real time preemptive OSs. The bank switching versions also had a form of memory protection.
CDOS-68k, CDOS-286 and the subsequent renamed to FlexOS products also had those capabilities, but with inherent memory protection.
So it is only really the basic CP/M-86 product (lacking the MP/M bits) which was the simple program loader.
In many ways the FlexOS product are sort of inspired from the DEC minicomputer RSX-11m OS; and the MP/M derivatives look like they were inspired by DEC RSX-11d (and hence RSX-15).
I was an MP/M 2 user (Altos) for a while. It was a great system for a small workgroup, supporting a handful of (Volker Craig) Terminals. VT-52 clones IIRC.
Fair enough. I suppose that hardware resource constraints were sufficiently tight at the time that the "mass market" wouldn't have thanked you for something that might have cost twice as much (at a time when micros were already quite expensive relative to today).
> And arguably more file loaders than operating systems as such
That's a bit unfair. They also provided file operations and hardware abstraction. That way, it didn't matter how your disk IO was implemented (CP/M on Apple II's used the 6502 for that) and your code could be exactly the same.
In the Acorn DFS the "directory" was an attribute for each file that was just a letter prefixed to the file's name.
It was used to group files. Since the original format only allowed 31 files per side, it wasn't really that useful. I never used it.
IIRC, Unisys's MCP doesn't have directories, just very long file names with separators in them. It's up to the applications to present that as a hierarchical namespace.
Now that I mention it, it'd be interesting to play with Apple's DOS 3.3 (33 char file names) that way.
Yes and but: look up ZCPR/3