UNIX History

Skip to first unread message

Patrick A. Fargo

Jan 11, 1984, 3:18:47 PM1/11/84
After reading the various responses to the history of UNIX within and outside
AT&T Bell Laboratories, I decided to provide some other details of the
development inside the labs. I ordered the 2nd PDP 11/70 at Indian Hill
in 1976. I will try to give a list of important changes in perspective.

After development of the first UNIX systems in research, Joe Maranzano
of Murray Hill created a UNIX support group. This group would package,
fix bugs, and enhance the research version periodically. A year after
this new group was formed, Heiz Lacklama and Doug Bayer of Holmdel
modified UNIX for a PDP 11/70 using the 3 memory management registers so
that UNIX ran as a supervisor. This product, called MERT for Mult
Environment Real-Time operating system, was eventually support by the same
UNIX support group.

The third major entry was UNIX/PWD. The programmers workbench contained
programs which controlled remote job entry, and source control. These were
developed at Piscataway N. J. In this time period, new PDP processors such
as the PDP 11/34, and PDP 11/23 and even a PDP 11/55 were released and off-
springs to UNIX developed for them. The PCC (Portable C Compiler) and satellite
library for UNIX was generated and new MINI UNIX products arose. On the
other hand, UNIX for a HONEYWELL and UNIVAC 1100 series was also started.

Around 1978, the UNIX support group in conjunction with a computer task force
decided to support two major releases. UNIX/TS and UNIX/RT. UNIX/TS was USG
UNIX and PWD UNIX combined. The UNIX/RT was basically supported MERT. Columbus
had modifyed a version of MERT extensively, and called their product
CB UNIX. Another version of MERT formed the basis for DMERT, a Duplex operating
system. The thrust of only two supported versions was that UNIX/RT showed
very good promise as being the more used version and anything that could
be done in UNIX/TS would work in UNIX/RT.

The advent of the PDP VAX computer now created four products. UNIX/RT and
UNIX/TS for both PDP 111/70 and VAX 780 computers. In 1979 UNIX/RT was
announced as 1 year to freeze, with UNIX/RT VAX officially dead. The
remaining UNIX/TS VAX was again modified by the Indian Hill computer center
into another product called UNIX/TS Augmented. Finally, the product
internal to AT&T Bell Labs call UNIX/TS was the only major product supported.

I hope this little history was interesting. If you have further questions
I will try and answer them within company constraints.

Patrick A. Fargo

Guy Harris

Jan 11, 1984, 5:27:53 PM1/11/84
Correcting a few typos: "Heiz Lacklama" is actually Heinz Lycklama, now
of Interactive Systems; "UNIX/PWD" is actually PWB/UNIX.

MERT was actually a separate OS from UNIX, which had a UNIX overlay on
top of it (so the first case of putting a UNIX-compatible interface on
top of a different OS was Bell's own MERT!).

In this time period, new PDP processors such as the PDP 11/34,

and PDP 11/23 and even a PDP 11/55 were released and offsprings

to UNIX developed for them.

The 11/55 was just an 11/45 with faster memory and a faster floating point
unit, so the standard UNIX that ran on an 11/45 would run on the 11/55.
The 11/34 and 11/23 would, by and large, run versions of UNIX that ran on
the 11/40, except that they could support the floating point instructions.
(They also had other features, like the 11/34's cache and the 11/23+'s
22-bit UNIBUS, but standard UNIX know about them.)

UNIX/TS was USG UNIX and PWD UNIX combined.

And was derived from a version of UNIX that was mostly Research V7, although
it was, I believe, slightly earlier than the released V7 (it had a V6-ish)
terminal driver, for instance) - the original USG UNIX and PWB/UNIX were
derived from V6 or from V6es later than the released V6 - a set of "50 changes"
that would turn V6 into what was running at Research at the time when the
changes were sent out was done by Ken Thompson, and there was a
"Phototypesetter, Version 7" distribution that contained the "modern"
nroff/troff/eqn/tbl, the "modern" C compiler with "long", "typedef", etc.,
the "modern" linker and archiver, and the Standard I/O library. Most of the
"50 changes" and "Phototypesetter, Version 7" stuff was in PWB/UNIX 1.0.

Another version of MERT formed the basis for DMERT, a Duplex operating

For the 3B20-D; the D stood for Duplex and meant there were two CPUs in a
redundant configuration.

In 1979 UNIX/RT was announced as 1 year to freeze, with UNIX/RT
VAX officially dead.

Just out of curiosity, why was UNIX/RT canned if, as stated earlier, it was
felt that UNIX/RT could do everything UNIX/TS could and more?

The remaining UNIX/TS VAX was again modified by the Indian Hill
computer center into another product called UNIX/TS Augmented.

