Early implementations of the `system()` call in a consumer OS

Question

Nowadays, it's easy to take for granted the system() call (as defined in POSIX), which allows a user program to easily execute a child process and wait for it to complete. Obviously, this is a trivial (and useful!) API to implement on a multitasking OS, such as the original Unix. I'm curious about the same capability being available to applications running on early consumer operating systems¹, which were not based on Unix and didn't support multitasking².

I would stipulate that the OS would need to provide an API that makes it just as trivial to invoke a child process as the system() call. Therefore, it would also transparently protect the memory of the calling program from being corrupted by a well-behaved child process (not meaning hardware enforced protected memory here). Multitasking systems have a general approach to sharing memory. This would, I assume, be a more limited mechanism that restores memory to the way it was when the call returns to the parent.

Did such an API exist on early single-tasking OS's like CP/M, DOS, MacOS, Atari TOS, etc.? Is there a more obscure consumer system with OS that provided it earlier?

¹ I'm talking about an OS for a low-cost "personal computer" as one might have found in common use by small business or home computer hobbyists.

² The Amiga was released in 1985 and had the Execute() API for this—it doesn't count, because it's also a multitasking OS.

Answer 1

MS-DOS allows an application to invoke a nested application. Processing of the former application will be suspended until the latter application returns, whereupon the former application will continue following the function call that invoked the other application.

The way this typically worked revolved around the fact that MS-DOS programs may be easily relocated to any 16-byte boundary when they are loaded, and often use storage near the end of their code space before they use storage that's higher up. Launching a nested application simply involves having it invoked with its "low-water mark" set to equal the parent program's "high-water mark".

MS-DOS 2.0 (October 1983) and later provided this as a system call, interrupt 0x21 service 0x4B. Prior to that, program loading had to be implemented manually, albeit with some help from interrupt 0x21 service 0x26 to create a PSP; see COMMAND.COM’s implementation for one example (this was trivial for .COM-style programs, more complex for MZ programs). Programming environments typically provided their own wrappers for service 0x4B; see for example Turbo C’s spawn functions, or GW-BASIC’s SHELL statement.

Answer 2

All versions of Atari's GEMDOS (first released in 1985) supported Pexec(). Flags permitted launching the child process and waiting for it to finish, or merely loading the child into memory (for overlays and debugging).

Answer 3

Since you mentioned CP/M: At least in its original 8080 incarnation, CP/M does not have any system call that allows a program to launch another and regain control when the program it launched terminates. Under CP/M-80, programs are assembled to run at address 0100h, so loading the 'child' process would inevitably overwrite the memory of the 'parent'. While it's possible to imagine workarounds (such as the 'parent' process relocating itself higher in memory and reporting a reduced memory size to the 'child') there is no simple system call that does this.

The closest approximation is the P_CHAIN call under CP/M 3, which takes a command line and executes it as if typed at the A> prompt. However this terminates the calling program before executing the command, for the reason given above.

Answer 4

The Cambridge Z88 (1987) has a number of system calls that allow it to

• enumerate installed programs on inserted flash cards in its 4MB address range
• Select one of the enumerated applications to run
• create and forward "Mailbox content" to applications being run (which can contain a "come back to (and restart) me after done")

So, essentially, all functions required to implement a system() call functional equivalent are present. It's obviously not presented as a POSIX-compliant implementation, though.

Answer 5

I'm not sure that it would have been useful on Mac OS unless you were writing a launcher in the brief period before the MultiFinder as applications always present at least some UI and do not exit of their own volition.

With System 7 Apple introduced AppleScript, which allows applications to expose scriptable actions and thereby allows a third-party application to interface with a scriptable application e.g. to open an audio editor, ask it to open a file, delete the first five seconds, normalise audio elsewhere, save and exit. But that's in the era where cooperative multitasking was enabled for all, rather than being a third-party extension (prior to System 5) or optional (in Systems 5 and 6).