The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: paul.winalski@gmail.com (Paul Winalski)
Subject: [TUHS] Line Terminators in Text Files [
Date: Mon, 4 Sep 2017 13:29:59 -0400	[thread overview]
Message-ID: <CABH=_VS8TNJSStmgSyT9xifbqtbsWQqN_0XaPss2oVwJn3B=8Q@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2MbSa3YxkkKdYUj01R0C-cnm0Bv6d+dAsBtEhHCegL4Qw@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

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.


  parent reply	other threads:[~2017-09-04 17:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-03 20:06 Clem Cole
2017-09-03 21:42 ` Warner Losh
2017-09-04 17:29 ` Paul Winalski [this message]
2017-09-04 18:34   ` Clem Cole
2017-09-04 20:28     ` ron minnich
2017-10-01 17:24   ` Tom Ivar Helbekkmo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABH=_VS8TNJSStmgSyT9xifbqtbsWQqN_0XaPss2oVwJn3B=8Q@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).