Was there also *another* UNIX/TS variant called UNIX/TS+ (plus)?

Finally, the product internal to AT&T Bell Labs call UNIX/TS
was the only major product supported.

And was named just UNIX as of release 3.0 (release 3.0.1 was publicly
released as System III); it incorporated stuff from TS Augmented and

Was CB-UNIX based on UNIX or MERT, and how much stuff going into the
mainstream UNIX (S3, S5) came from CB-UNIX?

Guy Harris

Patrick A. Fargo

Jan 12, 1984, 8:06:26 AM1/12/84
Thanks to Guy Harris for the corrections. In response to his other questions:

1). Why was UNIX/RT canned instead of TS? Good question! I believe
because of staffing a choice had to be made. Since DMERT was RT
based and would be supported, USG felt UNIX/TS had more potential
from a computer center standpoint.

2). Was UNIX/TS+ another modified UNIX/TS? Yes, the UNIX/TS Augmented
that I spoke of was actually called UNIX/TS++. Modifications were
made that were mostly hidden from the user interface.

3). What was CB-UNIX based on? CB-UNIX was a modified MERT. The
SCCS project modified extensively, the version of MERT they had.
Later, they incorporated the MERT changes in UNIX/RT releases.
Eventually, an agreement to take the requested CB modifications
into the standard UNIX/RT product was reached and that line of
modified O.S. ceased.

Thanks again for the corrections,

P. A. Fargo
AT&T Bell Laboratories IH

Larry Marek

Jan 12, 1984, 10:53:11 AM1/12/84
This is about as UNofficial as it can be, but from the point of a computer
system ``user'' UNIX/RT was a **PIG**. It may have been great for certain
applications, but it certainly did NOT make a good general time-sharing

Another point is that the whole system was riddled with bugs. I had the
opportunity to work with some of the RT folks (on a few of the bugs) and my
impression was that they were a small group of people that were just
overloaded. Apparently the "management" decision was that RT wasn't worth the
effort to "rescue" it.

Larry Marek


Jan 12, 1984, 12:34:24 PM1/12/84
The story goes that the stuff new to 5.0 (called System V when it
was released to the outside world) was put there to satisfy
the needs of the people at Columbus, who were using UNIX as a base for
writing 'Operations Support Systems', ie. programs to be used by
operating companys in non-programmer environments. They needed things
like shared memory and inter-process communication. Those features
had already been done for CB-UNIX (Whether as part of DMERT or UNIX, I
dont know.) but were re-done but the UNIX Support Group people.
The hope was that the Columbus people would all convert over to 5.0
and efforts could be consolidated. I dont know whether this hope was
realized, I left the Labs about the time this was happening.
Rick Thomas

Patrick A. Fargo

Jan 12, 1984, 12:52:55 PM1/12/84
The point about the performance and reliability of UNIX/RT is well taken,
and I agree. But remember, UNIX/RT (MERT) was in existence about 1 and a half
years less than UNIX/TS. The bug rate was higher, and UNIX/RT performance
was increased dramatically for a few projects at the labs. Overall apprasail
of UNIX/RT by the developers themselves were RT before TS.

Patrick A. Fargo

Jan 13, 1984, 8:11:58 AM1/13/84
A clarification about a statement I made concerning CB-UNIX.
The SCCS project at Columbus was NOT Source Control. It was
short for Switching Control Center System or something like that. Thanks
to Andy for the help.

P. A. Fargo


Jan 13, 1984, 8:53:49 PM1/13/84
CB UNIX was not derived from MERT but grew out of the internal
distributions from the USG (generic 1,2 and 3) (yes thats a new set
of numbers, not to be confused with any of the other UNIX numbering
conventions). The USG 3 system had some of the real time things that
CB wanted and they were incorporated into CB-UNIX. One of the reasons
that UNIX developed quickly and MERT did not was the support/feedback
from the CB Labs. They had some sharp people and a good exchange with
the USG when UNIX was an infant, but grew to love their version of UNIX
and did not swing their applications to MERT/UNIX-RT. I suspect that if
they had, RT might have been a good product but with only a few customers
and an over-burdened support staff RT was put on the shelf.

Any old USGer's care to add to this.

I hope some one is collecting all of this UNIX folklore and plans to
print it paperback.

Jim Farrell
AT&T Bell Labs


Jan 13, 1984, 9:39:34 PM1/13/84
From: Doug Gwyn (VLD/VMB) <gwyn%brl...@BRL-VLD.ARPA>

The UNIX System V IPC was already present in USG UNIX 4.1.
(Not related to 4.1BSD.)
It appears to me that these features must have been in UNIX/RT.


