Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help][Flex-devel] fix compiler warning]

[Brian D. <br...@de...>]

Keith Marshall wrote:

> This just serves to illustrate how poorly the guys at Microsnot
> understand process management.  The only mitigating factor is that, in

Now that's just a ridiculous statement to make.  There's nothing that
says process management requires the ability to replace one process with
another.  It is nice to have if you have an intention to port software
that originates from the C/Unix tradition, but it is in no way
indicative of poor design, just different design.

And you can't blame this on Microsoft at all.  VMS worked in a very
similar way.  It had no true fork() but a vfork()-like thing wherein
calling fork() simply reserves space for a child process but does not
actually create one.  Control flow continues in the parent but with a
fork return value of 0, a codepath normally taken by the child.  This is
where you might typically close fd's or drop privileges before exec()ing
the child, but it's impossible here since this is still the parent. 
This state continues until exec() is called, at which point the  spawned
process is actually created and starts running.  Control in the parent
then jumps back to where fork() returned, but this time with the PID as
return value.

VMS does have the ability to replace a running process with another
without changing PIDs, but there is no way to pass command line
arguments.  There is a shared/common memory buffer area, and the two
processes can theoretically communicate arguments that way, but there's
no defined protocol so they'd both have to know to look there.  Thus
it's not a very useful and not recommended.

Anyway, the point here is that process management in VMS was always
designed in the "spawn new from scratch" mindset, not the "duplicate
then replace", exactly as Windows is today.  And that's no coincidence
because in 1988 when Microsoft was looking for an architect to lead the
design of their new NT operating system, they hired Dave Cutler from DEC
who was also the original architect of VMS.

If you think about that for a moment, Microsoft presented him with what
nearly every software person dreams of: "You've already designed and
maintained a large, successful, and robust operating system, now do it
all over again but this time you can start from scratch without any
backwards compatibility headaches, and you can apply everything you
learned the first time around."  Such a chance doesn't happen that often
- another example would be Dennis Ritchie and Plan 9 for Bell Labs.  I
guess what I'm getting at here is that Cutler is a pretty sharp guy and
to carry this aspect of process management over into NT would seem to
indicate that after all of those years of experience with VMS there was
no sense of inadequacy.

Brian