4 Sep
2017
4 Sep
'17
11:29 p.m.
On 9/3/17, Clem Cole <clemc(a)ccc.com> wrote:
On Sun, Sep 3, 2017 at 11:08 AM, Warner Losh
<imp(a)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.