Jan 13, 1984, 10:01:43 PM1/13/84
From: Doug Gwyn (VLD/VMB) <gwyn%brl...@BRL-VLD.ARPA>

Guy Harris has given much more accurate UNIX history notes than most
of what has filtered into the ARPAnet on this topic. I would like to
add a couple of comments:

It was fairly easy to take the 6th Edition UNIX 11/45 floating-point
processor (FP11) support and add it into the 11/40 version for a
PDP-11/34. One subtle problem with using the 11/40 kernel on an 11/34
is that the faulted-instruction restart code was not entirely correct
for the 11/34, although later the 11/23 was again 11/40-compatible in
this regard. The 6th Edition UNIX floating-point support also had
some bugs that needed to be fixed if one was going to make heavy use
of floating-point on an 11/34 or 11/23, as we did at Geotronics Corp.

The most important Columbus product to appear in USG UNIX would
probably be the augmented "make", which is much nicer than the
7th Edition UNIX version, although still not perfect.

All it takes to make UNIX quite usable for real-time data acquisition
(1) plock(2) or equivalent to ensure that user-mode code is
memory-resident when needed.
(2) strict priority scheduling, which can be as simple as
adding a privileged "real-time process queue" to the
existing scheduler.
(3) data acquisition device driver and user-mode dual-buffered
program that cooperate nicely.
One of the past USENIX tapes contained Geotronics contributions for
items (1) and (2) for 6th Edition UNIX. John Quarterman, now with the
University of Texas Dept. of CS, did a really nice job of making (3)
work for the proprietary 11/23-based system used in the field by
Geotronics Corp.


Jan 15, 1984, 5:15:02 AM1/15/84
From: Ron Natalie <ron@brl-vgr>

Guess again guy, there is no such thing as a 22 bit UNIBUS.
23's have Q-Buses. 24's have unibuses. The 23+ was a documented
processor with 22 bit addressing (those of us with plain 23's found
that they were inherently 22 bits two and it was easy to make us
of it.


Guy Harris

Jan 15, 1984, 1:57:00 PM1/15/84

The UNIX System V IPC was already present in USG UNIX 4.1.
(Not related to 4.1BSD.)

For you real UNIX trivia freaks, the USG 4.0 IPC was different
from the USG 4.1 IPC. The original message send/receive system calls sent
to a process ID; they were changed to send to message queues, which had a
32-bit unique ID, instead (which makes more sense, as it permits you to
transparently replace servers). (It might be interesting to see how many
changes to the Berkeley IPC mechanism would be needed to provide yet another
domain which provides compatibility with the S5 IPC mechanism; obviously,
the socket addresses would be the unique IDs. The trick is that the S5
messages have a "long" which is a "message type", and the S5 "msgrcv"
call can ask to be delivered only messages of a certain type, or messages with
a certain type number or lower number. Also, message queues (and other
"IPC objects") have an owner UID, owner GID, and permission bit set
associated with them.) The semaphore code was also very different (it may
have been descended from semaphore code done for the pre-UNIX/TS USG systems),
and the shared memory code was the MAUS code which used a dedicated part
of physical memory for the shared space. The history of Bell UNIX IPC
mechanisms looks rather multi-branched; anybody out there with the full

It's also interesting to see mention of various such branches in the BSTJ
issue on UNIX (the July-August 1978 issue, Vol. 57, No. 6, Part 2). They
make casual reference to "the UNIX interprocess message facility", "the
semaphore capability of the UNIX system", and to "run levels" in "the standard
UNIX 'init' program" in the article on the Network Operations Control System,
and also describe the MAUS shared-memory facility which was originally done
for that system. (Another aside: the MAUS was credited to Dale DeJager
and R. J. Perdue; I remember seeing some code from Gould which was part of
their driver and support code for their 5000 series electrostatic printer-
plotter for DEC systems which was also credited to R. J. Perdue - was this
the same guy?) A lot of those features probably came out of Columbus but
never made it into the UNIXes released to the outside world until System III
(the 'init') or System V (the messages and semaphores). Andy Tannenbaum sent
me a "man" page for an "init" from a pre-UNIX/TS USG system which also had
the run levels, and Hal Pierson (ex-Labs, now working here) mentioned that
they had done both a semaphore system and the run-level based 'init' for a
system they did which collected output from the console terminal ports of
Electronic Switching Systems processors and allowed "craftsmen" (which I
think is AT&Tese for "field engineer") to peruse that output for maintenance
purposes. They also realized that these craftsmen wouldn't know an inode if
it came up and bit them in the *ss, so they had to replace "icheck" and "dcheck"
with a new program which would do most of the dirty work of file system repair
for them - Hal wrote one called "fcheck", which cleaned V6 file systems, and
which appeared in source-code form on the PWB/UNIX 1.0 distribution tape.
Unfortunately, PWB/UNIX 1.0 modified the V6 file system so that it didn't
support "huge" files, and the eighth indirect pointer pointed directly to
a block as the other seven did, so the "fcheck" there wouldn't fix a vanilla
PWB/UNIX file system, but it worked just fine on a vanilla V6 FS. When I
discovered it, quite by accident, I looked at it and it sure looked like
a super-duper file system fixer; once we got it up, we never went back to
"icheck" and "dcheck" again. Later on, of course, Ted Kowalski rewrote it
to work on a V7 filesystem, added some extra checks, gave it the ability
to reconnect files with no directory entries, put comments into the
code (something Hal still has trouble doing :-)), cleaned it up some, and
renamed it "fsck".

