John Elliott

> This ability to load child processes and TSRs is mostly owed to the CPU architecture, not to the design of MS-DOS - CP/M-86 had it too.

Did CP/M-86 support child processes though?

Also, did CP/M-86 support TSRs? I thought it supported RSXs which just like CP/M-80 were in a different format and manipulated by different APIs than normal programs, whereas under DOS any program can turn itself into a TSR at any time, you can't tell when you start it whether it is going to turn itself into one (unless you know what its code does, of course)

Looking at https://www.seasip.info/Cpm/bdos.html#144 I see BDOS function 144 (P_CREATE), for creating subprocesses, was implemented on MP/M and Concurrent CP/M – but I don't see any mention of it being implemented on (non-Concurrent) CP/M-86.

CP/M-86 1.1 (but not 1.0) supported BDOS function 47 (P_CHAIN), for launching a new program – but like exec() on Unix, or the BASIC CHAIN statement, it terminated its caller before launching the new program.

That said, PC-DOS/MS-DOS 1.x didn't really support subprocesses either. There was no documented API for creating them. The program loader was actually in COMMAND.COM, and while it called the DOS kernel to allocate memory for a new process (the undocumented API INT 0x21,0x26), COMMAND.COM was responsible for actually loading the .COM or .EXE from disk into the process' memory (including relocating .ees), so creating a child process required duplicating a large part of COMMAND.COM's code. In DOS…

> One could argue DRI bowed out too soon. Then again, it’s questionable whether it would have won against Windows anyway. Microsoft was the larger company and had OEM agreements with all of the major PC makers.

Well, it is also that Windows even at version 1.0 was much more capable than GEM. Better documentation, better tools, better API and better functionality.

GEM was really just a shell over DOS and applications were actually DOS programs that called a special interrupt handler to make API calls. While this allowed any language that could make EXE files and call interrupts to be used to make GEM apps, it also meant that GEM inherited all the limitations from DOS, like the inability to run multiple applications at the same time (DR did eventually make GEM/XM that allowed switching between applications but it was still only one application active at any given time). Windows meanwhile not only could run multiple applications, but it also had a software-based virtual memory system that allowed applications to swap in/out both data and code to fit in the available memory (this required custom compiler support so, unlike GEM, you couldn't use any old compiler but on the other hand it you could make more complex applications).

The GEM API was also very barebones, you could create windows but all you could do with them was to draw inside. Dialog boxes were a completely separate thing that could take a tree of "objects" to draw inside them but even then the functionality was…

There were others too. At least the Olivetti Prodest PC1 [1], which I had, and the Sinclair PC200 [2], which a close friend had. Other friends had the EuroPC, some had the Amstrad 1512 and other different PC compatible boxes.

I remember my PC1 fondly. Well, I still have it. I learned to code in GW-BASIC, Turbo Pascal and C (in that order) with it. I was using it for a long time, until 1997, for serious work (coding and university assignments), when I finally had the money to upgrade to a Pentium PC.

As much as my world was PC-centric, the first time I saw an Atari ST and what it could do, my jaw dropped. I knew of the Amiga from magazines, but the first time I actually saw one was several years later, after I acquired my Pentium PC and I admit it wasn't that impressive then. But still I couldn't help but think: "wow, you had that in 1989?". There was no comparison with the PCs of its time.

[1] https://www.seasip.info/VintagePC/prodestpc1.html

[2] https://en.wikipedia.org/wiki/Sinclair_PC200

> Both MS-DOS and CP/M still had the very clear and almost identical concept of a "file" in the first place.

ms-dos files (after 2.0) were sequences of bytes; cp/m's were sequences of 128-byte 'records', which is why old text files pad out to a multiple of 128 bytes with ^z characters. ms-dos (after 2.0) supported using the same 'file' system calls to read and write bytestream devices like paper tape readers and the console; cp/m had special system calls to read and write those (though pip did have special-case device names). see https://www.seasip.info/Cpm/bdos.html

that is, this

> CP/M (...) instead see[s] "files" as a stream of bytes/words/octets or whatever.

is not correct; cp/m has no system calls for reading or writing bytes or words to or from a file. nor octets, which is french for what ms-dos and cp/m call 'bytes'

admittedly filesystems with more than two types of files (ms-dos 2+ has two: directories and regular files) are more different from cp/m

There are plenty of CP/M simulators for Linux, but they're very niche and hard to find (and use).

I used to do C development for the Z80 using one; it translated CP/M syscalls to Linux ones, and would let me run the CP/M version of Hitech C more or less as if it were native. It worked all right. Hitech C was only a K&R C compiler and didn't produce great code, but it was entirely self-hosted.

The script and emulator I used came from here (look for 'Hitech C on Linux'):

http://uzix.sourceforge.net/uzix2.0/index.php?page=down

...but while searching for that I found this other emulator, which looks a bit more maintained:

http://www.seasip.info/Unix/Zxcc/index.html

The real-mode DOS system call interface is based on loading a function number into the AH register, other arguments in other registers, and calling interrupt 21h. I haven't used CP/M before, but it sounds like the DOS function numbers must be numbered in a similar fashion as their CP/M equivalents.

Edit:

This list of BDOS system calls bears a passing resemblance, based on my foggy memory, to some of the interrupt 21h calls I remember: http://www.seasip.info/Cpm/bdos.html The conventions with arguments in registers is different, however.