Re: [TUHS] Pipes and PRISM

[Richard Salz <rich.salz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3600 bytes --]

The VMS process model is different from Unix; like TOPS-20, it was more a
shared address space. I don't remember details, but I do recall that a
"logout" call in a DCL script logged you out of the system.

Did Softway Systems make kernel changes? I know MSFT's original Posix plan
was to do it all in user-space.  WSL is a Ubuntu port, so if Softway had
kernel changes, I could see how that made things simpler.


On Tue, Mar 1, 2022 at 12:05 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> Last week there was a bit of discussion about the different shells
> that would eventually lead to srb writing the shell that took his name
> and the command syntax and semantics that most modern shells use
> today.   Some of you may remember, VMS had a command interpreter
> called DCL (Digital Command language), part of an attempt to make
> command syntax uniform across DEC's different operating systems
> (TOPS-20 also used DCL).  As DEC started to recognize the value of the
> Unix marketplace, a project was born in DEC's Commercial Languages and
> Tools group to bring the Unix Bourne shell to VMS and to sell it as a
> product they called DEC Shell.
>
> I had been part of that effort and one of the issues we had to solve
> is providing formal UNIX pipe semantics.  They of course needed to
> somehow implement UNIX style process pipelines.  VMS from the
> beginning has had an interprocess communications pseudo-device called
> the mailbox that can be written to and read from via the usual I/O
> mechanism (the QIO system service).  A large problem with them is that
> it is not possible to detect the "broken pipe" condition with a
> mailbox and that feature deficiency made them unsuitable for use with
> DEC Shell.  So the team had me write a new device driver, based
> closely on the mailbox driver, but that could detect broken pipes
> lines UNIX-style.
>
> Shortly after I finished the VMS pipe driver, the team at DECwest had
> started work on the MICA project, which was Dave Culter's proposed OS
> unification.  Dave's team had developed a machine architecture called
> PRISM (Proposed RISC Machine) to be the VAX follow-on.  For forward
> compatibility purposes, PRISM would have to support both Ultrix and
> VMS.  Dave and team had already written a microkernel-based,
> lightweight OS for VAX called VAXeln that was intended for real-time
> applications.  His new idea was to have a MACH-like microkernel OS
> which he called MICA and then to put three user mode personality
> modules on top of that:
>
>     P.VMS, implementing the VMS system services and ABI
>     P.Ultrix, implementing the Unix  system calls and ABI
>     P.TBD, a new OS API and ABI intended to supersede VMS
>
> So I wrote the attached "why pipes" memo to explain to Cutler's team
> why it was important to implement pipes natively in P.TBD if they
> wanted that OS to be a viable follow-on to VMS and Ultrix.
>
> In the end, Dick Sites's 64-bit RISC machine architecture proposal,
> which was called Alpha, won out over PRISM. Cutler and a bunch of his
> DECwest engineering team went off to Microsoft.  Dave's idea of a
> microkernel-based OS with multiple personalities of course saw the
> light of day originally as NT OS/2, but because of the idea of
> multiple personalities, when Microsoft and IBM divorced Dave was able
> to quickly pivot to the now infamous Win32 personality, as what would
> be called Windows NT.  It was also easy for Softway Systems to later
> complete the NT POSIX layer for their Interix product, which now a few
> generations later is called WSL by Microsoft.
>
> -Paul W.
>

[-- Attachment #2: Type: text/html, Size: 4178 bytes --]