It appears to me that these features must have been in UNIX/RT.

MERT had its own set of new features, including yet *another* message facility
which didn't look like any of the "Ken&Dennis-derived" UNIX systems'
facilities, but I don't know what they did in UNIX/RT.

A lot of source material is in the BSTJ UNIX article, and may appear in some
issues of Bell Labs' "UNIX Systems Newsletter" which was distributed to
UNIX sites within AT&T & operating companies.

Anybody for a "net.unix.history" newsgroup - at the end of the year, maybe
we gather up all the articles, give them to some editor (maybe Dennis, who
certainly doesn't have anything more important to do :-)) who can cull out
the chaff, and publish it somewhere?

Guy Harris

Guy Harris

Jan 16, 1984, 3:01:13 PM1/16/84
Sorry, I should have said "the 11/23+'s, 11/24's, and 11/44's 22-bit address
space without a 22-bit I/O bus"; standard V7 and S3 assume that if you have a
22-bit memory space you have a MASSBUS.

Guy Harris


Jan 16, 1984, 8:20:17 PM1/16/84
A correction to the comment on the source of CB-UNIX.
I was the supervisor of the group in Columbus for a number of years that was
responsible for the development of CB-UNIX. The system was derived
from the UNIX operating system that was used in the SCCS (Switching
Control Center System), which incidentally was the first application
of UNIX outside of research. (UNIX was running on an 11/20, at the time,
without memory management and we deployed the first version of SCCS
in New Jersey Bell in New Brunswick, NJ.)

The SCCS version of UNIX had a number of unique features for the times:
semaphores and line disciplines (in 1974!) for example. Hal Pearson
was responsible for semaphores, and Bill Snider for line disciplines.

Messages and shared memory were first added to CB-UNIX in about 1975 or
1976. Shared memory was called MAUS (pronounced moss, standing for
Multiple Access User Space) and was derived from an earlier version
done by R. J. Purdue. CB-UNIX became rather widely accepted within BTL
as a base for turnkey Operations Systems--many of which have been
described in the BSTJ. Note that CB-UNIX was not a derivative of UNIX/RT, but
of Version 6 and Version 7. PWB UNIX was also a derivative of Version 7.
USG UNIX was originally a derivative of Version 6 and 7 with some CB-UNIX
facilities added. Eventaully a decision was made to consoldate to two
versions of UNIX: UNIX/TS and UNIX/RT. RT was a derivative of MERT, and
TS a derivative of PWB UNIX. RT was to be used by Operations Systems, but
was never too widely accepted. Eventually, UNIX/TS was augmented to have
many of the features present in CB-UNIX (this was done by Roger Faulkner
at Indian Hill, BTL. This, in turn, became the base for UNIX 4.0, which
was never released externally. While this augmentation was going on, UNIX/TS
was being changed into UNIX 3.0 which was release externally as SYSTEM III.

In more recent history, CB-UNIX has been eliminated entirely in favor of
UNIX 5.0. (one reason is because it never ran on anything other than the 11/70)

I once had a viewgraph with all this on it which I had great fun trying to

Now for trivia: How many know where in UNIX lore you would find the following
quote: "Values of beta will result in dom!"

Dale DeJager
AT&T Information Systems
Lincroft, N.J.

Jim Crandell

Jan 24, 1984, 6:42:19 PM1/24/84
>Now for trivia: How many know where in UNIX lore you would find the following
>quote: "Values of beta will result in dom!"

Sooner or later, in /usr/games/lib/fortunes.dat .
Jim ({ihnp4,kpno,ut-ngp}!ut-sally!crandell or cran...@ut-sally.UUCP)


Jan 27, 1984, 5:49:16 PM1/27/84
Nope, the place in /usr/lib/games.... got it from somewhere earlier
in UNIX history.
Reply all
Reply to author
0 new messages