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 systems1, which were not based on Unix and didn't support multitasking2.
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.
1 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.
2 The Amiga was released in 1985 and had the
Execute() API for this—it doesn't count, because it's also a multitasking OS.