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

[Steve Crocker]

ITS was super efficient in creating subordinate processes.  I don't
remember the details.  Have someone who was involved join the conversation.

Steve

Sent by a Verified

sender


On Sun, Aug 17, 2025 at 2:51 PM 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
>