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

[John Day]

I don’t know. I thought it about the ugliest thing I had ever seen.

In the systems we knew, the only difference between a process and a procedure was what it returned to. A procedure returned to the same stack, a process returned to a different stack. There was really little difference.

The operation wasn’t called something mundane like ’spawn’ but ‘motherforker’. ;-)

> On Aug 17, 2025, at 14:51, John Levine via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> 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.
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history