A Short History of CP/M-86
47 points
5 days ago
| 2 comments
| abortretry.fail
| HN
chasil
4 days ago
[-]
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."

https://en.wikipedia.org/wiki/CP/M

reply
pavlov
3 days ago
[-]
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.

reply
gattilorenz
3 days ago
[-]
> 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.

reply
ghaff
3 days ago
[-]
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.
reply
dfawcus
3 days ago
[-]
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).

reply
nickdothutton
3 days ago
[-]
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.
reply
ghaff
3 days ago
[-]
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).
reply
rbanffy
3 days ago
[-]
> 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.

reply
forinti
3 days ago
[-]
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.

reply
rbanffy
3 days ago
[-]
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.

reply
browningstreet
3 days ago
[-]
Yes and but: look up ZCPR/3
reply
cmrdporcupine
4 days ago
[-]
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

reply
chasil
3 days ago
[-]
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).

https://en.wikipedia.org/wiki/Corel_Ventura

reply
rbanffy
3 days ago
[-]
Notably, back then you couldn't get GEM on a PC without it being bundled with another program.
reply
cmrdporcupine
3 days ago
[-]
Atari shipped a PC clone that came with GEM + GEM Desktop
reply
rbanffy
1 day ago
[-]
But that was the 2-window GEM desktop, right?
reply
kabdib
3 days ago
[-]
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.

reply
cmrdporcupine
3 days ago
[-]
Thanks for chiming in. Always appreciate your recollections.
reply
95014_refugee
3 days ago
[-]
... and the open-source clone (EmuTOS) has been widely ported since.
reply