pat@ih1ap.UUCP (Patrick A. Fargo) (01/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@rlgvax.UUCP (Guy Harris) (01/12/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
system.
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
TS+.
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
{seismo,ihnp4,allegra}!rlgvax!guypat@ih1ap.UUCP (Patrick A. Fargo) (01/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@ihuxf.UUCP (Larry Marek) (01/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 system! 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 ihnp4!ihuxf!larry
usenet@abnjh.UUCP (usenet) (01/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
pat@ih1ap.UUCP (Patrick A. Fargo) (01/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.
pat@ih1ap.UUCP (Patrick A. Fargo) (01/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 BTL -IH
jimjwf@mhtsa.UUCP (01/14/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
gwyn%brl-vld@BRL-VLD.ARPA (01/14/84)
From: Doug Gwyn (VLD/VMB) <gwyn%brl-vld@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.
gwyn%brl-vld@BRL-VLD.ARPA (01/14/84)
From: Doug Gwyn (VLD/VMB) <gwyn%brl-vld@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 is: (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.
ron%brl-vgr@sri-unix.UUCP (01/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. -Ron
guy@rlgvax.UUCP (Guy Harris) (01/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
story?
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
{seismo,ihnp4,allegra}!rlgvax!guyguy@rlgvax.UUCP (Guy Harris) (01/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
{seismo,ihnp4,allegra}!rlgvax!guydale@lzmi.UUCP (01/17/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 explain. 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.
crandell@ut-sally.UUCP (Jim Crandell) (01/25/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 crandell@ut-sally.UUCP)
chinn@butler.UUCP (David Chinn) (05/31/86)
Sorry if this has been asked before....
Could anyone give me a short run down on lineage
of the major lines of UNIX? Perhaps a brief narration
or a family tree showing how sys V and 4.3 and such
are all related. I am primarily interested in AT&T and
Berkley, VAXEN and PDP's; where do 3b2 and 2.9 fit in?
Thanks in advance;
... uw-beaver david m chinn
!tikal!dataio box 639
!butler!chinn redmond, wash 98073henry@utzoo.UUCP (Henry Spencer) (06/06/86)
> Could anyone give me a short run down on lineage > of the major lines of UNIX? Perhaps a brief narration > or a family tree showing how sys V and 4.3 and such > are all related... If you want a *very* brief version, draw a line of development marked "V1" through "V8". Between V6 and V7, draw a branch starting out "PWB" and proceeding on through "SysIII" and "SysV" to "SysV.3.2.4.etc". Between V6 and V7, draw another branch starting out "1BSD" and going on to "2BSD" and "2.nBSD". Draw a branch from V7 and another from somewhere in the 2.xBSD series, and merge them into a line starting "3BSD" and going on into the 4BSD series. That's roughly right. Then cover the whole drawing with a dense tangle of lines indicating variants, independent sub-lines of development, and cross-fertilization in various directions. There were several *major* independent lines (tangles) of development within AT&T alone. Some friends of mine tried to draw up an accurate family tree; it took them a long time and considerable research and there were still gray areas and question marks. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
mrl@oddjob.UUCP (Scott R. Anderson) (06/10/86)
In article <6780@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> Could anyone give me a short run down on lineage >> of the major lines of UNIX? Perhaps a brief narration >> or a family tree showing how sys V and 4.3 and such >> are all related... > >Between V6 and V7, draw a branch starting out "PWB" and >proceeding on through "SysIII" and "SysV" to "SysV.3.2.4.etc". This raises the burning question: whatever happened to Systems I and II, and, especially, IV? I never hear them discussed. Were they ever released commercially, and if not, why not? -- Scott Anderson ihnp4!oddjob!kaos!sra
matt@saber.UUCP (Matt Perez) (06/11/86)
> > This raises the burning question: whatever happened to > Systems I and II, and, especially, IV? I never hear them > discussed. Were they ever released commercially, and if > not, why not? > > Scott Anderson > ihnp4!oddjob!kaos!sra System IV was in use within the Labs in (memory don't fail me now) the latter part of 1980. It was never released commercially because as SIV was released, SV was already targeted to be the system that was going to be released within and without Ma Bell at the same time. Up until then, a system was released in-house and external release would lag for as much as a couple of years or not at all. I know somebody who ran SI and SII at Teletype in or around 1978-1979. -- {amd,att,cbosgd,calma,cayuga,dual,idi,ihnp4,intel,imagen,nsc,qubix,qumix,sun,wamo,wcwvax,weitek}!saber!matt
sbs@valid.UUCP (Steven Brian McKechnie Sargent) (06/14/86)
> In article <6780@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >> Could anyone give me a short run down on lineage > >> of the major lines of UNIX? Perhaps a brief narration > >> or a family tree showing how sys V and 4.3 and such > >> are all related... > > > >Between V6 and V7, draw a branch starting out "PWB" and > >proceeding on through "SysIII" and "SysV" to "SysV.3.2.4.etc". > > This raises the burning question: whatever happened to > Systems I and II, and, especially, IV? I never hear them > discussed. Were they ever released commercially, and if > not, why not? > -- > > Scott Anderson > ihnp4!oddjob!kaos!sra If memory serves, what you call Systems I and II existed as versions of the UNIX Time Sharing System and the Programmer's Workbench system (versions 1.0 and 2.0). System III was made commercially available about 1981, during which time System IV was in use inside the phone company -- but at the same time that 4BSD was in its first blush of youth. So they leapfrogged IV altogether, presumably to avoid confusing the UNIX(TM)-buying public. Friends tell me there is also a System VI, which has been ruthlessly crushed for internal political reasons; but that's vicious rumour. The 8th Edition system is based on 4.1BSD, and I hear there's a Version 9 as well; so I think we've gotten the 1-digit numbers pretty well nailed down and bleeding, and the phone company will iterate forever on the System V.3.1.4a.870422.9:33:04am.Rev3 naming scheme. "After changes upon changes we are more or less the same." - Paul Simon S. (TM) UNIX is a Footnote of AT&T Bell Laboratories.
larry@geowhiz.UUCP (Larry McVoy) (06/14/86)
In article <6780@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> Could anyone give me a short run down on lineage >> of the major lines of UNIX? Perhaps a brief narration >> or a family tree showing how sys V and 4.3 and such >> are all related... > >If you want a *very* brief version, draw a line of development marked "V1" >through "V8". Between V6 and V7, draw a branch starting out "PWB" and [etc, etc] The best picture I've seen is by John Quartermain (sp?) in the chapter on Unix in the *second* edition of the Peterson & Silberschatz book "Operating System Concepts". I think it's just what the patient ordered. -- Larry McVoy ----------- Arpa: mcvoy@rsch.wisc.edu Uucp: {seismo, topaz, harvard, ihnp4}!uwvax!geowhiz!larry "Just remember, wherever you go -- there you are." -Buckaroo Banzai
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/15/86)
Various people have been putting forth misleading or incorrect speculations about releases/versions of UNIX. Unless you were DIRECTLY involved with the development of UNIX, please cut it out.
mike@whuxl.UUCP (BALDWIN) (06/16/86)
> Friends tell me there is also a System VI, which has been ruthlessly > crushed for internal political reasons; but that's vicious rumour. System VI is really System V Release 2.0. The naming convention was changed to "nail down" the System V part. Some SVR2 code still has 6.0 embedded in the comments. > The 8th Edition system is based on 4.1BSD, and I hear there's a Version > 9 as well; so I think we've gotten the 1-digit numbers pretty well > nailed down and bleeding, and the phone company will iterate forever on > the System V.3.1.4a.870422.9:33:04am.Rev3 naming scheme. I haven't heard of any 9th Edition; the System V numbering should be standardized now on Release numbers. Release X.Y.Z is major release X, enhancement Y, bug-fixes Z. > (TM) UNIX is a Footnote of AT&T Bell Laboratories. Oops! UNIX is now a *registered* trademark of *AT&T*. (No Bell Labs anymore) -- Michael Baldwin (not the opinions of) AT&T Bell Laboratories {at&t}!whuxl!mike
henry@utzoo.UUCP (Henry Spencer) (06/17/86)
> This raises the burning question: whatever happened to > Systems I and II, and, especially, IV? ... Adam Reed and Matt Perez have already answered this moderately well, but I'll throw in a few more tidbits. System I was, approximately, PWB, which was released. System II was an improved PWB, incorporating some useful things like a souped-up shell; it was never released because just then AT&T was not sure it wanted to continue distributing useful new goodies to potential competitors. After the decision to continue with distribution was made, System III was released, well after it was in use internally. System IV never made it out because it was already in use when SysIII came out, and the decision to bring external releases into sync with internal ones overtook it. System V was then released. Since "System V" has now become a magic marketing buzzword, the top-level numbering is absolutely frozen for external purposes, and all future releases will be V.something rather than VI, VII, etc. Fortuitously, this happens to avoid 4, 6, and 7, which correspond to other well-known flavors of Unix. If you want to get a look at what System IV was like, check out the PDP11 distribution of System V. PDP11 SysV is really SysIV. Although AT&T won't admit it in so many words, they effectively abandoned work on PDP11 Unix a long time ago. For example, although some of the SysV performance work wouldn't fit on the 11, *some* of it would. None of it was applied to PDP11 SysV. The PDP11 SysV shared-memory stuff is also different from and incompatible with the regular SysV version. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
hfavr@mtuxo.UUCP (a.reed) (06/17/86)
> This raises the burning question: whatever happened to > Systems I and II, and, especially, IV? I never hear them > discussed. Were they ever released commercially, and if > not, why not? > Scott Anderson > ihnp4!oddjob!kaos!sra System numbers correspond to releases standardized by the Bell Labs' UNIX Support Group (USG) and its successor organization in AT&T IS Computer Systems Division. Roman numbers are used for external releases and arabic numbers for the corresponding internal releases. There were no external releases corresponding to USG internal systems 1, 2, and 4. USG System 4 did not have enough functionality beyond that available in USG System 3/III to justify a separate external release. Adam Reed ihnp4!npois!adam
ka@hropus.UUCP (Kenneth Almquist) (06/19/86)
> > This raises the burning question: whatever happened to > > Systems I and II, and, especially, IV? ... Back in 1978, I think it was, a grand new numbering scheme for UNIX releases put out by USG was devised. Release numbers were set back to 1.0 and the operating system was renamed UNIX/TS. (The "TS" stands for time sharing.) At the same time, MERT, a different operating system whose primary use was to run a UNIX emulator, was renamed UNIX/RT (the "RT" stood for real time) and also had its release numbers set back to 1.0. The idea was that com- patable releases of UNIX/TS and UNIX/RT would have the same release numbers. UNIX/RT proceeded to bite the dust and the name of UNIX/TS gradually shifted back to plain "UNIX". USG started producing top level releases once a year. Second level releases were used to make features available as they were written. Third level releases were limited to bug fixes. For example, UNIX 3.0 was followed by UNIX 3.0.1, which was basicly UNIX 3.0 with a few bug fixes. (It was also followed by UNIX 3.1, which may or may not have come out before UNIX 3.0.1.) The first two versions of USG UNIX that were release externally to AT&T were UNIX 3.0.1 and UNIX 5.0.1. They were called System III and System V externally. There were no systems named System I, II, and IV. > System I was, approximately, PWB, which was released. PWB UNIX was not developed by USG. One of the goals enunciated in the switch to the new release naming scheme was to eliminate the various special versions of UNIX floating around. SCCS was included in UNIX/RT 1.0. The PWB code didn't make it into USG UNIX until release 2.0. I don't know much about the version of PWB UNIX that was released externally, but I think that predated UNIX/TS 1.0 significantly, so there were probably UNIX/TS 1.0 features not in the external version of PWB UNIX, as well as vice versa. > System II was an improved PWB, incorporating some useful > things like a souped-up shell. The Borne shell (which was in UNIX/TS 1.0) did not undergo any major changes between UNIX/TS 1.0 and UNIX 5.0. > Since "System V" has now > become a magic marketing buzzword, the top-level numbering is absolutely > frozen for external purposes, and all future releases will be V.something > rather than VI, VII, etc. The real horror is that the internal numbering system has been abandoned, so that even those of us inside AT&T have to suffer with names like "System V Release 2 Issue 2". Does driving people up the wall with a chaotic numbering scheme really encourage them to buy from AT&T? > If you want to get a look at what System IV was like, check out the PDP11 > distribution of System V. PDP11 SysV is really SysIV. Not really. > Although AT&T won't admit it in so many words, they effectively > abandoned work on PDP11 Unix a long time ago. Most new features made it to the PDP11. The major exception is the news object module format, which makes SDB possible. SDB is a UNIX 3.0 feature which did not make it to the PDP11. The UNIX 4.0 and UNIX 5.0 releases for the PDP11 were pretty complete. > For example, although some of the SysV performance work wouldn't fit > on the 11, *some* of it would. None of it was applied to PDP11 SysV. The PDP-11 uses hashing to implement the sleep/wakeup facility in the kernel under System V. I don't know of any other System V performance work that was applied to the PDP11 (but then if it had been it would probably would not have helped a machine the size of a PDP-11 much.) > The PDP11 SysV shared-memory stuff is also different from and > incompatible with the regular SysV version. Right, but it is present, which is a difference from UNIX 4.0. The IPC stuff was first released in UNIX 4.2. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path)
guy@sun.UUCP (06/21/86)
> I don't know much about the version of PWB UNIX that was released > externally, but I think that predated UNIX/TS 1.0 significantly, so there > were probably UNIX/TS 1.0 features not in the external version of PWB UNIX, > as well as vice versa. The PWB/UNIX that was released externally was PWB/UNIX 1.0, which was a V6-flavored system, rather than a V7-flavored system like the UNIX/TS line. > Most new features made it to the PDP11. The major exception is the news > object module format, which makes SDB possible. SDB is a UNIX 3.0 feature > which did not make it to the PDP11. The UNIX 4.0 and UNIX 5.0 releases > for the PDP11 were pretty complete. No; 3.0 had an object file format of the same flavor as that used by Research UNIX, and it supported "sdb" by adding the N_STAB symbol table entry type to hold debugger information. The way the N_STAB symbols were used, however, didn't support the new rules for structure member names, and didn't support some other things. The COFF debugger symbols do, so "sdb" was fixed to support them. I suspect the PDP-11 didn't support "sdb" either because 1) nobody bothered changing the Ritchie compiler to generate N_STAB entries or 2) there wasn't enough address space to support it. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
mash@mips.UUCP (John Mashey) (06/21/86)
In article <513@hropus.UUCP> ka@hropus.UUCP (Kenneth Almquist) writes: >.... generally accurate description of release history... > >PWB UNIX was not developed by USG. One of the goals enunciated in the >switch to the new release naming scheme was to eliminate the various special >versions of UNIX floating around. SCCS was included in UNIX/RT 1.0. The >PWB code didn't make it into USG UNIX until release 2.0. > >I don't know much about the version of PWB UNIX that was released externally, >but I think that predated UNIX/TS 1.0 significantly, so there were probably >UNIX/TS 1.0 features not in the external version of PWB UNIX, as well as vice >versa. Close, but not quite. 1) A bunch of us [Haight, Wehr, me] moved from PWB to USG in early 1977, to help the merging process as noted. 2] Research was doing V7 at this time, and one of the additional goals of ours, working with them, was to get V7 to have the facilities found needed elsewhere, but in a more elegant fashion, given hindsight. For example, that's where environment variables (a drastic generalization of a PWB feature) and process accounting came from.) 3] Many PWB features actually did make it into UNIX/TS 1.0: the Acknowledgments say: '...; a large part ot its contents is descended from the UNIX Programmer's Manual-Sixth Edition...and the PWB/UNIX User's Manual...' Specifically, from PWB in that round were a) Numerous minor commands and command extensions, b) A few system calls, c) -MM and -MV macros, d) Miscellaneous functions. 4] The general goal was for UNIX/TS 1.0 to let the USG & PWB kernels merge at the transition to a V7 base, while integrating such user-level features as were easy to do and of general use. 5] PWB/UNIX 2.0 took the 1.0 base and added in some of the remaining features, that took more time and were more work, like: SCCS, RJE, LEAP, etc, etc. As noted, there never was a SYSTEM II; this was it, in some sense; of course, it was the last PWB release. 6] PWB/UNIX 1.0 was what was released outside, way back. This was too bad, there was a 1.2 release that was substantially cleaned up and tuned; this was probably the highest-performance V6 time-sharing version in any widespread use. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
jsq@im4u.UUCP (John Quarterman) (06/22/86)
>The best picture I've seen is by John Quartermain (sp?) There's actually no question about it: you spelled it wrong. :-) >in the chapter on Unix in the *second* edition of >the Peterson & Silberschatz book "Operating System Concepts". >I think it's just what the patient ordered. >-- >Larry McVoy Glad you liked it. However, there's a better version forthcoming in ``4.2BSD and 4.3BSD as Examples of the UNIX System'' by Quarterman, Silberschatz, and Peterson in the December 1985 ACM Computing Surveys (that's right: forthcoming and 1985). Those of you who are impatient can try running the rest of this article through pic and ditroff. No claims are made for accuracy or completeness of the information or of its depiction. PS: this followup is going only to net.unix and I've directed further responses there as well. .KF .nf .ps -2 .PS smallb = 0.5i medb = 0.75i bigb = 1i biggerb = 1.5i boxwid = smallb boxht = smallb / 2 movewid = 0.5i spacing=0.5i sysv=spacing mert=sysv + spacing pwb=mert + spacing cbunix= pwb + spacing research=cbunix + spacing v32=research + spacing bsd4=research + (2 * spacing) bsd2=bsd4 + spacing boxwid = medb D69: box invis "1969" D73: box invis "1973" boxwid = smallb D76: box invis "1976"; move D77: box invis "1977"; move D78: box invis "1978"; move D79: box invis "1979"; move D80: box invis "1980"; move D81: box invis "1981"; move D82: box invis "1982"; move D83: box invis "1983"; move D84: box invis "1984"; move D85: box invis "1985" Label: box invis at D69 boxwid = smallb V1: box invis "V1" at D69 + (0, research) V5: box invis "V5" at D73 + (0, research) V6: box invis "V6" at D76 + (0, research) boxwid = bigb V7: box "Version 7" at D78 + (0, research) arrow from V1.e to V5.w arrow from V5.e to V6.w arrow from V6.e to V7.w boxwid = smallb V32: box invis "32V" at 1/4 <D78, D79> + (0, v32) boxwid = bigb V8: box "Version 8" at D83 + (0, v32) arrow from V7.n to V32.s arrow from V32.e to V8.w arrow right from V8.e "\fIBell Research\fP" ljust at Label + (0, research + (v32 - research) / 2) boxwid = smallb PWB: box invis "PWB" at 1/2 <V6, V7> + (0, pwb - research) arrow from V6.s to PWB.nw U30: box invis "3.0" at 1/2 <D79, D80> + (0, pwb) arrow from V32.se to 4/5 <PWB, U30> arrow from V7.sw to 1/2 <PWB, U30> U40: box invis "4.0.1" at D81 + (0, pwb) U301: box invis "3.0.1" at 1/2 <U30, U40> U50: box invis "5.0" at D82 + (0, pwb) U52: box invis "5.2" at D83 + (0, pwb) U524: box invis "5.2.4" at D84 + (0, pwb) arrow from PWB.e to U30.w arrow from U30.e to U301.w arrow from U301.e to U40.w arrow from U40.e to U50.w arrow from U50.e to U52.w arrow from U52.e to U524.w arrow right from U524.e boxwid = bigb CBUNIX: box invis "CB UNIX" at PWB + (0, cbunix - pwb) arrow from 1/4 <V6, V7> to CBUNIX.n spline -> from CBUNIX.e to U301 + (0, cbunix - pwb) then to 1/2 <U301, U40> "\fIBell Columbus\fP" ljust at Label + (0, cbunix) boxwid = medb MERT: box invis "MERT" at PWB + (0, mert - pwb) boxwid = bigb UNIXRT: box invis "UNIX/RT" at D78 + (0, mert) arrow from V6.s to MERT.nw arrow from MERT.e to UNIXRT.w arrow from UNIXRT.ne to 3/4 <PWB, U30> boxwid = bigb SysIII: box "System III" at D82 + (0, sysv) SysV: box invis "System V" at D83 + (0, sysv) oldht = boxht boxht = oldht * 2 SysV2: box "System V" "Release 2" at D84 + (0, sysv) boxht = oldht * 3 SysV24: box dotted "System V" "Release 2" "Version 4" at D85 + (0, sysv) boxht = oldht arrow from U301.se to SysIII.n arrow from U50.se to SysV.n arrow from U52.se to SysV2.n arrow from U524.se to SysV24.n "\fIUSG / USDL\fP" ljust at Label + (0, sysv + (pwb - sysv)/2) boxwid = smallb BSD3: box invis "3BSD" at 1/2 <D78, D79> + (0, bsd4) arrow from V32.n to BSD3.s boxwid = medb BSD40: box invis "4.0BSD" at 1/2 <D79, D80> + (0, bsd4) BSD41: box "4.1BSD" at 1/2 <D80, D81> + (0, bsd4) BSD42: box "4.2BSD" at 1/2 <D83, D84> + (0, bsd4) BSD41A: box invis "\s-14.1aBSD\s0" at 1/3 <BSD41, BSD42> BSD41C: box invis "\s-14.1cBSD\s0" at 2/3 <BSD41, BSD42> BSD43: box dotted "4.3BSD" at 1/2 <D84, D85> + (0, bsd4) arrow from BSD3.e to BSD40.w arrow from BSD40.e to BSD41.w arrow from BSD41.e to BSD41A.w arrow from BSD41A.e to BSD41C.w arrow from BSD41C.e to BSD42.w arrow from BSD42.e to BSD43.w arrow right from BSD43.e arrow from 1/5 <V32, V8> to BSD41.sw boxwid = smallb BSD1: box invis "1BSD" at 1/2 <V6, V7> + (0, bsd2 - research) BSD2: box invis "2BSD" at V7 + (0, bsd2 - research) boxwid = medb BSD28: box invis "2.8BSD" at D82 + (0, bsd2) BSD29: box invis "2.9BSD" at D83 + (0, bsd2) arrow from V6.n to BSD1.s arrow from BSD1.e to BSD2.w arrow from BSD2.e to BSD28.w arrow from BSD28.e to BSD29.w arrow right from BSD29.e arrow from BSD2.s to BSD3.n arrow from BSD41.ne to BSD28.sw arrow from 1/2 <BSD41A, BSD41C> to BSD29.sw "\fIBerkeley\fP" ljust at Label + (0, bsd4 + (bsd2 - bsd4)/2) arrow from BSD41.se to 3/4 <V32, V8> arrow from BSD41.s to U50.n boxwid = medb box dashed "PDP-11" at BSD1 + (-1, 0) boxwid = smallb box dashed "VAX" at 1/2 <V32, BSD3> + (-1, 0) boxwid = medb box dashed "PDP-11" at PWB.w + (-1, 0) boxwid = biggerb box dashed "PDP-11 / VAX" with .ne at 1/2 <U30, SysIII> .PE .ps +2 .FI "UNIX History" .fi .KE .GI -- John Quarterman, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jsq ARPA Internet and CSNET: jsq@im4u.UTEXAS.EDU, jsq@sally.UTEXAS.EDU
simon@cstvax.UUCP (Simon Brown) (06/23/86)
In article <513@hropus.UUCP> ka@hropus.UUCP writes: --- ... PDP11 SysV vs. `real' SysV ... >Most new features made it to the PDP11. The major exception is the news >object module format, which makes SDB possible. SDB is a UNIX 3.0 feature >which did not make it to the PDP11. The UNIX 4.0 and UNIX 5.0 releases >for the PDP11 were pretty complete. > But they don't have sxt devices for the pdp11, so no job-control! -- ------------------------------------------------- | Simon Brown, Dept. of Computer Science, | | Edinburgh University | | ...!mcvax!ukc!cstvax!simon | -------------------------------------------------
henry@utzoo.UUCP (Henry Spencer) (06/26/86)
> > Although AT&T won't admit it in so many words, they effectively > > abandoned work on PDP11 Unix a long time ago. > > Most new features made it to the PDP11... But there weren't all that many new features. A lot of what was new was the performance work, which did *not* make it. > > For example, although some of the SysV performance work wouldn't fit > > on the 11, *some* of it would. None of it was applied to PDP11 SysV. > > The PDP-11 uses hashing to implement the sleep/wakeup facility in the kernel > under System V... It did under V7 too; this is nothing new. > I don't know of any other System V performance work that > was applied to the PDP11 (but then if it had been it would probably would not > have helped a machine the size of a PDP-11 much.) Nonsense. Things like inode hashing make quite a substantial difference, and are easy to put in, if anyone had bothered to *try*. As for "the size of a PDP-11"... an 11/44 is fully the equal of a 750 on anything that doesn't hit address-space problems, and an 11/70 approaches a 780. The neglect of the 11 was not because the machines wouldn't benefit from it, but because AT&T had, as I indicated, effectively abandoned the 11. (I don't *blame* them, given how hard the address-space problem hits the kernel, but they should stop lying about it.) > > ... PDP11 SysV is really SysIV. > > Not really. > > > The PDP11 SysV shared-memory stuff is also different from and > > incompatible with the regular SysV version. > > Right, but it is present, which is a difference from UNIX 4.0. The IPC > stuff was first released in UNIX 4.2. I wasn't claiming that PDP11 SysV was identically equal to 4.00000, but that it was largely one of the 4's, not really a 5. (I should have been clearer about this.) -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry