[TUHS] History of non-Bell C compilers?

[Paul Winalski]

On 3/11/24, Peter Yardley <peter.martin.yardley at gmail.com> wrote:
> I used the DEC VMS C compiler extensively while I was at NSWIT. I ported a
> lot of Berkley (I think) C code to VMS. Some of their VLSI design suite, KIC
> etc. There weren’t a lot of changes to make, the compiler and library was
> pretty K&R from what I remember. The usual small header issues applied

The developers of the original DEC VMS C compiler took great pains to
be K&R-friendly by default.  There was a strict ANSI C option
available.

There later was a later, C89 compiler produced by Dave Cutler's
DECwest engineering team in Seattle.  I think it ran on Unix as well
as VMS.  It enforced the C89 standard very strictly--no option for
relaxations or extensions and no K&R compatibility.  One customer
described it as the Rush Limbaugh of C compilers--extremely
conservative and you can't argue with it.

> VMS IO is a bit different from UNIX IO

Understatement of the century.  :-)

>  but they had a mode (stream I think)
> that meant minimal changes to UNIX code.

VMS's device-independent I/O layer is called Record Management
Services (RMS) and as its name implies it is record-oriented.  They
did eventually add a stream mode to RMS, but that didn't happen until
well into the 1990s.  When DEC C for VMS first came out (ca. 1980)
there was no stream mode in RMS.  The C RTL had to implement stream
I/O as a layer on top of RMS.  It's fairly easy to build
record-oriented I/O on top of stream I/O but it's very difficult to do
it the other way around.  At first release the VMS C RTL's I/O had a
lot of buggy edge conditions.  It took them several releases to get
the I/O working properly.

Circa 1985 there was a port of the Bourne shell to VAX/VMS.  It of
course needed pipes, and I wrote a pipe pseudo-device driver for VMS.
It supported both stream and record read and write operations.

-Paul W.