[ih] Where's Multics now, was Internet-history Digest

[John Levine]

It appears that Dave Crocker via Internet-history <dcrocker at bbiw.net> said:
>On 8/17/2025 10:56 AM, John Levine via Internet-history wrote:
>> Huh?  Windows NT was widely reported to be the seconf coming of VMS
>> and that's what's still inside Windows 11.
>
>Exactly.
>
>I forgot to connect the dots:  Multics -> VMS -> Windows.
>
>The major point of continuity that I know about is the cost of 
>sub-processes.  In unix, it's cheap.  In the other approach, it is very 
>expensive.  (No, I don't remember or know enough detail to fill this in 
>adequately for a technical audience.)

One of the underappeciated innovations in Unix was to split process creation
into fork() and exec() rather than a single spawn() call. Opening and closing
files and moving file descriptors are done with normal I/O calls rather than
needing a zillion spawn() options.

When a process did a fork() it bascially swappped out the process' address
space, assigned the swapped copy to the old process, left the swapped in copy in
the new process, and just incremented the counts on all the open files. The bit
that made two copies of the kernel context had the comment "you are not supposed
to understand this".

These days fork() isn't as simple as it used to be since a process typically
has several shared libraries each with R/O and R/W pages but it is still a
lot simpler than posix_spawn().

3BSD had the ugly vfork() kludge which, observing that most fork() calls are
soon followed by exec(), pauses the parent process and gives the address space
to the child until it calls exec() or exit(). 

I believe the motivation was that the VAX-11/750 had microcode bugs that made
read-only stack pages and hence copy-on-write sttacks not work. DEC declined to
fix it since it didn't affect VMS. The sensible approach would have been to make
the shared stack pages copy-on-touch rather than copy-on-write, which would have
preserved fork() semantics at little extra cost, but nooooo ....

R's,
John

PS: TENEX had a fork call but I believe that the usual way to create
a process was for the parent to create the fork, then do calls to
manage the child including mapping in the other program and then
start it.  One option was a Unix style fork with shared copy-on-write
pages but I don't know how much people used it that way.  I also didn't
see any reasonable equivalent of exec(), for a process to whomp another
program on top of itself.