So now that I'm done futzing with the 4.1 manual for a while, I've decided to look around a few others to try and get a better feel for the continuity of different features as well as documentation practices between branches. On that note, the more I compare, the more continuity I find between PWB 1.0 and UNIX System III. Between that, various emails here, and some info from Clem, I feel fairly confident calling System III and V as well as the 4.1 in between PWB releases, at least as far as version continuity is concerned, so I may start using that nomenclature more here and there. On the flip side, the name UNIX/TS seems to bear less and less relevance outside of whatever efforts it did originate with in the late 70's. I eventually mean to aggregate all the references I've found together to develop a better picture of what that was, but just know that documentation consistency points to PWB 3, 4, and 5 as the true identity of the USG releases in the 80s, not UNIX/TS as I have referenced previously.
So now for an interesting bit of init history I've managed to piece together. The 4.1 manual still indicates the same init system as System III, based on a file called /etc/inittab but with a slightly different format and semantics from what we ultimately see in System V. That init, seen earliest thus far in PWB 3.0, seems to have been developed around that time. I'm struggling to find the email right now but I think someone on the list mentioned having written this one in either '79 or '80. As for the init in System V, it likely entered the PWB line from CB-UNIX based on the CB-UNIX 2.3 manual which can be found here: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/cbunix_man5.pdf . I say likely as some recent perusal of the MERT Release 0 manual has now cast some doubt on that. So to start, CB-UNIX 2.3 appears to be somewhat contemporaneous with UNIX 5.0 in that the manual has pages labeled specifically UNIX 5.0. That said, the issue date on the front pages of the manuals is over a year apart, so the 5.0 additions could be just that, added pages after the formal 2.3 issue. Anyway, in common between them is an init system utilizing likewise a file named /etc/inittab, but with a slightly different format and some expanded functionality. The CB-UNIX manpage for this inittab(5) can be found on page 29 of the above document. I had never looked further in that one though, and a couple days ago, I was cataloging all of the pages present in that manual when I came across page 34. This is a page for lines(5) that simply says "No longer used. See inittab(5)." Curious, so perhaps this stream of init once called the file /etc/lines, then renamed it inittab to match PWB? The very next page answers part of that question. Page 35, also lines(5), contains a description of a file very similar to the inittab(5) entry except a line is 5 fields wide, including a "shellcm" field. Unfortunately, the remaining pages of this entry are not in the PDF, presumably this was a mistaken entry. I have another such mistaken entry in a moment. Anywho, what is there of the page indicates the id field actually had an impact on the /dev entry for the terminal line in that it would be named /dev/ln<id>, and goes on to say that if a line monitor other than /etc/getty is used this must be accounted for. So interesting little note there about using something besides getty for line monitoring. Otherwise the page reads pretty similar for what is there, indicating a likely continuity between this /etc/lines-based init and the CB variant of the /etc/inittab system. One interesting note is that /etc/lines supports C-style comments, /etc/inittab instead uses sh conventions. This lines file also indicates there is a run-level 7 which may have become the S run-level. The respawn and wait actions are there, and that's where the page cuts off, so no further evidence here of what was in /etc/lines in 1979 in CB-UNIX 2.1. By 1980 it is replaced with /etc/inittab.
So aside from the lines(5) stuff, this has been pretty well understood that System V init came from or at least strongly resembles CB-UNIX init as far as what is available documentation-wise. Well, as I mentioned above, the MERT Release 0 manual may shed some further light on this matter, albeit without fully illuminating it. So first, some MERT context. This document details the origins of MERT Release 0 pretty succinctly: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs%2037-… . Basically MERT 0 is the first "supported" release by the "Small Systems Planning and Development Department (8234)" at Murray Hill. The manual is based on the USG Program Generic Issue 3 version of the manual which was issued in early 1977. This manual, in turn, is from October 1977. This intro goes on to indicate that this product will eventually be released instead as "UNIX/RT" to accompany the in-progress "UNIX/TS" which is said here to be based on V7 with additions from USG Generic 3 and PWB. The MERT-specific portion of this manual is technically considered the second edition, presumably in that the first was the material maintained and distributed by Lycklama and Bayer. So in any case, the landscape of the time seems to be that V7 is starting to go around to the various streams, with UNIX/TS in the works to present it with USG/PWB stuff and then UNIX/RT being planned as the MERT-counterpart. This isn't quite my focus here, but does provide some UNIX/TS "stuff" that has been explained to varying degrees already. So where this all relates to the init though is this: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs%2001-…'s%20Manual%20for%20MERT.pdf On page 4 of this document is a list of pages that one must replace in a standard USG Program Generic 3 manual to produce a MERT Release 0 manual. In other words, this essentially lists which pages are changed for MERT. Of interest to this discussion is the V File Formats section on page 5. The instructions are to remove a page called "lines" and to add a page called "ttys". If you then go on to read through the manual, in section V, the ttys file suggests an init system akin to the research init system. This is also indicated by replacement of the init page itself with one describing a system closer to that of research than anything else: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Pr… . So based on this, it sounds like USG Generic 3 may have had the same /etc/lines init that we see hints of in CB-UNIX. This also then suggests that CB-UNIX 2.3 may have some basis in USG Generic 3 just like MERT. Based on yet another email I'm struggling to find, another user here had offered up some info regarding a USG Generic 2 manual he has from days past. That manual contained an init similar in flavor to the research init as well, indicating that this init system shows up as part of Generic 3.
So now for that other misprint that also bears some relevance. In the UNIX 4.1 manual I recently finished restoring, there was an errant gettydefs(4) page which was only the very last few lines of the manpage (basically the SEE ALSO) section. This file is not part of the pages one needs to discard to create a MERT manual and is not otherwise in the manual, so does not appear to be a part of Generic 3. However, this file does show up in CB-UNIX 2.3, and from there presumably gets sucked into System V, but the misprint suggests such a manpage existed somewhere that would've accidentally wound up in a UNIX 4.1 typesetting run. In any case, it is very well possible this init system may have started popping up in the PWB line before 5.0, but I can't confirm this.
In any case, to consolidate this information, here's a bit of a timeline for the init as I see it:
1975 May - V6 issued. Begins getting adopted as the standard base for various streams
1976 January - USG Generic 2 issued. From what has been discussed, this still has a research-style init based on /etc/rc and /etc/ttys
1977 March - USG Generic 3 issued. This allegedly features the addition of the /etc/lines-based init that eventually becomes System V init
1977 May - PWB 1.0 issued. Forks the documentation style quite a bit, starts trends that continue to System III and beyond, still research-style init
1977 October - MERT 0 issued. This uses Generic 3 as a base but reverts to a research-style init system
1979 January - V7 issued. Still using /etc/rc and /etc/ttys
1979 November - CB-UNIX 2.1 issued. This appears to be using a Generic 3-style /etc/lines init
1980 June - PWB 3.0 issued. This has the first known appearance of /etc/inittab but with a different implementation from USG Generic 3
1981 May - CB-UNIX 2.3 issued. By this point, /etc/lines has morphed into /etc/inittab and /etc/gettydefs has been added
1981 June - PWB 4.1 issued. The manual still features the PWB 3.0-style init but an errant page suggests at least possibly /etc/gettydefs support
1982 June - PWB 5.0 issued. The transformation is complete, PWB now uses Generic 3-descended init with CB-UNIX gettydefs
This all makes me wonder what PWB 2.0 and UNIX/TS (if it ever coalesced) would've used. Precedent would say PWB 2.0 would use research-style init and UNIX/TS would've likely used Generic 3 if the aim was continuity with the USG Generics, but who knows. Anywho, hope that info's helpful to anyone else researching init systems. Of course if you have info that contradicts or enhances any of this I'd love to hear it!
- Matt G.
With all your help I thought I would share a couple
of programs I had a hand in.
more.c is like 'more' for Linux. more abc.txt or cat abc.txt | more or ls
-l | more
pg.c is a 'pager' program. pg abc.txt def.txt
cls. is a clear screen home cursor program using VT100 codes. It works on
the console or telnet or putty.
All can be compiled and placed in /usr/bin
cc -o /usr/bin/cls cls.c
cc -o /usr/bin/pg pg.c
cc -o /usr/bin/more more.c
More to come. Enjoy.
Ken
--
WWL 📚
> From: Michael Huff
> All of the simh vax tutorials on Gunkies still give instructions to turn
> all of the tar files (plus things like miniroot) into a single tap file
> for installation.
If those are out-of-date, you/someone should get a CHWiki account and
update them! :-)
Documentation skew from code has always been a problem...
Noel
Morning,
I am using enblock to create tap files from tar files.
Was a program ever written to convert tap files to tar files or
a Linux program that could read tap files?
I also see that writing to a tap file from Unix the size increases
when writing multiple files however when writing 1 file to the tap
file "tar cv0 ..." the tap file still remains at its larger size from the
previous larger writes. Is this what is expected?
Thanks,
Ken
--
WWL 📚
On Monday, February 27, 2023, Dan Cross <crossd(a)gmail.com> wrote:
> On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS <tuhs(a)tuhs.org>
> wrote:
> > Thanks all for the insights. Let me attempt a summary.
> >
> <SNIP>
>
Oh, and lots of games; I had a nice
> Solitaire version that I can no longer recall the name of.
>
>
Coming from the 8-bit microcomputer world (Atari 8-bit, C64), and then
upgrading to 16-bit (Amiga and PC MS-DOS) I experienced a myriad of
unforgettable games on those platforms. They were mostly commercial but
they were very much different from modern games. It was the era of
innovation and pouring all your soul into the games you produce. I still
think that some of them have not been surpassed in quality and playability.
I still play them on period correct hardware as they are still extremely
fun and challenging.
This is my top 10 list (sorted by year):
* Prince of Persia
* The Secret of Monkey Island
* Civilization
* Dune II
* Master of Orion
* Reunion
* Warcraft
* Ascendancy
* Quake
* Half-Life
As I started to play with Linux in the mid 90s I remember a port of Doom
and then Quake, but not that many other games. Can you elaborate more on
what Unix afficionados played in the late 80s/early 90s?
--Andy
And, you know, let's say you have all the time and patience in the world
and you download the source and read it carefully and determine it's not
malicious...
I believe there might have been a lecture/paper about this once.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrust…
(I can just hear them damn kids standing on my lawn chanting "You can't
spell 'trust' without 'rust'!")
I keep trying to give VSCode a go. It seems really nifty. And somehow I
keep bouncing off and landing in Emacs, every time. Maybe when I finally
get around to writing, rather than cargo-culting TypeScript, or Unity/C#,
it'll be a better fit. But for my current life, which is mostly Python...I
appear to be sticking with Emacs.
Adam
Got a little present for folks today. Been working on this for a little while now, and while there'll probably be some edits here and there, I believe it to be quite accurate.
After the link is a manpage restoration of the UNIX 4.1 User's Manual (3B20S) that I bought a little while ago: https://gitlab.com/segaloco/pwb4u_man
The permuted index is the only significant piece that isn't done, but that shouldn't impact the informational value. Note this is just u_man, I haven't found a complimentary a_man copy yet. I hope one will turn up one of these days, but I plan on at least analyzing the gap between System III and System V with regards to those pages as a future project.
My process involved diff'ing the available III and V manpage sources and reconciling differences between the two and 4.1 with some copy-paste here and some restoration there. Where differences couldn't be resolved, I simply removed content to match the physical pages. One minute detail that is also not filled in is the page count in M.folio. So I didn't count the pages. Maybe someday. In any case, I appreciate the opportunity this has given me to learn the manpage macros pretty well.
Anywho, in the second pass of verifying the changes I took some notes on noteworthy mentions. This list is not an exhaustive analysis but represents some of the areas where significant developments shine through in the text:
System III->4.1 (No claims are made as to what occurred at 4.0):
- The documentation is cleaned up quite a bit in general, in what seems like a push towards commercial-ready manuals. Many sections are edited to be more clear and descriptive. There is also a notable shift towards gender neutral language. The editors and acknowledgements info are removed, casting an anonymous shadow over the manual maintainers and their muses alike.
- The tty manpage is renamed termio, reflecting the shifting terminal interface landscape at this time.
- This release adds IPC with a familiar interface to what is in System V. According to various accounts the IPC was under heavy development at this time, but while the underlying components may have been shifting and changing, the documentation changes suggest a relatively stable programmer API by this point. The only IPC-related piece System V adds is icprm(1).
- The LP print service is added here. The old lpr system is still there in the background; it is in System V. However, it is relegated to DEC only status.
- SGS and COFF development components show up with 4.1 3B-20. No telling what else they officially supported in the 4.x timeframe. The System V pages as described below indicate a number of supported platforms.
- The shell gets the $CDPATH and ulimit features
- Many system features show a trend towards portability (except the PDP-11, the system appears to be moving away from it)
- The Virtual Protocol Machine (VPM) seems to go from targeting KMC11 to UN53 and V.35. Haven't researched what these are yet, but VPM is on the move.
- As of 4.1, 3B-20 does *not* support: Fortran, BASIC, Honeywell/GCOS 6000 connectivity, lpr printing, SNOBOL, standalone C
- Added pages include cflow(1), cprs(1), cxref(1), dis(1), dump(1) (was a tape dump (1m), now a SGS tool), enable(1), hpio(1), ipcs(1), list(1), lp(1), lpstat(1), newform(1), sadp(1), trouble(1), x25pvc(1), msgctl(2), msgget(2), msgop(2), plock(2), semctl(2), semget(2), semop(2), shmctl(2), shmget(2), shmop(2), sys3b(2), drand48(3c), getcwd(3c), hsearch(3c), ld*(3x) (COFF library), setbuf(3s), stdipc(3c), strtol(3c), termio(4) (renamed from tty(4)), ldfcn(5), mosd(5), mptx(5), jotto(6)
- Removed pages include cref(1), dump(1m), fget.odemon(1c), odpd(1c), orjestat(1c), reform(1), tp(1), typo(1), xref(1), tp(4), tty(4) (renamed to termio(4))
- Some pages were skipped and show back up in System V with minimal changes, meaning they were probably in 4.x: adb(1), arcv(1), bs(1), dpd(1c), dpr(1c), efl(1), f77(1), factor(1), fget(1c), fget.demon(1c), fsend(1c), gcat(1c), gcosmail(1c), kas(b)/kun(b)(1), lpd(1c), lpr(1), ratfor(1), scc(1), sno(1), vpr(1)
4.1->System V (Likewise, there was at least a 4.2):
- Documentation is cleaned up and edited some more. Almost everywhere that the name "UNIX" occurs, it has been replaced with some variation on "The UNIX System" with a capital S. This is lower case in my 5.0 manual which I have not combed for differences with System V yet. Still, the "system" following is standard by 5.0 it seems. This is right around the time of dashing Bell associations too, so variations of this manual exist with and without the Bell logo on the front, and with varying degrees of modification to explain the legal landscape involved.
- Section 3 in particular sees a pretty significant rewrite effort. This coincides with MR 1055 here: https://archive.org/details/unix-system-release-description-system-v/I%20-%…
- A new portable archive format is introduced. By the sounds of it, this introduces a new header type into the ar(4) format.
- A new 1024-block filesystem is introduced, along with necessary support.
- A new synchronous terminal interface is added.
- VAX is supported by SGS/COFF now. Additional platforms as suggested by formatting marks in the pages include: Basic-16, Bellmac 32, and 8086, in addition to the already supported 3B-20. Unknown whether these platforms found any support with USG releases.
- ex(1) is added (along with vi(1) and edit(1)). There is also the se(1) editor which I don't know much about.
- CB-init is added, shaking up the /etc/inittab format and many login-related features. MAUS also steps in from CB for shared memory on PDP-11.
- Added pages include asa(1), convert(1), cpp(1), edit(1), ex(1), fsplit(1), ipcrm(1), machid(1), makekey(1), net(1c), nscstat(1c), nsctorje(1c), nusend(1c), scat(1), se(1), stlogin(1), ststat(1), vi(1), maus(2), clock(3c), dial(3c), erf(3m), getut(3c), matherr(3m), memory(3c), sputl(3x), ttyslot(3c), x25*(3c), filehdr(4), gettydefs(4), issue(4), linenum(4), reloc(4), scnhdr(4), syms(4)
- Removed pages include vpmc(1c), vpmsave(1c), vpmset(1c), x25pvc(1c), fptrap(3x)
That's all I've got. As time goes on I'll start documenting worthwhile tidbits in the Wiki. If there's any question of the contents of any of the pages, I'll happily consult the original and make corrections, and can scan any page to verify the contents if needed. I'll eventually be scanning the whole thing, just not right now. Feel free to open a pull request if you think something needs to change.
- Matt G.
On 2/25/23, Brian Walden <tuhs(a)cuzuco.com> wrote:
> It was originaly 205. See A.OUT(V) (the first page) at
> https://www.bell-labs.com/usr/dmr/www/man51.pdf it was documented as to
> why.
>
>
> The header always contains 6 words:
> 1 "br .+14" instruction (205(8))
> 2 The size of the program text
> 3 The size of the symbol table
> 4 The size of the relocation bits area
> 5 The size of a data area
> 6 A zero word (unused at present)
>
> I always found this so elegant in it's simplicity. Just load and start
> execution at the start (simplifies exec(2) in the kernel) I always wondered
> if this has done anywhere else before, or invenetd first in unix.
IBM's Basic Program Support (BPS) for System/360 was a set of
stand-alone utilities for developing and running stand-alone programs.
BPS/360 wasn't really an operating system because there wasn't any
resident kernel. You just IPLed (Initial Program Load; IBM-speak for
"boot") your application directly. So the executable format for BPS
had a bootstrap loader as the "program header". Not quite the same
thing as a.out's 205(8) magic number, but similar in concept.
I don't know of any other OS ABI that uses this trick to transfer
control to application programs.
Microsoft uses something similar in PECOFF. A PECOFF executable for
x86 or X86-64 starts with a bit of code in MS-DOS MZ executable format
that prints the message "This program cannot be run in DOS mode".
-Paul W.