On 9/3/17, Clem Cole <clemc at ccc.com> wrote:
> On Sun, Sep 3, 2017 at 11:08 AM, Warner Losh <imp at bsdimp.com> wrote:
>>
> ​The fun story on that Warner is after years of dogged defense of RMS, when
> C was written for VMS, Cutler had to add Stream I/O.   The moment is was
> released, much (?most?) of customer base (including a lot of internal folks
> like the compiler runtime and DB folks) switched to using it.   It was so
> much easier.​  I never heard Dave back down, but it I used to smile when I
> saw the statistics.
>
Dave Cutler had left the VMS OS group by this time and was
implementing the VAX Code Generator (VCG) as the back end for DEC's
PL/I and C compilers.  He had to do some fancy footwork with buffering
in the C runtime to implement stream I/O on top of the record-oriented
RMS.  There were plenty of odd edge conditions that couldn't be made
to work properly or efficiently.

The first true stream I/O interface in VAX/VMS was in a device driver
for UNIX-style pipes that I wrote for the DEC Shell product, which was
a Bourne shell implementation for VAX/VMS.  VMS pipes could operate in
either record mode (each QIO write represents a record; each QIO read
returns one record's worth of data) or stream mode (each QIO write is
buffered up as a record until a "write end-of-record" QIO is seen; QIO
reads return the number of bytes requested, or up to the end of a
record, whichever occurs first).

RMS finally got a true stream mode interface circa VAX/VMS version 5,
three releases after the DEC C compiler was first released.

I was once a firm believer in the virtues of a record-oriented I/O
interface such as RMS, but after using UNIX and Linux for several
years I became a convert to stream I/O as the base primitive.  One can
always implement record I/O on top of stream I/O if you want it, but
it's difficult to do it the other way round.

-Paul W.