From tuhs at tuhs.org Wed Jul 1 01:59:11 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 30 Jun 2026 11:59:11 -0400 Subject: [TUHS] UNIX V4 clip by CBS In-Reply-To: References: Message-ID: below On Mon, Jun 29, 2026 at 5:12 PM Thalia Archibald via TUHS wrote: > The CBS story for our recovery of UNIX V4 has now been published! > It's a fun, short clip with footage not shown in the February video put > out by CHM. > https://www.youtube.com/watch?v=HatXp2dqxb4 nice. > > > As an aside, the black monitor in the historical clips (0:12, 0:44) looks > like a > Teletype Model 40. > I think you are right. I don't think I ever saw one with the video display option. But I did encounter a couple of track-mounted versions with a kyb/printer (ASR-33 function replacement) in a computer room. From tuhs at tuhs.org Wed Jul 1 02:09:43 2026 From: tuhs at tuhs.org (al kossow via TUHS) Date: Tue, 30 Jun 2026 09:09:43 -0700 Subject: [TUHS] UNIX V4 clip by CBS In-Reply-To: References: Message-ID: >> The CBS story for our recovery of UNIX V4 has now been published! >> It's a fun, short clip with footage not shown in the February video put >> out by CHM. >> https://www.youtube.com/watch?v=HatXp2dqxb4 > the reason it never ran https://cosocial.ca/@robpike/116836488725606098 From tuhs at tuhs.org Wed Jul 1 05:59:48 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Tue, 30 Jun 2026 19:59:48 +0000 Subject: [TUHS] Several Missing UNIX Documents Procured In-Reply-To: References: Message-ID: <3936838F-BF08-419E-95C5-350DE4448AC9@archibald.dev> On Jun 29, 2026, at 19:35, segaloco wrote: > Hello one and all! I wanted to share news of a recent document haul that contains many interesting bits. The highlights are: > WwB 2.0 Source Code (circa 1982, I think it's all there) > More to come! > > - Matt G. Great work as usual! I’m especially excited by the WWB source. Thalia From tuhs at tuhs.org Wed Jul 1 06:04:36 2026 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Wed, 1 Jul 2026 06:04:36 +1000 Subject: [TUHS] Anachronistic verisimilitude at cat-v.org In-Reply-To: References: Message-ID: I don't own that page, but clearly those who do did not understand col(1). I'll forward this to tuhs to see if anyone there knows who can fix it. -rob On Tue, Jun 30, 2026 at 10:58 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > The display on page 2 of > https://harmful.cat-v.org/cat-v/unix_prog_design.pdf > is explainable, but may be mystifying to readers who > know backspace only as an editing convenience, not a > printing action. > > Doug > From tuhs at tuhs.org Wed Jul 1 07:39:13 2026 From: tuhs at tuhs.org (sl via TUHS) Date: Tue, 30 Jun 2026 17:39:13 -0400 Subject: [TUHS] Anachronistic verisimilitude at cat-v.org Message-ID: > On Tue, Jun 30, 2026 at 10:58 PM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> The display on page 2 of >> https://harmful.cat-v.org/cat-v/unix_prog_design.pdf >> is explainable, but may be mystifying to readers who >> know backspace only as an editing convenience, not a >> printing action. >> >> Doug > > I don't own that page, but clearly those who do did not understand col(1). > I'll forward this to tuhs to see if anyone there knows who can fix it. > > -rob i inherited cat-v.org from uriel when he passed away in 2012. i have postscript but no troff source for the original paper. over the years i've discovered multiple problems with the document. back in 2013 i wrote to bwk: Page 4 of the pdf version, the paragraph that begins with "The answer is 'No.'" contains lines such as: cat's job is to the data in files and: Programs that collect data shouldn't the data Amusing, but presumably not intentional. There are other examples of apparently missing words throughout the file. bwk confirmed that nobody seemed to have the source, and copied rob on the reply. since the source was presumed lost, i examined the version published in the BLTJ, and reported: The printed version from BLTJ had also lost some characters during its journey from source to print. Specifically, the backquotes from the example on page 3: cat `cat filelist` The italics missing from my copy were intact in this version. Today, a friend located a postscript version that seems to have retained all of the missing pieces: http://netlib.bell-labs.com/cm/cs/doc/84/kp.ps.gz this version addressed the problems i'd originally noticed but now exhibits the problems doug noted above. everyone stopped responding to me at this point, and in the subsequent years i have failed to recreate the entire document by re-typing it. sl From tuhs at tuhs.org Wed Jul 1 16:11:52 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 01 Jul 2026 06:11:52 +0000 Subject: [TUHS] Several Missing UNIX Documents Procured In-Reply-To: References: Message-ID: <_ZPnpqeXOG-z90KK54srYeB-L0MtGjnxiU7Iiv4rFIMENi1T7xASQD93Fp9FezjQsLqENcKsm6DB3aAwlMtdLE8kSNxrhvGVJ5MxbU3La6I=@protonmail.com> On Monday, June 29th, 2026 at 18:35, segaloco via TUHS wrote: > Hello one and all! I wanted to share news of a recent document haul that contains many interesting bits. > > ... > > There are other odds and ends, and the seller found another binder already and may continue to do so, I've arranged to check in again on Friday. Among the random bits here too are two issues of the WECo UNIX Systems Newsletter that, among other things, detail "UNIX Release 6.0". From the February 1983 newsletter: > > > UNIX System Release 6.0 planning and development is continuing on schedule. The target ready-to-order > > date is December 15, 1983. The most probable features include: > > > > - Demand Paging > > - Job Control > > - shell Enhancements > > - Curser(sic)/Terminfo Package > > - Selected BSD commands (ls,mail,pg) > > - cron/at Package > > - Arbitrary length variable names in C (flexnames) > > The earliest SVR2 manuals, those distributed internally to BTL facilities, are dated December, 1983, so presumably USG delivered on their ready-to-order timeline. > These two newsletter issues are now uploaded here: https://archive.org/details/unix-systems-newsletter-vol-5-no-3 https://archive.org/details/unix-systems-newsletter-vol-6-no-1 These are right as System V is making it out and Release 6.0 (SVR2) is being developed. They give a little peek into what folks inside AT&T were seeing on the eve of System V and divestiture. - Matt G. From tuhs at tuhs.org Fri Jul 3 22:41:06 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Fri, 03 Jul 2026 14:41:06 +0200 Subject: [TUHS] fork In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com> Message-ID: <1444cb0fa6d0d8425d07057de72eb567@vanheusden.com> > p.s. it is on http://pdp.komputilo.nl:8080/ (behind a NAT router) and > it takes quite a while to serve pages :-) After fixing an important bug (stack yellow zone did not trigger an MMR1 update) it is a lot more stable! Kernel compiles go all the way to the finish, finally :-) If I remember correctly, I also mentioned not being able to talk to the NTPd included in BSD: that is also solved after I switched to NTP v1. Regards -- www.vanheusden.com From tuhs at tuhs.org Mon Jul 6 22:32:16 2026 From: tuhs at tuhs.org (Aharon Robbins via TUHS) Date: Mon, 06 Jul 2026 15:32:16 +0300 Subject: [TUHS] Reconstituted - Program design in the UNIX environment Message-ID: Hello All, Last week, with some spare time and a desire to stop doing things that really needed doing, I decided to try to reconstitute the troff source for "Program design in the UNIX environment" which had apparently been lost. This version fixes a few issues in the existing PostScript version of the document from http://harmful.cat-v.org. I've made it available at https://github.com/arnoldrobbins/unix-program-design also. Comments and/or fixes are welcome. I have sent the files directly to Rob and Brian. Enjoy, Arnold -------------- next part -------------- .\" Borrowed from BWK's macros from CSTR 100. .ig programs are displayed between .P1/.P2 pairs default is to indent by 1/2 inch, nofill, dP smaller .P1 x causes an indent of x instead. .P3 can be used to specify optional page-break points inside .P1/.P2 .. .nr DV .5v \" space before start of program .nr dT 5 .de P1 .nr P1 .4i \" program indent in .P1 .if \\n(.$ .nr P1 \\$1 .br .nr v \\n(.v .di p1 .in \\n(P1u .nf .ps -\\n(dP .vs -\\n(dVu .ft CW .nr t \\n(dT*\\w'x'u .ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu .. .de P2 .br .ps \\n(PS .vs \\n(VSp .vs \\nvu .ft 1 .in .di .br .sp \\n(DVu .br .if \\n(.$=0 .ne \\n(dnu \" -\\n(DVu .p1 .sp \\n(DVu .br .fi .. From tuhs at tuhs.org Mon Jul 6 23:42:47 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 06 Jul 2026 07:42:47 -0600 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: References: Message-ID: <202607061342.666DglvX005321@freefriends.org> Hmm, The troff file didn't get attached. It's attached now. Sorry 'bout that folks. Arnold Aharon Robbins via TUHS wrote: > Hello All, > > Last week, with some spare time and a desire to stop doing things > that really needed doing, I decided to try to reconstitute the troff > source for "Program design in the UNIX environment" which had > apparently been lost. > > This version fixes a few issues in the existing PostScript version > of the document from http://harmful.cat-v.org. > > I've made it available at https://github.com/arnoldrobbins/unix-program-design > also. > > Comments and/or fixes are welcome. > > I have sent the files directly to Rob and Brian. > > Enjoy, > > Arnold From tuhs at tuhs.org Tue Jul 7 00:00:36 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Tue, 7 Jul 2026 00:00:36 +1000 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: References: Message-ID: On Mon, Jul 06, 2026 at 03:32:16PM +0300, Aharon Robbins via TUHS wrote: > Hello All, > > Last week, with some spare time and a desire to stop doing things > that really needed doing, I decided to try to reconstitute the troff > source for "Program design in the UNIX environment" which had > apparently been lost. > > This version fixes a few issues in the existing PostScript version > of the document from http://harmful.cat-v.org. checksum of unix_prog_design.ps from http://harmful.cat-v.org/cat-v/ matches that of kp.ps from https://9p.io/cm/cs/doc/index.html and http://web.archive.org/web/20080123190345id_/http://cm.bell-labs.com/cm/cs/papers.html Scans have some other differences such as numbered sections: UNIX System Readings and Applications Volume II, pp 18-28 https://bitsavers.org/pdf/att/unix/ https://archive.org/details/program-design-in-unix-environment From tuhs at tuhs.org Tue Jul 7 00:02:57 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 6 Jul 2026 10:02:57 -0400 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: References: Message-ID: Thank you. Sent from a handheld expect more typos than usual On Mon, Jul 6, 2026 at 8:32 AM Aharon Robbins via TUHS wrote: > Hello All, > > Last week, with some spare time and a desire to stop doing things > that really needed doing, I decided to try to reconstitute the troff > source for "Program design in the UNIX environment" which had > apparently been lost. > > This version fixes a few issues in the existing PostScript version > of the document from http://harmful.cat-v.org. > > I've made it available at > https://github.com/arnoldrobbins/unix-program-design > also. > > Comments and/or fixes are welcome. > > I have sent the files directly to Rob and Brian. > > Enjoy, > > Arnold > From tuhs at tuhs.org Tue Jul 7 00:09:42 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 06 Jul 2026 08:09:42 -0600 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: References: Message-ID: <202607061409.666E9gZ9007463@freefriends.org> Jonathan Gray wrote: > checksum of unix_prog_design.ps from > http://harmful.cat-v.org/cat-v/ > > matches that of kp.ps from > https://9p.io/cm/cs/doc/index.html and > http://web.archive.org/web/20080123190345id_/http://cm.bell-labs.com/cm/cs/papers.html > > Scans have some other differences such as numbered sections: > > UNIX System Readings and Applications Volume II, pp 18-28 > https://bitsavers.org/pdf/att/unix/ > > https://archive.org/details/program-design-in-unix-environment Rob -- were the numbered sections added for the BSTJ issue? Should I put them into this doc? I have a copy of that journal in my basement, so I should be able to do that. Thanks, Arnold From tuhs at tuhs.org Tue Jul 7 10:08:26 2026 From: tuhs at tuhs.org (Greg 'groggy' Lehey via TUHS) Date: Tue, 7 Jul 2026 10:08:26 +1000 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: <202607061342.666DglvX005321@freefriends.org> References: <202607061342.666DglvX005321@freefriends.org> Message-ID: On Monday, 6 July 2026 at 7:42:47 -0600, Arnold Robbins via TUHS wrote: > Hmm, > > The troff file didn't get attached. It's attached now. > > Sorry 'bout that folks. Sorry from our side, I suppose. Our mailing list software strips most attachments. We should probably revisit that situation (TUHS team please discuss), but since you also put it on github, we don't have a problem in this case. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Tue Jul 7 11:25:27 2026 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Tue, 7 Jul 2026 11:25:27 +1000 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: <202607061409.666E9gZ9007463@freefriends.org> References: <202607061409.666E9gZ9007463@freefriends.org> Message-ID: No idea, sorry. It was a while ago. -rob On Tue, Jul 7, 2026 at 12:19 AM Arnold Robbins via TUHS wrote: > Jonathan Gray wrote: > > > checksum of unix_prog_design.ps from > > http://harmful.cat-v.org/cat-v/ > > > > matches that of kp.ps from > > https://9p.io/cm/cs/doc/index.html and > > > http://web.archive.org/web/20080123190345id_/http://cm.bell-labs.com/cm/cs/papers.html > > > > Scans have some other differences such as numbered sections: > > > > UNIX System Readings and Applications Volume II, pp 18-28 > > https://bitsavers.org/pdf/att/unix/ > > > > https://archive.org/details/program-design-in-unix-environment > > Rob -- were the numbered sections added for the BSTJ issue? > Should I put them into this doc? > > I have a copy of that journal in my basement, so I should be able > to do that. > > Thanks, > > Arnold > From tuhs at tuhs.org Tue Jul 7 16:02:39 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 07 Jul 2026 00:02:39 -0600 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: References: <202607061409.666E9gZ9007463@freefriends.org> Message-ID: <202607070602.66762d0r084030@freefriends.org> Rob, No problem, thanks. I have updated the copy in Github such that with `groff -r tj=1 ...' the headings and author biographies are included. It seems that some people aren't getting attachments so I won't try to include the document. If you want it, please get it from Github. Enjoy, Arnold Rob Pike wrote: > No idea, sorry. > > It was a while ago. > > -rob > > > On Tue, Jul 7, 2026 at 12:19 AM Arnold Robbins via TUHS > wrote: > > > Jonathan Gray wrote: > > > > > checksum of unix_prog_design.ps from > > > http://harmful.cat-v.org/cat-v/ > > > > > > matches that of kp.ps from > > > https://9p.io/cm/cs/doc/index.html and > > > > > http://web.archive.org/web/20080123190345id_/http://cm.bell-labs.com/cm/cs/papers.html > > > > > > Scans have some other differences such as numbered sections: > > > > > > UNIX System Readings and Applications Volume II, pp 18-28 > > > https://bitsavers.org/pdf/att/unix/ > > > > > > https://archive.org/details/program-design-in-unix-environment > > > > Rob -- were the numbered sections added for the BSTJ issue? > > Should I put them into this doc? > > > > I have a copy of that journal in my basement, so I should be able > > to do that. > > > > Thanks, > > > > Arnold > > From tuhs at tuhs.org Tue Jul 7 16:05:05 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Tue, 7 Jul 2026 01:05:05 -0500 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: References: Message-ID: <20260707060505.tbcl72syeuqt47aj@illithid> Hi Arnold, At 2026-07-06T15:32:16+0300, Aharon Robbins via TUHS wrote: > Last week, with some spare time and a desire to stop doing things > that really needed doing, I decided to try to reconstitute the troff > source for "Program design in the UNIX environment" which had > apparently been lost. > > This version fixes a few issues in the existing PostScript version > of the document from http://harmful.cat-v.org. > > I've made it available at https://github.com/arnoldrobbins/unix-program-design > also. Thanks for doing this work! > Comments and/or fixes are welcome. I have several observations. They are not necessarily critiques. Some are notes to myself, or to anyone interested in contributing to groff to improve it, or are simply things to keep in mind about how the ms(7) package has evolved over the years. 1. It's nice to see the dagger reappearing in the document title. 2. groff ms's default line length is longer than that used by the original version of this document. groff ms uses symmetrical left and right margins by default (about 190 px on my screen); the original PostScript file did not (left: ~190px, right: ~290 px). 3. Figure 1 now looks reasonable. I think Clem Cole asked me to look into why the original version formatted so weirdly. I wanted to answer his question, but I couldn't come up with one: I checked out my copy of the V1 cat.1 man page, but it is a truly plain text document. No overstriking is evident. I therefore cannot account for the appearance of the underscores in the original PostScript file. 4. The bibliographic references are set as footnotes instead of end notes. Arnold has a comment in the reconstruction: .\" Notable differences: .\" - The formatting of the references is different. Anyone who knows .\" how to make GNU refer mimic the original markup, please .\" let me know. When formatting the document for myself with groff 1.24.1, I got a couple of diagnostics. $ groff -R -m s -T pdf unix_prog_design.ms >| unix_prog_design.pdf refer:unix_prog_design.ms:687: error: found '$LIST$' but not accumulating references troff:unix_prog_design.ms:145: warning: font name 'CW' is deprecated Seeing that hint, with the following patch, the footnotes become end notes like in the original document. $ git diff diff --git a/unix_prog_design.ms b/unix_prog_design.ms index 35de433..dd34f47 100644 --- a/unix_prog_design.ms +++ b/unix_prog_design.ms @@ -21,6 +21,9 @@ .\" - Thanks to Brian Kernighan's CSTR 100 macros for .P1 and .P2. .\" .so prog.mac +.R1 +accumulate +.R2 .TL Program design in the UNIX\(dg .FS This means that it appears that GNU refer's `-e` option, which means the same thing, didn't work. I'll have to file a Savannah ticket about that. 5. Regarding the other diagnostic: troff:unix_prog_design.ms:145: warning: font name 'CW' is deprecated ...font names are a known portability grievance. You can either change "prog.mac" to use groff's name for Courier roman, "CR", or use groff ms's font selection macros. Here's an example of each solution. $ git diff diff --git a/prog.mac b/prog.mac index 21a61fe..a14fbba 100644 --- a/prog.mac +++ b/prog.mac @@ -19,7 +19,7 @@ .nf .ps -\\n(dP .vs -\\n(dVu -.ft CW +.ft CR .nr t \\n(dT*\\w'x'u .ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu .. $ git diff diff --git a/prog.mac b/prog.mac index 21a61fe..a3ae43f 100644 --- a/prog.mac +++ b/prog.mac @@ -19,7 +19,7 @@ .nf .ps -\\n(dP .vs -\\n(dVu -.ft CW +.CW .nr t \\n(dT*\\w'x'u .ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu .. @@ -28,7 +28,7 @@ .ps \\n(PS .vs \\n(VSp .vs \\nvu -.ft 1 +.R .in .di .br However, there are other uses of `\f(CW` in the document, and they warn too. Due to the unpopularity of repeated font availability warnings, GNU troff emits only one per font name.[1] In the future, I'd like GNU troff to work more like a proper linter in this respect, and issue a warning on each occurrence, there by making it easier to drive an editor session by redirecting its stderr to a file, and then editing that file with `vi -q`. Here's a patch to reformat the table of Pike-disapproved cat(1) options more similarly to the original PostScript file. I have no idea if K&P originally used tbl(1) for this purpose. I also reduced the type size, as is apparent in the original PostScript, and changed the option dashes to use the "correct" glyph, `\-`.[2] @@ -292,16 +292,19 @@ with features. This list comes from .CW cat on the Berkeley distribution of the UNIX system: .PP -.nf -.in .5i -\f(CW-s\fP strip multiple blank lines to a single instance -\f(CW-n\fP number the output lines -\f(CW-b\fP number only the non-blank lines -\f(CW-v\fP make non-printing characters visible - \f(CW-ve\fP mark ends of lines - \f(CW-vt\fP change representation of tab -.in -.5i -.fi +.RS +.TS +Lf(CR)p-1 Lp-1 S. +\-s strip multiple blank lines to a single instance +\-n number the output lines +\-b number only the non-blank lines +\-v make non-printing characters visible +.T& +L Lf(CR)p-1 Lp-1. +\& \-ve mark ends of lines +\& \-vt change representation of tab +.TE +.RE .PP In System V, there are similar options and even a clash of naming: .CW -s (One could alternatively eschew the `p` column modifiers to the table, and bracket the whole thing in `.ps -1` and `.ps` instead.) Using tbl(1) of course requires modification of the command line. $ groff -Rt -m s -T pdf unix_prog_design.ms >| unix_prog_design.pdf 6. Cleaning up another occurrences of font `CW`, I saw further opportunities to use `\-` for Unix option dashes and also to employ ms(7)'s `Q` and `U` strings for typographer's quotation marks. However, the latter are 4.2BSD ms extensions--a fact I had not documented in groff's ms(7) man page and "ms.ms" document! So I'll take a note to myself to fix that. Using `` and '' appears to kern the symbols more closely to the original. On the gripping hand, passing 3 arguments to the `CW` macro _is_ a GNU extension in groff ms(7). You can always get around that with `\c`, though. @@ -353,7 +356,8 @@ But what about .CW -v ? That prints non-printing characters in a visible representation. Making strange characters visible is a genuinely new -function, for which no existing program is suitable. (``\f(CWsed -n l\fP'', +function, for which no existing program is suitable. +.CW "sed \-n l" ``, '' the closest standard possibility, aborts when given very long input lines, which are more likely to occur in files containing non-printing characters.) So isn't it appropriate to add the @@ -535,7 +539,8 @@ pr -$0 -t -l1 $* is the program name (\c .CW 2 , .CW 3 , -etc.), so \-\f(CW$0\fP +etc.), so +.CW $0 "" \- becomes \-\fIn\fP where .I n 7. I see that the em dashes in the "use of cat" footnote now actually appear. Great work! Regards, Branden [1] https://lists.gnu.org/archive/html/groff/2024-10/msg00066.html [2] https://lwn.net/Articles/947941/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Tue Jul 7 16:05:45 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 07 Jul 2026 00:05:45 -0600 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: References: <202607061342.666DglvX005321@freefriends.org> Message-ID: <202607070605.66765kHe084278@freefriends.org> No worries. Thanks. "Greg 'groggy' Lehey" wrote: > On Monday, 6 July 2026 at 7:42:47 -0600, Arnold Robbins via TUHS wrote: > > Hmm, > > > > The troff file didn't get attached. It's attached now. > > > > Sorry 'bout that folks. > > Sorry from our side, I suppose. Our mailing list software strips most > attachments. We should probably revisit that situation (TUHS team > please discuss), but since you also put it on github, we don't have a > problem in this case. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php From tuhs at tuhs.org Tue Jul 7 17:32:43 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 07 Jul 2026 01:32:43 -0600 Subject: [TUHS] Reconstituted - Program design in the UNIX environment In-Reply-To: <20260707060505.tbcl72syeuqt47aj@illithid> References: <20260707060505.tbcl72syeuqt47aj@illithid> Message-ID: <202607070732.6677WhCk096086@freefriends.org> Hi. Thanks for these. I have made changes, although not verbatim, conditionalizing some things on \(.g for groff. I'd like the document to remain portable to Plan 9 troff. I've pushed the updates to Github. W.R.T. the cat(I) man page, I simply put in backspaces to get the overstriking, and manually converted whatever weird bit was in the PostScript for the em dashes back into \(em. Thanks, Arnold "G. Branden Robinson via TUHS" wrote: > Hi Arnold, > > At 2026-07-06T15:32:16+0300, Aharon Robbins via TUHS wrote: > > Last week, with some spare time and a desire to stop doing things > > that really needed doing, I decided to try to reconstitute the troff > > source for "Program design in the UNIX environment" which had > > apparently been lost. > > > > This version fixes a few issues in the existing PostScript version > > of the document from http://harmful.cat-v.org. > > > > I've made it available at https://github.com/arnoldrobbins/unix-program-design > > also. > > Thanks for doing this work! > > > Comments and/or fixes are welcome. > > I have several observations. They are not necessarily critiques. Some > are notes to myself, or to anyone interested in contributing to groff to > improve it, or are simply things to keep in mind about how the ms(7) > package has evolved over the years. > > 1. It's nice to see the dagger reappearing in the document title. > > 2. groff ms's default line length is longer than that used by the > original version of this document. groff ms uses symmetrical left > and right margins by default (about 190 px on my screen); the > original PostScript file did not (left: ~190px, right: ~290 px). > > 3. Figure 1 now looks reasonable. I think Clem Cole asked me to look > into why the original version formatted so weirdly. I wanted to > answer his question, but I couldn't come up with one: I checked out > my copy of the V1 cat.1 man page, but it is a truly plain text > document. No overstriking is evident. I therefore cannot account > for the appearance of the underscores in the original PostScript > file. > > 4. The bibliographic references are set as footnotes instead of end > notes. Arnold has a comment in the reconstruction: > > .\" Notable differences: > .\" - The formatting of the references is different. Anyone who knows > .\" how to make GNU refer mimic the original markup, please > .\" let me know. > > When formatting the document for myself with groff 1.24.1, I got a > couple of diagnostics. > > $ groff -R -m s -T pdf unix_prog_design.ms >| unix_prog_design.pdf > refer:unix_prog_design.ms:687: error: found '$LIST$' but not accumulating references > troff:unix_prog_design.ms:145: warning: font name 'CW' is deprecated > > Seeing that hint, with the following patch, the footnotes become end > notes like in the original document. > > $ git diff > diff --git a/unix_prog_design.ms b/unix_prog_design.ms > index 35de433..dd34f47 100644 > --- a/unix_prog_design.ms > +++ b/unix_prog_design.ms > @@ -21,6 +21,9 @@ > .\" - Thanks to Brian Kernighan's CSTR 100 macros for .P1 and .P2. > .\" > .so prog.mac > +.R1 > +accumulate > +.R2 > .TL > Program design in the UNIX\(dg > .FS > > This means that it appears that GNU refer's `-e` option, which > means the same thing, didn't work. I'll have to file a Savannah > ticket about that. > > 5. Regarding the other diagnostic: > > troff:unix_prog_design.ms:145: warning: font name 'CW' is deprecated > > ...font names are a known portability grievance. You can either > change "prog.mac" to use groff's name for Courier roman, "CR", or > use groff ms's font selection macros. Here's an example of each > solution. > > $ git diff > diff --git a/prog.mac b/prog.mac > index 21a61fe..a14fbba 100644 > --- a/prog.mac > +++ b/prog.mac > @@ -19,7 +19,7 @@ > .nf > .ps -\\n(dP > .vs -\\n(dVu > -.ft CW > +.ft CR > .nr t \\n(dT*\\w'x'u > .ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu > .. > > $ git diff > diff --git a/prog.mac b/prog.mac > index 21a61fe..a3ae43f 100644 > --- a/prog.mac > +++ b/prog.mac > @@ -19,7 +19,7 @@ > .nf > .ps -\\n(dP > .vs -\\n(dVu > -.ft CW > +.CW > .nr t \\n(dT*\\w'x'u > .ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu > .. > @@ -28,7 +28,7 @@ > .ps \\n(PS > .vs \\n(VSp > .vs \\nvu > -.ft 1 > +.R > .in > .di > .br > > However, there are other uses of `\f(CW` in the document, and they > warn too. Due to the unpopularity of repeated font availability > warnings, GNU troff emits only one per font name.[1] In the > future, I'd like GNU troff to work more like a proper linter in > this respect, and issue a warning on each occurrence, there by > making it easier to drive an editor session by redirecting its > stderr to a file, and then editing that file with `vi -q`. > > Here's a patch to reformat the table of Pike-disapproved cat(1) > options more similarly to the original PostScript file. I have no > idea if K&P originally used tbl(1) for this purpose. I also > reduced the type size, as is apparent in the original PostScript, > and changed the option dashes to use the "correct" glyph, `\-`.[2] > > @@ -292,16 +292,19 @@ with features. This list comes from > .CW cat > on the Berkeley distribution of the UNIX system: > .PP > -.nf > -.in .5i > -\f(CW-s\fP strip multiple blank lines to a single instance > -\f(CW-n\fP number the output lines > -\f(CW-b\fP number only the non-blank lines > -\f(CW-v\fP make non-printing characters visible > - \f(CW-ve\fP mark ends of lines > - \f(CW-vt\fP change representation of tab > -.in -.5i > -.fi > +.RS > +.TS > +Lf(CR)p-1 Lp-1 S. > +\-s strip multiple blank lines to a single instance > +\-n number the output lines > +\-b number only the non-blank lines > +\-v make non-printing characters visible > +.T& > +L Lf(CR)p-1 Lp-1. > +\& \-ve mark ends of lines > +\& \-vt change representation of tab > +.TE > +.RE > .PP > In System V, there are similar options and even a clash of naming: > .CW -s > > (One could alternatively eschew the `p` column modifiers to the > table, and bracket the whole thing in `.ps -1` and `.ps` instead.) > > Using tbl(1) of course requires modification of the command line. > > $ groff -Rt -m s -T pdf unix_prog_design.ms >| unix_prog_design.pdf > > 6. Cleaning up another occurrences of font `CW`, I saw further > opportunities to use `\-` for Unix option dashes and also to employ > ms(7)'s `Q` and `U` strings for typographer's quotation marks. > However, the latter are 4.2BSD ms extensions--a fact I had not > documented in groff's ms(7) man page and "ms.ms" document! So I'll > take a note to myself to fix that. Using `` and '' appears to kern > the symbols more closely to the original. On the gripping hand, > passing 3 arguments to the `CW` macro _is_ a GNU extension in groff > ms(7). You can always get around that with `\c`, though. > > @@ -353,7 +356,8 @@ But what about > .CW -v ? > That prints non-printing characters in a visible > representation. Making strange characters visible is a genuinely new > -function, for which no existing program is suitable. (``\f(CWsed -n l\fP'', > +function, for which no existing program is suitable. > +.CW "sed \-n l" ``, '' > the closest standard possibility, aborts when given very long input > lines, which are more likely to occur in files containing non-printing > characters.) So isn't it appropriate to add the > > @@ -535,7 +539,8 @@ pr -$0 -t -l1 $* > is the program name (\c > .CW 2 , > .CW 3 , > -etc.), so \-\f(CW$0\fP > +etc.), so > +.CW $0 "" \- > becomes \-\fIn\fP > where > .I n > > 7. I see that the em dashes in the "use of cat" footnote now actually > appear. > > Great work! > > Regards, > Branden > > [1] https://lists.gnu.org/archive/html/groff/2024-10/msg00066.html > [2] https://lwn.net/Articles/947941/ From tuhs at tuhs.org Fri Jul 10 03:29:12 2026 From: tuhs at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS) Date: Thu, 09 Jul 2026 10:29:12 -0700 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: <202604010851.6318pCpZ096750@freefriends.org> References: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> <202604010851.6318pCpZ096750@freefriends.org> Message-ID: <79321654c912ced4@orthanc.ca> Arnold Robbins via TUHS writes: > I think at some point 9 track tape drives hit something like 6400 BPI, > but I may be hallucinating the memory. By at least the mid-1980s, 6250 BPI drives were available. But they were expensive, so software for geneneral distribution was usually shipped on 1600 BPI tapes to be comatible with the majority of tape drives. 6250 drives could read/write 1600 tapes, and many could handle 800 BPI as well. --lyndon From tuhs at tuhs.org Fri Jul 10 07:42:35 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 09 Jul 2026 21:42:35 +0000 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: <79321654c912ced4@orthanc.ca> References: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> <202604010851.6318pCpZ096750@freefriends.org> <79321654c912ced4@orthanc.ca> Message-ID: We had 6250 drives at BRL in the mid-eighties. I had one in my living room around 1987 when I was writing device drivers for the thing for a company I was working on the side for. It was a Multibus II system that I had reverse engineered the message passing coprocessor kernel drivers for. ------ Original Message ------ >From "Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS" To arnold at skeeve.com; "Arnold Robbins via TUHS" Date 7/9/2026 1:29:12 PM Subject [TUHS] Re: Choice of Tape Format for BTL UNIX Distro >Arnold Robbins via TUHS writes: > >> I think at some point 9 track tape drives hit something like 6400 BPI, >> but I may be hallucinating the memory. > >By at least the mid-1980s, 6250 BPI drives were available. But >they were expensive, so software for geneneral distribution was >usually shipped on 1600 BPI tapes to be comatible with the majority >of tape drives. > >6250 drives could read/write 1600 tapes, and many could handle 800 >BPI as well. > >--lyndon From tuhs at tuhs.org Sat Jul 11 10:12:41 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 11 Jul 2026 00:12:41 +0000 Subject: [TUHS] Help Preserving 8in LSX Floppies? Message-ID: Hello, exciting news, I've just received a whole bunch of 8" floppies, among them are two labeled: UNIX OPERATING SYSTEM LSX SYSTEM MASTER (10-29-77) There are two disks, the second of which additionally bears: /USR FILE SYSTEM so presumably the root and usr disks for LSX. Both are typed labels. Along with these are 6 with printed listings and hand-written labels indicating snapshots of the /usr directory from one or multiple LSX systems (some are labeled "original", some "development"). Two of the disks are source dumps of a kernel, with one looking like the file listing of a typical V6-ish kernel and the other having some extra LSX-ish bits, but its just path names so couldn't say what is contained therein. I currently have no means to extract 8" floppies, so wanted to ask if anyone on list is able to? I can't speak to the FS details although I imagine something like a V6-ish filesystem is involved. Raw dumps of the disks should allow decoding the FS at a later date. There are other floppies too, among them some snapshots of UNIX game source code as well as a smattering of RSX-11 and/or RT-11 stuff. Anywho, if anyone has the machinery, I'll happily pay for the shipping and your time. In the meantime I'll keep these safely tucked away. I'm primarily focused on the LSX stuff but maybe the other bits could be interesting too. - Matt G. From tuhs at tuhs.org Sat Jul 11 13:59:49 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Fri, 10 Jul 2026 20:59:49 -0700 Subject: [TUHS] Help Preserving 8in LSX Floppies? In-Reply-To: References: Message-ID: I've seen on Facebook that Dave Plummer has some PDP-11 floppy drives. Working? I dunno. On Fri, Jul 10, 2026 at 5:23 PM segaloco via TUHS wrote: > Hello, exciting news, I've just received a whole bunch of 8" floppies, > among them are two labeled: > > UNIX OPERATING SYSTEM LSX > SYSTEM MASTER (10-29-77) > > There are two disks, the second of which additionally bears: > > /USR FILE SYSTEM > > so presumably the root and usr disks for LSX. Both are typed labels. > Along with these are 6 with printed listings and hand-written labels > indicating snapshots of the /usr directory from one or multiple LSX systems > (some are labeled "original", some "development"). Two of the disks are > source dumps of a kernel, with one looking like the file listing of a > typical V6-ish kernel and the other having some extra LSX-ish bits, but its > just path names so couldn't say what is contained therein. > > I currently have no means to extract 8" floppies, so wanted to ask if > anyone on list is able to? I can't speak to the FS details although I > imagine something like a V6-ish filesystem is involved. Raw dumps of the > disks should allow decoding the FS at a later date. There are other > floppies too, among them some snapshots of UNIX game source code as well as > a smattering of RSX-11 and/or RT-11 stuff. > > Anywho, if anyone has the machinery, I'll happily pay for the shipping and > your time. In the meantime I'll keep these safely tucked away. I'm > primarily focused on the LSX stuff but maybe the other bits could be > interesting too. > > - Matt G. > From tuhs at tuhs.org Sat Jul 11 14:04:49 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 11 Jul 2026 14:04:49 +1000 Subject: [TUHS] Help Preserving 8in LSX Floppies? In-Reply-To: References: Message-ID: On Sat, Jul 11, 2026 at 12:12:41AM +0000, segaloco via TUHS wrote: > Hello, exciting news, I've just received a whole bunch of 8" floppies, among them are two labeled: > > UNIX OPERATING SYSTEM LSX > SYSTEM MASTER (10-29-77) > > There are two disks, the second of which additionally bears: > > /USR FILE SYSTEM > > so presumably the root and usr disks for LSX. Both are typed labels. Along with these are 6 with printed listings and hand-written labels indicating snapshots of the /usr directory from one or multiple LSX systems (some are labeled "original", some "development"). Two of the disks are source dumps of a kernel, with one looking like the file listing of a typical V6-ish kernel and the other having some extra LSX-ish bits, but its just path names so couldn't say what is contained therein. Matt, while you continue on with this journey, you might want to check here first: https://www.tuhs.org/Archive/Distributions/USDL/LSX/ as someone else has trodden this path before and they might have some clues and tips for you :-) Cheers, Warren From tuhs at tuhs.org Sat Jul 11 20:38:21 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Sat, 11 Jul 2026 06:38:21 -0400 (EDT) Subject: [TUHS] Help Preserving 8in LSX Floppies? Message-ID: <20260711103821.3E7BD18C077@mercury.lcs.mit.edu> > From: Warren Toomey > Matt, while you continue on with this journey, you might want to check > here ... as someone else has trodden this path before and they might > have some clues and tips for you :-) A fair amount of archaeology has already been performed on LSX: https://gunkies.org/wiki/LSX See in particular the "LSX Unix Restoration Page": https://www.mailcom.com/lsx/index.html which has the whole story of a prior reclamation, and Heinz' original BSTJ article on it, which he has put online here: https://www.heinzlycklama.com/docs/bstj57-6-2087.pdf The most useful thing you could find would be the two user-mode programs needed to support contiguous files (the kernel does not support the creation of such files; there were two separate user-mode programs, one to allocate space for such files, and one to move a file into such an area). It is possible they are already online somewhere in the prior reclamation, and I just didn't find them, but if not, perhaps your new set of floppies has them. Noel From tuhs at tuhs.org Sun Jul 12 14:51:38 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Sat, 11 Jul 2026 21:51:38 -0700 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk Message-ID: I finally managed to extract and format this document. Read it if you're in to horror literature! It comes from the 'memo' file in https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_virgin_source.tar.gz PDF here: https://drive.google.com/file/d/1eVfRW8QS7M11MfK4kFaWRMZLXtuLWjSj/view?usp=sharing Please, admins, grab a copy for the archive. From tuhs at tuhs.org Sun Jul 12 15:02:09 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Sun, 12 Jul 2026 05:02:09 +0000 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: References: Message-ID: <18579AD4-9F4E-4A1C-999D-4B75E22693D9@archibald.dev> On Jul 11, 2026, at 22:51, Tom Lyon wrote: > I finally managed to extract and format this document. > Read it if you're in to horror literature! > > Please, admins, grab a copy for the archive. I’ve added it as https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_memo.pdf Thanks! Thalia From tuhs at tuhs.org Mon Jul 13 05:27:26 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 12 Jul 2026 15:27:26 -0400 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: References: Message-ID: <20260712192727.42ED61154C11E@ary.qy> It appears that Tom Lyon via TUHS said: >I finally managed to extract and format this document. >Read it if you're in to horror literature! > >It comes from the 'memo' file in >https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_virgin_source.tar.gz > >PDF here: >https://drive.google.com/file/d/1eVfRW8QS7M11MfK4kFaWRMZLXtuLWjSj/view?usp=sharing I'm intrigued by the references to BLISS on TSS. Is that the same BLISS as on DEC macines? I never heard of a 370 version and neither has Wikipedia. From tuhs at tuhs.org Mon Jul 13 05:36:30 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Sun, 12 Jul 2026 19:36:30 +0000 Subject: [TUHS] IBM C compillers In-Reply-To: <20260712192727.42ED61154C11E@ary.qy> References: <20260712192727.42ED61154C11E@ary.qy> Message-ID: I had some experience with a C compiler written by the Oracle folk for VM/370. It had some interesting quirks. The most bizarre of which is that it didn’t follow the convention of sticking _ in front of symbols in the language in the assembler output. This led to some spectacular blowups when you named a global variable something like R15. From tuhs at tuhs.org Mon Jul 13 05:57:36 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Sun, 12 Jul 2026 12:57:36 -0700 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: <20260712192727.42ED61154C11E@ary.qy> References: <20260712192727.42ED61154C11E@ary.qy> Message-ID: There was work at NPS in 1972 on BLISS-360: https://archive.org/details/preliminarydesig00zavopdf https://ia800507.us.archive.org/2/items/stepstowardcompi00bahl/stepstowardcompi00bahl.pdf I doubt if it escaped to the wider world. On Sun, Jul 12, 2026 at 12:27 PM John Levine wrote: > It appears that Tom Lyon via TUHS said: > >I finally managed to extract and format this document. > >Read it if you're in to horror literature! > > > >It comes from the 'memo' file in > > > https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_virgin_source.tar.gz > > > >PDF here: > > > https://drive.google.com/file/d/1eVfRW8QS7M11MfK4kFaWRMZLXtuLWjSj/view?usp=sharing > > I'm intrigued by the references to BLISS on TSS. Is that the same BLISS > as on DEC > macines? I never heard of a 370 version and neither has Wikipedia. > From tuhs at tuhs.org Mon Jul 13 07:43:35 2026 From: tuhs at tuhs.org (John R Levine via TUHS) Date: 12 Jul 2026 17:43:35 -0400 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: References: <20260712192727.42ED61154C11E@ary.qy> Message-ID: <3f0705cf-ed6e-2fb3-2806-958025e02606@taugh.com> On Sun, 12 Jul 2026, Clem Cole wrote: > BLISS was CMU's system programming language, designed by Bill Wulf and his > students in the late 1960s/early 1970s. The original compiler was a PDP-10 > target (the urban legend is that it was bootstrapped using TECO macros, but > I don't believe that). BLISS-11 followed a few years later; it was a > cross-compiler that ran on TOPS-10 (it could not self-host). Compared to > Dennis's C compiler, a contemporary development, the code it generates makes > the UNIX C compiler seem almost like a toy (although C could self-host, > unlike BLISS-11). We used PDP-10 BLISS a lot when I was a grad student at Yale in the 1970s. We were aware of BLISS-11 but didn't use it, first because Ned Irons was working on his extensible IMP-72, and in 1976 I installed Unix on our PDP-11 and that's what we used. BLISS was a strange language due to everything being an expression and no implicit dereferencing (A=B would put the address of B into A, A = .B gets the contents of B) but once you got used to it, it was a very usable language. BLISS-11 did excellent optimization but it's my impression that on a PDP-11 if you wrote C code with reasonable register declarations, the code wasn't much worse even though the compiler was much less clever. > The CMU BLISS compiler is discussed in > the "Green Book," and after that experiment, quickly became the "how-to > manual" for compiler code generation/optimization: Yes, I have a copy. A few decades back I talked to Wulf about putting it back in print but we found it was available from a print-on-demand publisher, I think one that usually handled PhD theses. These days you can download it: https://archive.org/details/wulf-the-design-of-an-optimizing-compiler-1975 > As for the IBM 360 family, at some point, one of Gary Kildall's (of CP/M > fame - remember he was a compiler researcher, not an OS one) students at > the Naval Postgraduate School wrote a 360 ISA target; but I don't remember > the OS target for the original 360 compiler. .... Someone who knows the details should add that to the Wikipedia article on BLISS. R's, John From tuhs at tuhs.org Mon Jul 13 06:50:45 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 12 Jul 2026 16:50:45 -0400 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: <20260712192727.42ED61154C11E@ary.qy> References: <20260712192727.42ED61154C11E@ary.qy> Message-ID: BLISS was CMU's system programming language, designed by Bill Wulf and his students in the late 1960s/early 1970s. The original compiler was a PDP-10 target (the urban legend is that it was bootstrapped using TECO macros, but I don't believe that). BLISS-11 followed a few years later; it was a cross-compiler that ran on TOPS-10 (it could not self-host). Compared to Dennis's C compiler, a contemporary development, the code it generates makes the UNIX C compiler seem almost like a toy (although C could self-host, unlike BLISS-11). In those days, there was very much a belief in the "systems" community that you had to write in assembler for any "real" or "production." Famously, Wulf took a bunch of his best BLISS programmers and the best PDP-11 programmers they knew and gave them a bunch of functions/programs to write. It turned out that for any code longer than 10 lines of assembler, BLISS did as well as or better. The CMU BLISS compiler is discussed in the "Green Book," and after that experiment, quickly became the "how-to manual" for compiler code generation/optimization: [image: BLISS_GreenBook_Cover.png] Gordon Bell was on the CMU faculty in those days, and he brought BLISS to DEC (and a number of former Wulf's students became the core of the DEC Tech Languages Group - TLG). BLISS quickly became the primary system programming language for most everything (note Culter hated BLISS - which is why VMS was written in assembler, but that's a different story). I've written elsewhere about the huge mistake DEC marketing made (they were charging $5K per CPU, so too few customers ended up buying it). Yes, the ARPA research community (CMU, MIT, Stanford, et al) all had it, as did a lot of DOD/DOE contractors, but for the rest of the world, particularly universities, when you had the sources to C (and it was self-hosting) and came with UNIX all for $100, it wasn't a fair fight. † As for the IBM 360 family, at some point, one of Gary Kildall's (of CP/M fame - remember he was a compiler researcher, not an OS one) students at the Naval Postgraduate School wrote a 360 ISA target; but I don't remember the OS target for the original 360 compiler. CMU was also famously a 360/67 TSS shop. I don't remember if CMU took it back and did the TSS support; but it was on our 360/67 (along with PL/360 from Stanford) when I worked in the computer center. I think I may still have some of the docs. Note, Bell Labs was also TSS Shop (ISTR that the original Unix port ran under TSS - Tom, did you remember?). Clem † I've also mentioned I learned BLISS before C and was really disappointed with Dennis' compiler when I first saw it. But I quickly joined the C team when I realized it was much easier to write and compile programs (the PDP-10s and 20s were always way overloaded). On Sun, Jul 12, 2026 at 3:27 PM John Levine via TUHS wrote: > It appears that Tom Lyon via TUHS said: > >I finally managed to extract and format this document. > >Read it if you're in to horror literature! > > > >It comes from the 'memo' file in > > > https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_virgin_source.tar.gz > > > >PDF here: > > > https://drive.google.com/file/d/1eVfRW8QS7M11MfK4kFaWRMZLXtuLWjSj/view?usp=sharing > > I'm intrigued by the references to BLISS on TSS. Is that the same BLISS > as on DEC > macines? I never heard of a 370 version and neither has Wikipedia. > From tuhs at tuhs.org Wed Jul 15 06:42:47 2026 From: tuhs at tuhs.org (Aron Insinga via TUHS) Date: Tue, 14 Jul 2026 16:42:47 -0400 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: References: <20260712192727.42ED61154C11E@ary.qy> Message-ID: Clem, thank you for these details! Here is the full version of Ron Brender's history of how BLISS was adopted and evolved by DEC.  (Truncated versions have been published elsewhere.)  In recent years BLISS and VMS have been ported by VSI to the X86_64. https://archive.org/details/full-bliss-history And since you mentioned comparison of the BLISS and C generated code, here's a short paper written by a friend: https://archive.org/details/bliss-11-a-lesson-in-object-code-optimization/ One of the things I am trying to find so I can scan it is the report by the Implementation Language Task Force.  They knew that C existed but I don't think they knew much about it and couldn't get it.  I don't recall if they mentioned BCPL but as another typeless language, I'm sure they would have found that it had no advantage over BLISS.  (Really, BLISS-10 was an operator typed language, e.g. different infix operators for single-precision integer and single-precision floating point addition.  And the bit field operators (X<.p1,.s> = .Y<.p2,.s>) were wonderful for bit-twiddling.  Yeah, the '.' fetch operator was a royal pain.)  I remember that they considered PL/I but thought its compiler would be too big for DEC computers.  I don't recall if they looked at subsets or at Algol a la Burroughs.  But they had BLISS-10 and BLISS-11 to bootstrap with and Ron's experience from BLISS-11 on how to extend the language for shorter word-length machines.  (Operations on things that don't fit into a single word are done by reference. There were a bunch of compile-time constants for bits per word [%BPVAL: 32 for a VAX], addressing units per word [%UPVAL: 4], and bits per addressing unit [%BPUNIT: 8], if I remember them correctly; I sure typed them enough.  And there was one heck of a phenomenal compile-time facility/macro processor.  BLISS code could be parameterized for different architectures.) In later days (at HP or VSI?) some bits of VMS (I don't know which or how big they were) got rewritten in C from several languages that had crept in. Oh, and one lesson for language design: BLISS stopped being an expression language (LEAVE WITH) at some point, to preserve locality of reference for the reader.  Consider: X=(IF .condition THEN (     ! a lot of code to compute foo     .foo ) ELSE (     ! a lot of code to compute bar     .bar )); ! now what did we do with the values of those blocks? [If I said something conflicting with what Ron wrote, assume he's right and I had a memory parity error.] If I may add a diversion about a project that used BLISS and was influenced by BLISS: I wrote the compiler for the DECSIM logic simulator's behavior modeling language compiler.  This was a successor to SAGE2's use of, IIRC, preprocessed BLISS-10: more CMU heritage.  DECSIM was to run on both the 36-bit and 32-bit machines so it was all written in Common BLISS.  We were not connected with DEC's compiler groups, so instead of writing 2 code generators, I generated Common BLISS code.  I used the green BLISS book (LEXSYNFLOW and all that) as a guide, and my compiler was *not* a simple preprocessor; it built an AST, propagated attributes up [like width of concatenated bit vectors] and down the tree, and finally traversed the tree emitting the BLISS code for the object code.  For simple things [2-state, 32-bits] it looked like a direct BLISS translation; a lot of the rest was nested function calls.  Co-routines, where needed for ACTIVATE and WAIT, were done with a big switch statement taking a 'virtual program counter' to know where to resume execution; it was simple and I was working alone.  It also generated a binary file of the data descriptors used by the logic simulation engine and run-time library.  Because of the BLISS environment, I hammered the wishlist into a language by stealing the control flow statements from BLISS, and adding ACTIVATE and WAIT, but this language had both operator types and certain data types for logic simulation: 2-state and 4-state (0, 1, Undefined, and Z/High Impedance) bit vectors, and time.  By the time we were done, I think the 36-bit architectures were cancelled.  (The simulator kernel folks really only wanted the VAX's address space (for fault simulation) anyway.)  I had a short paper in ICCAD -84 and others (e.g. Sherwood, Ulrich) wrote a lot more papers about DECSIM, but those were the days that ECAD tools (aside from University projects like SAGE)were developed internally and kept proprietary in hopes of getting a competitive advantage from them.  Nate Phillips, who wrote the run-time functions e.g. 4-state operations, spent some time (at Stanford?) working on logic synthesis and they used the compiler for that. (Oh, an aside**2, I wanted to call the behavior language Sybil but the team insisted on a good acronym which I couldn't come up with. (I thought it was also a fitting from Classical History.  I don't remember what other spellings I tried, if any.)  As with JavaScript, I tried worse names (cf. ECMAScript) but they didn't stick well either.  In the end the CAD tool suite folks came up with .SDS (Structure DECSIM) instead of .NET and .BDS (Behavior DECSIM) file types and hence language names, based on the keyword that specified the model type, a bit redundant.) Anyway, thanks for listening.  More info when I find it. - Aron On 7/12/26 16:50, Clem Cole via TUHS wrote: > BLISS was CMU's system programming language, designed by Bill Wulf and his > students in the late 1960s/early 1970s. The original compiler was a PDP-10 > target (the urban legend is that it was bootstrapped using TECO macros, but > I don't believe that). BLISS-11 followed a few years later; it was a > cross-compiler that ran on TOPS-10 (it could not self-host). Compared to > Dennis's C compiler, a contemporary development, the code it generates makes > the UNIX C compiler seem almost like a toy (although C could self-host, > unlike BLISS-11). > > In those days, there was very much a belief in the "systems" community that > you had to write in assembler for any "real" or "production." Famously, > Wulf took a bunch of his best BLISS programmers and the best PDP-11 > programmers they knew and gave them a bunch of functions/programs to > write. It turned out that for any code longer than 10 lines of assembler, > BLISS did as well as or better. The CMU BLISS compiler is discussed in > the "Green Book," and after that experiment, quickly became the "how-to > manual" for compiler code generation/optimization: > [image: BLISS_GreenBook_Cover.png] > Gordon Bell was on the CMU faculty in those days, and he brought BLISS to > DEC (and a number of former Wulf's students became the core of the DEC Tech > Languages Group - TLG). BLISS quickly became the primary system > programming language for most everything (note Culter hated BLISS - which > is why VMS was written in assembler, but that's a different story). I've > written elsewhere about the huge mistake DEC marketing made (they were > charging $5K per CPU, so too few customers ended up buying it). Yes, the > ARPA research community (CMU, MIT, Stanford, et al) all had it, as did a > lot of DOD/DOE contractors, but for the rest of the world, particularly > universities, when you had the sources to C (and it was self-hosting) and > came with UNIX all for $100, it wasn't a fair fight. † > > As for the IBM 360 family, at some point, one of Gary Kildall's (of CP/M > fame - remember he was a compiler researcher, not an OS one) students at > the Naval Postgraduate School wrote a 360 ISA target; but I don't remember > the OS target for the original 360 compiler. CMU was also famously a > 360/67 TSS shop. I don't remember if CMU took it back and did the TSS > support; but it was on our 360/67 (along with PL/360 from Stanford) when I > worked in the computer center. I think I may still have some of the docs. > > Note, Bell Labs was also TSS Shop (ISTR that the original Unix port ran > under TSS - Tom, did you remember?). > > Clem > > > † I've also mentioned I learned BLISS before C and was really disappointed > with Dennis' compiler when I first saw it. But I quickly joined the C team > when I realized it was much easier to write and compile programs (the > PDP-10s and 20s were always way overloaded). > > On Sun, Jul 12, 2026 at 3:27 PM John Levine via TUHS wrote: > >> It appears that Tom Lyon via TUHS said: >>> I finally managed to extract and format this document. >>> Read it if you're in to horror literature! >>> >>> It comes from the 'memo' file in >>> >> https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_virgin_source.tar.gz >>> PDF here: >>> >> https://drive.google.com/file/d/1eVfRW8QS7M11MfK4kFaWRMZLXtuLWjSj/view?usp=sharing >> >> I'm intrigued by the references to BLISS on TSS. Is that the same BLISS >> as on DEC >> macines? I never heard of a 370 version and neither has Wikipedia. >> From tuhs at tuhs.org Wed Jul 15 08:49:53 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Tue, 14 Jul 2026 15:49:53 -0700 Subject: [TUHS] Help Preserving 8in LSX Floppies? In-Reply-To: References: Message-ID: <0f570b20-c7a4-4e26-ac26-65bb7ab87757@mhorton.net> Hi, Matt. A couple decades ago, someone abandoned an 8" floppy drive on my doorstep. I haven't done anything with it, but it's still in my museum. It's labelled Honeywell, but Google says it's an OEM CDC 9404/9406. It has two quarter-sized DIN connectors on the back (for "power" and "logic"). The floppy door in front does not latch. It weighs about 17 pounds. There are no cables (not even a power cable). I doubt it's very useful, but if you're up for hardware restoration and interface I'll work with you to get it to you. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Keynote Speaker on Inclusion and Innovation       Award Winning Author maryannhorton.com On 7/10/26 17:12, segaloco via TUHS wrote: > Hello, exciting news, I've just received a whole bunch of 8" floppies, among them are two labeled: > > UNIX OPERATING SYSTEM LSX > SYSTEM MASTER (10-29-77) > > There are two disks, the second of which additionally bears: > > /USR FILE SYSTEM > > so presumably the root and usr disks for LSX. Both are typed labels. Along with these are 6 with printed listings and hand-written labels indicating snapshots of the /usr directory from one or multiple LSX systems (some are labeled "original", some "development"). Two of the disks are source dumps of a kernel, with one looking like the file listing of a typical V6-ish kernel and the other having some extra LSX-ish bits, but its just path names so couldn't say what is contained therein. > > I currently have no means to extract 8" floppies, so wanted to ask if anyone on list is able to? I can't speak to the FS details although I imagine something like a V6-ish filesystem is involved. Raw dumps of the disks should allow decoding the FS at a later date. There are other floppies too, among them some snapshots of UNIX game source code as well as a smattering of RSX-11 and/or RT-11 stuff. > > Anywho, if anyone has the machinery, I'll happily pay for the shipping and your time. In the meantime I'll keep these safely tucked away. I'm primarily focused on the LSX stuff but maybe the other bits could be interesting too. > > - Matt G. From tuhs at tuhs.org Wed Jul 15 09:19:19 2026 From: tuhs at tuhs.org (Charles H Sauer (he/him) via TUHS) Date: Tue, 14 Jul 2026 18:19:19 -0500 Subject: [TUHS] Help Preserving 8in LSX Floppies? In-Reply-To: <0f570b20-c7a4-4e26-ac26-65bb7ab87757@mhorton.net> References: <0f570b20-c7a4-4e26-ac26-65bb7ab87757@mhorton.net> Message-ID: <180b10fe-f004-4f96-895a-ee5a9af16993@technologists.com> I've been hesitant to jump in to the discussion since what I say probably won't be useful, but if anyone has access to a working IBM Displaywriter (https://en.wikipedia.org/wiki/IBM_Displaywriter_System), that machine might be useful. I presume in terms of numbers that IBM shipped far more of those than any other product that used 8" diskettes. Though primarily (a pretty nice) "word processor," it was 8086 based and could run MS-DOS. (I don't remember if DOS was publicly available or not, but I had a copy for my unit. I mostly used mine for 3270 emulation to access VM/370. That environment seemed nicer to me than a real 3277.) Charlie On 7/14/2026 5:49 PM, Mary Ann Horton via TUHS wrote: > Hi, Matt. > > A couple decades ago, someone abandoned an 8" floppy drive on my > doorstep. I haven't done anything with it, but it's still in my museum. > > It's labelled Honeywell, but Google says it's an OEM CDC 9404/9406. It > has two quarter-sized DIN connectors on the back (for "power" and > "logic"). The floppy door in front does not latch. It weighs about 17 > pounds. There are no cables (not even a power cable). > > I doubt it's very useful, but if you're up for hardware restoration and > interface I'll work with you to get it to you. > > Thanks, > > /Mary Ann Horton/ (she/her/ma'am) >       Keynote Speaker on Inclusion and Innovation >       Award Winning Author > maryannhorton.com > > > > On 7/10/26 17:12, segaloco via TUHS wrote: >> Hello, exciting news, I've just received a whole bunch of 8" floppies, >> among them are two labeled: >> >> UNIX OPERATING SYSTEM LSX >> SYSTEM MASTER (10-29-77) >> >> There are two disks, the second of which additionally bears: >> >> /USR FILE SYSTEM >> >> so presumably the root and usr disks for LSX.  Both are typed labels. >> Along with these are 6 with printed listings and hand-written labels >> indicating snapshots of the /usr directory from one or multiple LSX >> systems (some are labeled "original", some "development").  Two of the >> disks are source dumps of a kernel, with one looking like the file >> listing of a typical V6-ish kernel and the other having some extra >> LSX-ish bits, but its just path names so couldn't say what is >> contained therein. >> >> I currently have no means to extract 8" floppies, so wanted to ask if >> anyone on list is able to?  I can't speak to the FS details although I >> imagine something like a V6-ish filesystem is involved.  Raw dumps of >> the disks should allow decoding the FS at a later date.  There are >> other floppies too, among them some snapshots of UNIX game source code >> as well as a smattering of RSX-11 and/or RT-11 stuff. >> >> Anywho, if anyone has the machinery, I'll happily pay for the shipping >> and your time.  In the meantime I'll keep these safely tucked away. >> I'm primarily focused on the LSX stuff but maybe the other bits could >> be interesting too. >> >> - Matt G. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From tuhs at tuhs.org Wed Jul 15 12:06:07 2026 From: tuhs at tuhs.org (Jacob Ritorto via TUHS) Date: Tue, 14 Jul 2026 22:06:07 -0400 Subject: [TUHS] Help Preserving 8in LSX Floppies? In-Reply-To: References: Message-ID: <1B596B4E-9CF3-4662-909A-DC1F1C6998D9@gmail.com> Hey Matt. I have a working RX02 on my 11/34 (and I have the means to connect it to the ‘83, which is on the internet for transferring). It’s been running reliably for quite some years, now, and hasn’t marred any floppies that I know of. Gets cleaned when it needs it and gets used a few times a year to keep it spry. I’d be happy to give imaging your diskettes a go (after head cleaning and testing some scratch floppies, of course), but only choose me after giving first dibs to the professionals here who have serious pro archiving kit. My collection is only “best effort” hobby systems that I’ve scraped together for love, though I’m overeager to make honest use of them in times like these. Cheers Jake > On Jul 10, 2026, at 20:12, segaloco via TUHS wrote: > > Hello, exciting news, I've just received a whole bunch of 8" floppies, among them are two labeled: > > UNIX OPERATING SYSTEM LSX > SYSTEM MASTER (10-29-77) > > There are two disks, the second of which additionally bears: > > /USR FILE SYSTEM > > so presumably the root and usr disks for LSX. Both are typed labels. Along with these are 6 with printed listings and hand-written labels indicating snapshots of the /usr directory from one or multiple LSX systems (some are labeled "original", some "development"). Two of the disks are source dumps of a kernel, with one looking like the file listing of a typical V6-ish kernel and the other having some extra LSX-ish bits, but its just path names so couldn't say what is contained therein. > > I currently have no means to extract 8" floppies, so wanted to ask if anyone on list is able to? I can't speak to the FS details although I imagine something like a V6-ish filesystem is involved. Raw dumps of the disks should allow decoding the FS at a later date. There are other floppies too, among them some snapshots of UNIX game source code as well as a smattering of RSX-11 and/or RT-11 stuff. > > Anywho, if anyone has the machinery, I'll happily pay for the shipping and your time. In the meantime I'll keep these safely tucked away. I'm primarily focused on the LSX stuff but maybe the other bits could be interesting too. > > - Matt G. From tuhs at tuhs.org Wed Jul 15 12:15:07 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 15 Jul 2026 02:15:07 +0000 Subject: [TUHS] Help Preserving 8in LSX Floppies? In-Reply-To: <1B596B4E-9CF3-4662-909A-DC1F1C6998D9@gmail.com> References: <1B596B4E-9CF3-4662-909A-DC1F1C6998D9@gmail.com> Message-ID: <4HWFUIhU7_NLowpQ_NGDL63tkmL89qJHiVja4YKrM6GdH_LtA_dT_AoyWtKUX5-v5b-mMbVY2s-as0fPq0_LonTaTkA3AzqXctI4IeeYI6c=@protonmail.com> Thanks for the outpouring of offers everyone. Yufeng Gao has offered to image every 8" floppy I've got in this lot, so once his schedule opens up we'll be coordinating on this archival job. I'll notify the larger group in the future when/if we recover anything noteworthy. Probably won't be til late-August/September til I ship the disks out. More to come! - Matt G. From tuhs at tuhs.org Sat Jul 18 04:53:39 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Fri, 17 Jul 2026 13:53:39 -0500 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: References: Message-ID: <20260717185339.3m2ch64ohx24i2fg@illithid> Hi Tom, At 2026-07-11T21:51:38-0700, Tom Lyon via TUHS wrote: > I finally managed to extract and format this document. > Read it if you're in to horror literature! > > It comes from the 'memo' file in > https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_virgin_source.tar.gz > > PDF here: > https://drive.google.com/file/d/1eVfRW8QS7M11MfK4kFaWRMZLXtuLWjSj/view?usp=sharing What troff did you use to format this document? I ran into some interesting problems with it, including one that chokes every tbl(1) I have on hand to throw at it--except maybe Seventh Edition Unix tbl, which I did not attempt. Here's the litany of failure: $ tbl memo >/dev/null # groff 1.24.1 tbl:memo:532: error: invalid column classifier 'h' tbl:memo:532: error: giving up on this table region $ dwb tbl memo >/dev/null # DWB 3.3 File memo, line 532: Bad table specification character 'h' tbl quits $ solaris10 tbl memo >/dev/null # GitHub Solaris10-ditroff memo: line 532: bad table specification character tbl quits $ heirloom tbl memo >/dev/null memo: line 532: bad table specification character tbl quits $ 9 tbl memo >/dev/null # GitHub plan9port memo:532: warning: unrecognized column modifier character 'h' memo:532: warning: unrecognized column modifier character 'K' memo:532: warning: unrecognized column modifier character 'm' memo:532: warning: unrecognized column modifier character 'o' memo:532: warning: unrecognized column modifier character 'K' memo:532: warning: unrecognized column modifier character 'm' memo:532: warning: unrecognized column modifier character 'o' memo:532: warning: unrecognized column modifier character 'H' memo:532: warning: unrecognized column modifier character 'o' memo:532: too many columns in table tbl quits The cause of all this trouble is straightforward. $ sed -n '530,532p' memo .TS l l l l l l Character KA mode KB mode Holmdel Standard There's no '.' at the end of the table description. Some use of custom macros that have no evident definitions anywhere in the tar archive are apparent. $ sed -n '856,860p' memo that may not be mixed with data. Consider declarations of the form .ip char *listp[] {"first", "second", "third"}; .tp A page-local macro `mn` _is_ defined (at the top of the document), but in one place it is misspelled. This is a silent failure on AT&T troff, but not necessarily with GNU troff, to which you can give the `-w mac` option to diagnose calls of undefined macros (or requests, or interpolations of undefined diversions). I'm attaching some "modernizing" fixups for the document, in case anyone's interested. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Sat Jul 18 05:00:23 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Fri, 17 Jul 2026 12:00:23 -0700 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: <20260717185339.3m2ch64ohx24i2fg@illithid> References: <20260717185339.3m2ch64ohx24i2fg@illithid> Message-ID: I used groff. I was stumped for a long time with the tbl missing '.' problem. I was never any good with *roff and all the macros. On Fri, Jul 17, 2026 at 11:53 AM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi Tom, > > At 2026-07-11T21:51:38-0700, Tom Lyon via TUHS wrote: > > I finally managed to extract and format this document. > > Read it if you're in to horror literature! > > > > It comes from the 'memo' file in > > > https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_virgin_source.tar.gz > > > > PDF here: > > > https://drive.google.com/file/d/1eVfRW8QS7M11MfK4kFaWRMZLXtuLWjSj/view?usp=sharing > > What troff did you use to format this document? I ran into some > interesting problems with it, including one that chokes every tbl(1) I > have on hand to throw at it--except maybe Seventh Edition Unix tbl, > which I did not attempt. > > Here's the litany of failure: > > $ tbl memo >/dev/null # groff 1.24.1 > tbl:memo:532: error: invalid column classifier 'h' > tbl:memo:532: error: giving up on this table region > $ dwb tbl memo >/dev/null # DWB 3.3 > File memo, line 532: Bad table specification character 'h' > tbl quits > $ solaris10 tbl memo >/dev/null # GitHub Solaris10-ditroff > memo: line 532: bad table specification character > tbl quits > $ heirloom tbl memo >/dev/null > > memo: line 532: bad table specification character > tbl quits > $ 9 tbl memo >/dev/null # GitHub plan9port > > memo:532: warning: unrecognized column modifier character 'h' > > memo:532: warning: unrecognized column modifier character 'K' > > memo:532: warning: unrecognized column modifier character 'm' > > memo:532: warning: unrecognized column modifier character 'o' > > memo:532: warning: unrecognized column modifier character 'K' > > memo:532: warning: unrecognized column modifier character 'm' > > memo:532: warning: unrecognized column modifier character 'o' > > memo:532: warning: unrecognized column modifier character 'H' > > memo:532: warning: unrecognized column modifier character 'o' > > memo:532: too many columns in table > tbl quits > > The cause of all this trouble is straightforward. > > $ sed -n '530,532p' memo > .TS > l l l l l l > Character KA mode KB mode Holmdel Standard > > There's no '.' at the end of the table description. > > Some use of custom macros that have no evident definitions anywhere in > the tar archive are apparent. > > $ sed -n '856,860p' memo > that may not be mixed with data. Consider declarations of > the form > .ip > char *listp[] {"first", "second", "third"}; > .tp > > A page-local macro `mn` _is_ defined (at the top of the document), but > in one place it is misspelled. This is a silent failure on AT&T troff, > but not necessarily with GNU troff, to which you can give the `-w mac` > option to diagnose calls of undefined macros (or requests, or > interpolations of undefined diversions). > > I'm attaching some "modernizing" fixups for the document, in case > anyone's interested. > > Regards, > Branden > From tuhs at tuhs.org Sat Jul 18 05:05:49 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Fri, 17 Jul 2026 14:05:49 -0500 Subject: [TUHS] "Notes on the IBM C Compiler" by Mike Lesk In-Reply-To: References: <20260717185339.3m2ch64ohx24i2fg@illithid> Message-ID: <20260717190549.kyu5sifebpgrdsrv@illithid> At 2026-07-17T12:00:23-0700, Tom Lyon wrote: > I used groff. > I was stumped for a long time with the tbl missing '.' problem. > I was never any good with *roff and all the macros. The mavens of the groff mailing list stand ready to take on challenges. I feel like I've gotten good at *roff, but Tadziu Hoffman is a wizard! Clem let me know that my attachment got scrubbed--incredibly, I didn't forget to attach it for once--so here it is inline. --- memo 1976-01-16 09:46:22.000000000 -0600 +++ memo.gbr 2026-07-17 13:41:27.213368183 -0500 @@ -1,3 +1,4 @@ +.if \n(GS .ds MH \" empty .de mn .sp .ne 3 @@ -528,7 +529,7 @@ .ce Character Set Variation .TS -l l l l l l +l l l l l l. Character KA mode KB mode Holmdel Standard \e backslash E0 5F E0 E0 ' single quote AE 7D 7D 7D* @@ -855,9 +856,11 @@ Uses the location counter for strings being initialized externally that may not be mixed with data. Consider declarations of the form -.ip +.IP +.CW char *listp[] {"first", "second", "third"}; -.tp +.R +.LP .mn litloc Uses the location counter for literals. Mixed with either code or data. @@ -890,7 +893,7 @@ Accept a call from the supervisor program. .mn subretrn Return for a call received by subsave. -.mm stackdo +.mn stackdo Define the automatic variable stack. .mn prolog Entry code for a C routine: defines base Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Sat Jul 18 18:54:30 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 18 Jul 2026 08:54:30 +0000 Subject: [TUHS] The Curious Case of "x"-suffixed Kernel Headers in 50 Changes Message-ID: I stumbled across something tonight that has me a bit curious. So both Program Generic 3 and CB-UNIX 2.3 include a series of "x"-suffixed headers in the kernel which contain the declarations for a number of kernel data structures. For instance, filex.h in PG3 is: > /* > * Allocation for the file table. > */ > struct file file[NFILE]; Well, the "50 Changes" tape issued between V6 and V7 also includes similar header changes, for instance: > ------ filex.h > 0a1,4 > > /* > > * Allocation for the file table. > > */ > > struct file file[NFILE]; Several other bits from "50 Changes" appear in both PG3 and PWB1, suggesting both were based on at least some portion of this updated V6, for instance both include pause(2), alarm(2), and access(2). However, neither PWB1 nor V7 include these "x"-suffixed headers. Additionally, they are not in System III and beyond, suggesting they did not work their way into UNIX/TS either. This leaves the Program Generic and CB-UNIX lineages as the only ones that demonstrate this (although I have not gone looking to see if these are in No. 2 SCCS UNIX yet, I don't have kernel sources unfortunately but I may have a file schedule somewhere.) Anywho, this suggests some interesting context for the "50 Changes" tape. My speculative brain wants to say this may indicate that the changes swept up some USG-ish UNIX stuff, but this is just speculation. Does anyone know the absolute providence of the 50 Changes tape? Is it possible that the kernel version therein is a little more USG-ish than research? That said, when you get down to sysent, the message passing and error reporting features of USG UNIX are simply stubbed out as "reserved for USG", where these are implemented in PG3. By the way, the reason I'm looking into this 50 Changes tape is I want to make a cleaner diff between V6 *at the time USG would've sampled it* and PG3. Many of the 50 Changes are also in PG3, so presumably there is a common ancestor, but the whole filex.h et. al. matter has certainly muddied the situation. If I didn't know any better, I'd want to believe the 50 Changes is the patch from V6 to USG PG1, but that might be too far of a reach. - Matt G. From tuhs at tuhs.org Sun Jul 19 20:00:07 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sun, 19 Jul 2026 20:00:07 +1000 Subject: [TUHS] The Curious Case of "x"-suffixed Kernel Headers in 50 Changes In-Reply-To: References: Message-ID: On Sat, Jul 18, 2026 at 08:54:30AM +0000, segaloco via TUHS wrote: > I stumbled across something tonight that has me a bit curious. So both > Program Generic 3 and CB-UNIX 2.3 include a series of "x"-suffixed > headers in the kernel which contain the declarations for a number of > kernel data structures. For instance, filex.h in PG3 is: > > > /* > > * Allocation for the file table. > > */ > > struct file file[NFILE]; > > Well, the "50 Changes" tape issued between V6 and V7 also includes > similar header changes, for instance: > > > ------ filex.h > > 0a1,4 > > > /* > > > * Allocation for the file table. > > > */ > > > struct file file[NFILE]; > > Several other bits from "50 Changes" appear in both PG3 and PWB1, > suggesting both were based on at least some portion of this updated V6, > for instance both include pause(2), alarm(2), and access(2). However, > neither PWB1 nor V7 include these "x"-suffixed headers. Additionally, > they are not in System III and beyond, suggesting they did not work > their way into UNIX/TS either. This leaves the Program Generic and > CB-UNIX lineages as the only ones that demonstrate this (although I have > not gone looking to see if these are in No. 2 SCCS UNIX yet, I don't > have kernel sources unfortunately but I may have a file schedule > somewhere.) > > Anywho, this suggests some interesting context for the "50 Changes" > tape. My speculative brain wants to say this may indicate that the > changes swept up some USG-ish UNIX stuff, but this is just speculation. > Does anyone know the absolute providence of the 50 Changes tape? Is it > possible that the kernel version therein is a little more USG-ish than > research? That said, when you get down to sysent, the message passing > and error reporting features of USG UNIX are simply stubbed out as > "reserved for USG", where these are implemented in PG3. Ken gave a diff to Greg Chesson on the way to Berkeley. This was later distributed by Mike O'Brien. Salus QCU, pp 132,138-139 Unix News, November 1976, p 1 https://archive.org/details/unix_news_november-1976 Ken was at Berkeley from September 1975 to June 1976. (determined from Ken's correspondence with Tony Marsland University of Alberta Archives, Tony Marsland fonds UAA-2004-058-061-003 UAA-2004-058-061-007) diff is 'unix_changes', notes by Mike and Ken in 'changenotes' relevant notes for *x.h headers: from Mike: 1) Space allocation for buf, file, inode, proc, text, and u split out into separate files (see notes). from Ken: 1) Separate definition and declarations of tables: a more portable C will require that there be only one space definition in a group of programs. This has to do with loader restrictions that are on some notable big blue machines. > > By the way, the reason I'm looking into this 50 Changes tape is I want > to make a cleaner diff between V6 *at the time USG would've sampled it* > and PG3. Many of the 50 Changes are also in PG3, so presumably there > is a common ancestor, but the whole filex.h et. al. matter has > certainly muddied the situation. If I didn't know any better, I'd > want to believe the 50 Changes is the patch from V6 to USG PG1, but > that might be too far of a reach. *x.h headers aren't in PG2 going by https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1046_UNIX_Support_Classifications_for_PG_1C300_Issue_2.pdf From tuhs at tuhs.org Mon Jul 20 03:37:11 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 19 Jul 2026 11:37:11 -0600 Subject: [TUHS] Off topic: anyone interested in this book? Message-ID: <202607191737.66JHbBBF094650@freefriends.org> Hi All. I'm going through my shelves to start getting rid of books that I've either never opened or won't ever open again. I found the following: Numerical Methods and Software David Kahaner, Cleve Moler, Stephen Nash Prentice Hall, 1977 ISBN 0-13-627258-4 With software on (5-1/4") diskette Please let me know you're interested. First one to respond wins. :-) Thanks, Arnold From tuhs at tuhs.org Mon Jul 20 04:12:22 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 19 Jul 2026 18:12:22 +0000 Subject: [TUHS] The Curious Case of "x"-suffixed Kernel Headers in 50 Changes In-Reply-To: References: Message-ID: On Sunday, July 19th, 2026 at 03:00, Jonathan Gray via TUHS wrote: > > *x.h headers aren't in PG2 going by > https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1046_UNIX_Support_Classifications_for_PG_1C300_Issue_2.pdf > D'oh, good catch. I suspect that then indicates this was a very late change prior to UNIX/TS introduction and filtered out to USG and Columbus, but PWB didn't get it in time and jumped to UNIX/TS in the 2.0 days. Too bad we can't get a file schedule of PWB 1.1 or 1.2, I wonder if either had this brief change... Still, that makes it less likely this is some USG shenanigans and just late C-UNIX stuff prior to portability work. - Matt G. From tuhs at tuhs.org Wed Jul 22 01:07:27 2026 From: tuhs at tuhs.org (Aharon Robbins via TUHS) Date: Tue, 21 Jul 2026 18:07:27 +0300 Subject: [TUHS] Requesting some setup Message-ID: Hi All. I am starting (at a snail's pace) to go through a lot of the dusty files on my system(s). Much of it might be of interest to TUHS. Can we set up an email address like archivists at tuhs.org where I could just send stuff and rely on it being handled? Also, for bigger stuff, can there be a public ftp upload directory? For example, I found a bunch of Modula-3 stuff for *nix from ~ 2005 or so. But there's lots more. Most or all of which I'll never do anything with, so instead of just deleting it forever, I can at least see if TUHS is interested in it. Thanks, Arnold From tuhs at tuhs.org Wed Jul 22 05:34:33 2026 From: tuhs at tuhs.org (David Barto via TUHS) Date: Tue, 21 Jul 2026 12:34:33 -0700 Subject: [TUHS] I'm sure someone has done this already Message-ID: <7F3B90D2-E29B-4B78-8C36-FAF95478BB9C@kdbarto.org> Take the v6, v7, 32v etc Unix Kernel and related software and run Claude (or some other AI) on the code to see what it says about potential security or software bugs exist. I’m sure it would have interesting results. David From tuhs at tuhs.org Wed Jul 22 06:39:27 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 21 Jul 2026 20:39:27 +0000 Subject: [TUHS] I'm sure someone has done this already In-Reply-To: <7F3B90D2-E29B-4B78-8C36-FAF95478BB9C@kdbarto.org> References: <7F3B90D2-E29B-4B78-8C36-FAF95478BB9C@kdbarto.org> Message-ID: On Tuesday, July 21st, 2026 at 12:34, David Barto via TUHS wrote: > Take the v6, v7, 32v etc Unix Kernel and related software and run Claude > (or some other AI) on the code to see what it says about potential security > or software bugs exist. > > I’m sure it would have interesting results. > > David It has been said several times anecdotally that the kernel (as of V6?) had no known bugs during various analyses. The "On Security" paper demonstrates some clever manipulations of the provided system features to escalate privileges and deny service, but they are not presented as "bugs" so much as malicious-but-legitimate uses of the system. Granted I've never seen such a "no bugs" assertion about userland, so there could be stuff there that would compromise internal state of a given process. That might be an interesting criterion to consider though, whether a security problem is an implementation bug or an up-to-that-point legitimate use-case that was just ripe for abuse (such as inode/proc exhaustion or abuse of SUID). - Matt G. From tuhs at tuhs.org Wed Jul 22 20:03:21 2026 From: tuhs at tuhs.org (Aharon Robbins via TUHS) Date: Wed, 22 Jul 2026 13:03:21 +0300 Subject: [TUHS] 3B1 games, anyone? Message-ID: Hi All. I found sources for a bunch of 3B1 games. Is there a formal place to archive them? Or, Warren et. al., do you want them for the TUHS archive? Thanks, Arnold $ ls -l total 224 -rw-r--r-- 1 arnold arnold 8797 Jul 10 1992 bugs.tar.gz -rw-r--r-- 1 arnold arnold 2936 Jul 10 1992 chaos.tar.gz -rw-r--r-- 1 arnold arnold 8203 Jul 10 1992 crabs.tar.gz -rw-r--r-- 1 arnold arnold 24534 Jul 10 1992 klondike.tar.gz -rw-r--r-- 1 arnold arnold 10274 Jul 10 1992 life.tar.gz -rw-r--r-- 1 arnold arnold 16969 Jul 10 1992 mahjongg.tar.gz -rw-r--r-- 1 arnold arnold 44226 Jul 10 1992 mandel.tar.gz -rw-r--r-- 1 arnold arnold 11982 Jul 10 1992 mines.tar.gz -rw-r--r-- 1 arnold arnold 7034 Jul 10 1992 moire.tar.gz -rw-r--r-- 1 arnold arnold 8936 Jul 10 1992 rocks.tar.gz -rw-r--r-- 1 arnold arnold 4109 Jul 10 1992 shoot.tar.gz -rw-r--r-- 1 arnold arnold 7649 Jul 10 1992 ski.tar.gz -rw-r--r-- 1 arnold arnold 18440 Jan 23 1991 tetris.tar.gz -rw-r--r-- 1 arnold arnold 8365 Jul 10 1992 tetrix.tar.gz -rw------- 1 arnold arnold 15584 May 15 1991 torus.shar.gz From tuhs at tuhs.org Wed Jul 22 20:06:49 2026 From: tuhs at tuhs.org (Marco Moock via TUHS) Date: Wed, 22 Jul 2026 12:06:49 +0200 Subject: [TUHS] 3B1 games, anyone? In-Reply-To: References: Message-ID: <1d0d6f3f-8e8b-4126-b3ff-7b2770df9bf3@dorfdsl.de> Am 22.07.26 um 12:03 schrieb Aharon Robbins via TUHS: > -rw-r--r-- 1 arnold arnold 8797 Jul 10 1992 bugs.tar.gz > -rw-r--r-- 1 arnold arnold 2936 Jul 10 1992 chaos.tar.gz > -rw-r--r-- 1 arnold arnold 8203 Jul 10 1992 crabs.tar.gz > -rw-r--r-- 1 arnold arnold 24534 Jul 10 1992 klondike.tar.gz > -rw-r--r-- 1 arnold arnold 10274 Jul 10 1992 life.tar.gz > -rw-r--r-- 1 arnold arnold 16969 Jul 10 1992 mahjongg.tar.gz > -rw-r--r-- 1 arnold arnold 44226 Jul 10 1992 mandel.tar.gz > -rw-r--r-- 1 arnold arnold 11982 Jul 10 1992 mines.tar.gz > -rw-r--r-- 1 arnold arnold 7034 Jul 10 1992 moire.tar.gz > -rw-r--r-- 1 arnold arnold 8936 Jul 10 1992 rocks.tar.gz > -rw-r--r-- 1 arnold arnold 4109 Jul 10 1992 shoot.tar.gz > -rw-r--r-- 1 arnold arnold 7649 Jul 10 1992 ski.tar.gz > -rw-r--r-- 1 arnold arnold 18440 Jan 23 1991 tetris.tar.gz > -rw-r--r-- 1 arnold arnold 8365 Jul 10 1992 tetrix.tar.gz > -rw------- 1 arnold arnold 15584 May 15 1991 torus.shar.gz Is there more info about them? Were they X11 or TUI games? -- Gruß Marco Muell und Spam bitte an abfalleimer2002 at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Wed Jul 22 20:56:56 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 22 Jul 2026 04:56:56 -0600 Subject: [TUHS] 3B1 games, anyone? In-Reply-To: <1d0d6f3f-8e8b-4126-b3ff-7b2770df9bf3@dorfdsl.de> References: <1d0d6f3f-8e8b-4126-b3ff-7b2770df9bf3@dorfdsl.de> Message-ID: <202607221056.66MAuuE6008335@freefriends.org> Marco Moock via TUHS wrote: > Am 22.07.26 um 12:03 schrieb Aharon Robbins via TUHS: > > > -rw-r--r-- 1 arnold arnold 8797 Jul 10 1992 bugs.tar.gz > > -rw-r--r-- 1 arnold arnold 2936 Jul 10 1992 chaos.tar.gz > > -rw-r--r-- 1 arnold arnold 8203 Jul 10 1992 crabs.tar.gz > > -rw-r--r-- 1 arnold arnold 24534 Jul 10 1992 klondike.tar.gz > > -rw-r--r-- 1 arnold arnold 10274 Jul 10 1992 life.tar.gz > > -rw-r--r-- 1 arnold arnold 16969 Jul 10 1992 mahjongg.tar.gz > > -rw-r--r-- 1 arnold arnold 44226 Jul 10 1992 mandel.tar.gz > > -rw-r--r-- 1 arnold arnold 11982 Jul 10 1992 mines.tar.gz > > -rw-r--r-- 1 arnold arnold 7034 Jul 10 1992 moire.tar.gz > > -rw-r--r-- 1 arnold arnold 8936 Jul 10 1992 rocks.tar.gz > > -rw-r--r-- 1 arnold arnold 4109 Jul 10 1992 shoot.tar.gz > > -rw-r--r-- 1 arnold arnold 7649 Jul 10 1992 ski.tar.gz > > -rw-r--r-- 1 arnold arnold 18440 Jan 23 1991 tetris.tar.gz > > -rw-r--r-- 1 arnold arnold 8365 Jul 10 1992 tetrix.tar.gz > > -rw------- 1 arnold arnold 15584 May 15 1991 torus.shar.gz > > Is there more info about them? > > Were they X11 or TUI games? They would have used the 3B1's native graphics, I expect. Neither X11 nor curses. Arnold From tuhs at tuhs.org Thu Jul 23 05:20:12 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Wed, 22 Jul 2026 14:20:12 -0500 Subject: [TUHS] 1bsd compatible ar utility Message-ID: Hi All, I am working through a 1BSD installation on Research Unix V6. The||cont.a archives use magic |0177545|, which stock V6 ar does not understand. V7 appears to be able to, but on V6 it immediately dies with |Bad system call|. Inspection shows references to later calls including |access|and |ioctl|, so it appears to have been linked against a post-V6 libc. I came across some old emails talking about this and an nar utility... Does anyone know where the source for this |nar|utility lives, or of a V6-native |ar|that supports |0177545|archives? newoldar on the host works fine, too, but I'd rather not extract on the host. I'm hoping to do this native. I'm working with a pristine v6 installed from tape on pdp 11/70 with split I/D and FPP (opensimh). 1BSD doesn't include an ar utility in the tarball on TUHS. Did folks not do this from pure v6? or what? Thanks, Will From tuhs at tuhs.org Thu Jul 23 05:56:39 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 22 Jul 2026 19:56:39 +0000 Subject: [TUHS] 1bsd compatible ar utility In-Reply-To: References: Message-ID: On Wednesday, July 22nd, 2026 at 12:20, Will Senn via TUHS wrote: > Hi All, > > I am working through a 1BSD installation on Research Unix V6. > The||cont.a archives use magic |0177545|, which stock V6 ar does not > understand. V7 appears to be able to, but on V6 it immediately dies with > |Bad system call|. Inspection shows references to later calls including > |access|and |ioctl|, so it appears to have been linked against a post-V6 > libc. I came across some old emails talking about this and an nar > utility... Does anyone know where the source for this |nar|utility > lives, or of a V6-native |ar|that supports |0177545|archives? > > newoldar on the host works fine, too, but I'd rather not extract on the > host. I'm hoping to do this native. I'm working with a pristine v6 > installed from tape on pdp 11/70 with split I/D and FPP (opensimh). > > 1BSD doesn't include an ar utility in the tarball on TUHS. Did folks not > do this from pure v6? or what? > > Thanks, > > Will > Both USG PG3 and PWB1 have copies of ar(I) featuring the NARMAG value of 0177545, they may prove useful. https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd1/ar.c https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s1/ar.c - Matt G. From tuhs at tuhs.org Thu Jul 23 06:34:05 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Wed, 22 Jul 2026 15:34:05 -0500 Subject: [TUHS] 1bsd compatible ar utility In-Reply-To: References: Message-ID: <03eff3f9-a88c-4d0c-9720-8721bbb00555@gmail.com> On 7/22/26 2:56 PM, segaloco via TUHS wrote: > On Wednesday, July 22nd, 2026 at 12:20, Will Senn via TUHS wrote: > >> Hi All, >> >> I am working through a 1BSD installation on Research Unix V6. >> The||cont.a archives use magic |0177545|, which stock V6 ar does not >> understand. V7 appears to be able to, but on V6 it immediately dies with >> |Bad system call|. Inspection shows references to later calls including >> |access|and |ioctl|, so it appears to have been linked against a post-V6 >> libc. I came across some old emails talking about this and an nar >> utility... Does anyone know where the source for this |nar|utility >> lives, or of a V6-native |ar|that supports |0177545|archives? >> >> newoldar on the host works fine, too, but I'd rather not extract on the >> host. I'm hoping to do this native. I'm working with a pristine v6 >> installed from tape on pdp 11/70 with split I/D and FPP (opensimh). >> >> 1BSD doesn't include an ar utility in the tarball on TUHS. Did folks not >> do this from pure v6? or what? >> >> Thanks, >> >> Will >> > Both USG PG3 and PWB1 have copies of ar(I) featuring the NARMAG value of 0177545, they may prove useful. > > https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd1/ar.c > https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s1/ar.c > > - Matt G. Thanks, Matt, I pulled the PWB1 |ar.c|, made a few small changes for stock V6 compatibility (just enough for t and x support), and compiled it natively under V6. The resulting binary successfully lists and extracts the |0177545|1BSD archives. So the archive problem is "solved". Much appreciated. Will From tuhs at tuhs.org Thu Jul 23 09:17:36 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Wed, 22 Jul 2026 18:17:36 -0500 Subject: [TUHS] 1bsd compatible ar utility In-Reply-To: <03eff3f9-a88c-4d0c-9720-8721bbb00555@gmail.com> References: <03eff3f9-a88c-4d0c-9720-8721bbb00555@gmail.com> Message-ID: On 7/22/26 3:34 PM, Will Senn wrote: > > On 7/22/26 2:56 PM, segaloco via TUHS wrote: >> On Wednesday, July 22nd, 2026 at 12:20, Will Senn via TUHS wrote: >> >>> Hi All, >>> >>> I am working through a 1BSD installation on Research Unix V6. >>> The||cont.a archives use magic |0177545|, which stock V6 ar does not >>> understand. V7 appears to be able to, but on V6 it immediately dies with >>> |Bad system call|. Inspection shows references to later calls including >>> |access|and |ioctl|, so it appears to have been linked against a post-V6 >>> libc. I came across some old emails talking about this and an nar >>> utility... Does anyone know where the source for this |nar|utility >>> lives, or of a V6-native |ar|that supports |0177545|archives? >>> >>> newoldar on the host works fine, too, but I'd rather not extract on the >>> host. I'm hoping to do this native. I'm working with a pristine v6 >>> installed from tape on pdp 11/70 with split I/D and FPP (opensimh). >>> >>> 1BSD doesn't include an ar utility in the tarball on TUHS. Did folks not >>> do this from pure v6? or what? >>> >>> Thanks, >>> >>> Will >>> >> Both USG PG3 and PWB1 have copies of ar(I) featuring the NARMAG value of 0177545, they may prove useful. >> >> https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd1/ar.c >> https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s1/ar.c >> >> - Matt G. > > Thanks, Matt, > > I pulled the PWB1 |ar.c|, made a few small changes for stock V6 > compatibility (just enough for t and x support), and compiled it > natively under V6. The resulting binary successfully lists and > extracts the |0177545|1BSD archives. > > So the archive problem is "solved". Much appreciated. > > Will > The archive problem got solved, but I don't think 1bsd is truly meant for a pristine v6 from tape. ex, apparently requires a v7 cc, and ashell core dumps on syscalls that don't exist in v6: ./ashell Bad system call -- Core dumped READ_ME (for ashell): cat READ_ME Wed Oct 19, 1977 This directory contains the source for a shell. It requires floating point to do the time command which is built-in so you will have to cc it -f on machines without floating point. It also requires a version 7 C compiler. Accurate documentation is in the file "sh.6" to be nroffed with /usr/man/man0/naa and a new "version 7" nroff. This shell requires the "htmp" data base also used by the editor "ex". If you do not set it up so that the "sethome" command is done by "login" then you should use the old "osethome" routine in ../s6 rather than "sethome" and reenable the execl of this sethome in the file "sh.c" (with the correct pathname).                                 Bill Joy                                 CS Division                                 Department of EE and CS                                 UC Berkeley                                 Berkeley, California  94704                                 (415) 524-4510          [HOME]                                 (415) 642-4948          [SCHOOL] Some of the utilities work fine: # ./version char    version[] "October 10, 1975"; # ./version | ./wc       1       5      35 but as I'm really just trying (again, but with more knowledge than before and an AI assist to boot) to recreate the experience of doing this the hard way, I want to get ashell working, pascal, ex, trek, etc. Any hints or tips on getting the correct starting evirons set up appreciated. Will From tuhs at tuhs.org Thu Jul 23 11:16:11 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 22 Jul 2026 21:16:11 -0400 Subject: [TUHS] 1bsd compatible ar utility In-Reply-To: References: <03eff3f9-a88c-4d0c-9720-8721bbb00555@gmail.com> Message-ID: Will, The issue is you are skipping a few steps as it turns out. BSD (a.k.a. What we call 1BSD) probably cannt be installed on virgin V6 distribution. By the time it was released there were two important V6 updates in the wild that most likely of us (like Joy at UCB did) had already installed. The most important is the 50 fixes from Ken. That is likely to get the kernel itself closer to what Bill was running (remember Jen had already done is sabbatical at UCB so all of those were there). The second is the first USENIX tape, often called the Harvard tape. That will have a number of utilities such as the updated ar and two new versions of tp (the C rewrite from assembled and super tp - stp - which already started to become the standard as it had some more graceful error support such as a second copy of it directory at the end of tape). Note to use tp (or v6tar which Bill gives you a binary) you’ll need an updated tape driver. All of that in on the Harvard tape - but I’ve forgotten exactly where. The other issue is the compiler. Dennis has updated C and released his replacement for Lesk’s portable C library with his new I/O library libS.a. This compiler was bundled with the troff kit, as is often referred to as “Typesetter C.” It is also compiler Dennis and Brian are discussing in K&R1. Sadly we can’t seem to find a copy of that distribution but we have mostly reconstructed much of it from other systems. That compiler plus some other additions, ended up in V7 and libS.a was folded into libc.a. We had that compiler at CMU by 1976/77 timeframe, and I’m fairly sure UCB had it also. As I said it’s the compiler from K&R1 and a lot of sites (I would suspect that most of the core USENIX sites outside of the Bell System were using it, so Bill expecting it he there was really not surprising. Talk to me offline and I can try help you with much of your stumbles. I have gotten much of the original BSD tape to work. FWIW Noel Chiappa’s MIT V6++ system is probably the most comfortable V6 I’ve seen, as it has most things you might expect. It has pretty much all the major upgrades the we all tried to add to our V6 system. Im not 100% sure, but I would be surprised if he don’t have Dennis compiler. If might also want to you look at https://www.tuhs.org/Archive/Distributions/Research/Tim_Shoppa_v6/README Tim Shoppa V6 system from UBC is also fairly complete. Clem Sent from a handheld expect more typos than usual On Wed, Jul 22, 2026 at 7:17 PM Will Senn via TUHS wrote: > > On 7/22/26 3:34 PM, Will Senn wrote: > > > > On 7/22/26 2:56 PM, segaloco via TUHS wrote: > >> On Wednesday, July 22nd, 2026 at 12:20, Will Senn via TUHS< > tuhs at tuhs.org> wrote: > >> > >>> Hi All, > >>> > >>> I am working through a 1BSD installation on Research Unix V6. > >>> The||cont.a archives use magic |0177545|, which stock V6 ar does not > >>> understand. V7 appears to be able to, but on V6 it immediately dies > with > >>> |Bad system call|. Inspection shows references to later calls including > >>> |access|and |ioctl|, so it appears to have been linked against a > post-V6 > >>> libc. I came across some old emails talking about this and an nar > >>> utility... Does anyone know where the source for this |nar|utility > >>> lives, or of a V6-native |ar|that supports |0177545|archives? > >>> > >>> newoldar on the host works fine, too, but I'd rather not extract on the > >>> host. I'm hoping to do this native. I'm working with a pristine v6 > >>> installed from tape on pdp 11/70 with split I/D and FPP (opensimh). > >>> > >>> 1BSD doesn't include an ar utility in the tarball on TUHS. Did folks > not > >>> do this from pure v6? or what? > >>> > >>> Thanks, > >>> > >>> Will > >>> > >> Both USG PG3 and PWB1 have copies of ar(I) featuring the NARMAG value > of 0177545, they may prove useful. > >> > >> https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd1/ar.c > >> https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s1/ar.c > >> > >> - Matt G. > > > > Thanks, Matt, > > > > I pulled the PWB1 |ar.c|, made a few small changes for stock V6 > > compatibility (just enough for t and x support), and compiled it > > natively under V6. The resulting binary successfully lists and > > extracts the |0177545|1BSD archives. > > > > So the archive problem is "solved". Much appreciated. > > > > Will > > > > The archive problem got solved, but I don't think 1bsd is truly meant > for a pristine v6 from tape. ex, apparently requires a v7 cc, and ashell > core dumps on syscalls that don't exist in v6: > ./ashell > Bad system call -- Core dumped > > READ_ME (for ashell): > > cat READ_ME > Wed Oct 19, 1977 > > This directory contains the source for a shell. > It requires floating point to do the time command which is built-in > so you will have to cc it -f on machines without floating point. > It also requires a version 7 C compiler. > > Accurate documentation is in the file "sh.6" to be nroffed with > /usr/man/man0/naa and a new "version 7" nroff. > > This shell requires the "htmp" data base also used by the editor "ex". > If you do not set it up so that the "sethome" command is done by "login" > then you should use the old "osethome" routine in ../s6 rather than > "sethome" > and reenable the execl of this sethome in the file "sh.c" (with the correct > pathname). > > Bill Joy > CS Division > Department of EE and CS > UC Berkeley > Berkeley, California 94704 > > (415) 524-4510 [HOME] > (415) 642-4948 [SCHOOL] > > Some of the utilities work fine: > > # ./version > char version[] "October 10, 1975"; > # ./version | ./wc > 1 5 35 > > but as I'm really just trying (again, but with more knowledge than > before and an AI assist to boot) to recreate the experience of doing > this the hard way, I want to get ashell working, pascal, ex, trek, etc. > Any hints or tips on getting the correct starting evirons set up > appreciated. > > Will > From tuhs at tuhs.org Thu Jul 23 13:05:19 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Wed, 22 Jul 2026 22:05:19 -0500 Subject: [TUHS] 1bsd compatible ar utility In-Reply-To: References: <03eff3f9-a88c-4d0c-9720-8721bbb00555@gmail.com> Message-ID: <15cf001d-fb26-4478-8223-2692338fd8df@gmail.com> Clem, That sure explains a lot of the pain. I shoulda known better than to think it'd be straightforward :).... V6->50 fixes->Harvard tape->typsetter C->BSD1->... BSD2? Where does V7 fit - post BSD2? Wow. On paper it all sounded reasonable, unfortunately the paper's a little thin. I'm going to try 50 fixes as my next V6 project. Thanks, Will On 7/22/26 8:16 PM, Clem Cole wrote: > Will, > > The issue is you are skipping a few steps as it turns out.  BSD > (a.k.a. What we call 1BSD) probably cannt be installed on virgin V6 > distribution.  By the time it was released there were two important V6 > updates in the wild that most likely of us (like Joy at UCB did) had > already installed.  The most important is the 50 fixes from Ken.  That > is likely to get the kernel itself closer to what Bill was running > (remember Jen had already done is sabbatical at UCB so all of those > were there).   The second is the first USENIX tape, often called the > Harvard tape.  That will have a number of utilities such as the > updated ar and two new versions of tp (the C rewrite from assembled > and super tp - stp - which already started to become the standard as > it had some more graceful error support such as a second copy of it > directory at the end of tape).  Note to use tp (or v6tar which Bill > gives you a binary) you’ll need an updated tape driver. All of that in > on the Harvard tape - but I’ve forgotten exactly where. > > The other issue is the compiler.  Dennis has updated C and released > his replacement for Lesk’s portable C library with his new I/O library > libS.a.  This compiler was bundled with the troff kit, as is often > referred to as “Typesetter C.”  It is also compiler Dennis and Brian > are discussing in K&R1.  Sadly we can’t seem to find a copy of that > distribution but we have mostly reconstructed much of it from other > systems. > > That compiler plus some other additions, ended up in V7 and libS.a was > folded into libc.a. > > We had that compiler at CMU by 1976/77 timeframe, and I’m fairly sure > UCB had it also.  As I said it’s the compiler from K&R1 and a lot of > sites (I would suspect that most of the core USENIX sites outside of > the Bell System were using it, so Bill expecting it he there was > really not surprising. > > > Talk to me offline and I can try help you with much of your stumbles. > I have gotten much of the original BSD tape to work.   FWIW Noel > Chiappa’s MIT V6++ system is probably the most comfortable V6 I’ve > seen,  as it has most things you might expect.    It has pretty much > all the major upgrades the we all tried to add to our V6 system. Im > not 100% sure, but I would be surprised if he don’t have Dennis > compiler.  If might also want to you look at > https://www.tuhs.org/Archive/Distributions/Research/Tim_Shoppa_v6/README Tim > Shoppa V6 system from UBC is also fairly complete. > > Clem > > > Sent from a handheld expect more typos than usual > > On Wed, Jul 22, 2026 at 7:17 PM Will Senn via TUHS wrote: > > > On 7/22/26 3:34 PM, Will Senn wrote: > > > > On 7/22/26 2:56 PM, segaloco via TUHS wrote: > >> On Wednesday, July 22nd, 2026 at 12:20, Will Senn via > TUHS wrote: > >> > >>> Hi All, > >>> > >>> I am working through a 1BSD installation on Research Unix V6. > >>> The||cont.a archives use magic |0177545|, which stock V6 ar > does not > >>> understand. V7 appears to be able to, but on V6 it immediately > dies with > >>> |Bad system call|. Inspection shows references to later calls > including > >>> |access|and |ioctl|, so it appears to have been linked against > a post-V6 > >>> libc. I came across some old emails talking about this and an nar > >>> utility... Does anyone know where the source for this |nar|utility > >>> lives, or of a V6-native |ar|that supports |0177545|archives? > >>> > >>> newoldar on the host works fine, too, but I'd rather not > extract on the > >>> host. I'm hoping to do this native. I'm working with a pristine v6 > >>> installed from tape on pdp 11/70 with split I/D and FPP > (opensimh). > >>> > >>> 1BSD doesn't include an ar utility in the tarball on TUHS. Did > folks not > >>> do this from pure v6? or what? > >>> > >>> Thanks, > >>> > >>> Will > >>> > >> Both USG PG3 and PWB1 have copies of ar(I) featuring the NARMAG > value of 0177545, they may prove useful. > >> > >> > https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd1/ar.c > >> https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s1/ar.c > >> > >> - Matt G. > > > > Thanks, Matt, > > > > I pulled the PWB1 |ar.c|, made a few small changes for stock V6 > > compatibility (just enough for t and x support), and compiled it > > natively under V6. The resulting binary successfully lists and > > extracts the |0177545|1BSD archives. > > > > So the archive problem is "solved". Much appreciated. > > > > Will > > > > The archive problem got solved, but I don't think 1bsd is truly meant > for a pristine v6 from tape. ex, apparently requires a v7 cc, and > ashell > core dumps on syscalls that don't exist in v6: > ./ashell > Bad system call -- Core dumped > > READ_ME (for ashell): > > cat READ_ME > Wed Oct 19, 1977 > > This directory contains the source for a shell. > It requires floating point to do the time command which is built-in > so you will have to cc it -f on machines without floating point. > It also requires a version 7 C compiler. > > Accurate documentation is in the file "sh.6" to be nroffed with > /usr/man/man0/naa and a new "version 7" nroff. > > This shell requires the "htmp" data base also used by the editor "ex". > If you do not set it up so that the "sethome" command is done by > "login" > then you should use the old "osethome" routine in ../s6 rather than > "sethome" > and reenable the execl of this sethome in the file "sh.c" (with > the correct > pathname). > >                                  Bill Joy >                                  CS Division >                                  Department of EE and CS >                                  UC Berkeley >                                  Berkeley, California 94704 > >                                  (415) 524-4510 [HOME] >                                  (415) 642-4948 [SCHOOL] > > Some of the utilities work fine: > > # ./version > char    version[] "October 10, 1975"; > # ./version | ./wc >        1       5      35 > > but as I'm really just trying (again, but with more knowledge than > before and an AI assist to boot) to recreate the experience of doing > this the hard way, I want to get ashell working, pascal, ex, trek, > etc. > Any hints or tips on getting the correct starting evirons set up > appreciated. > > Will > From tuhs at tuhs.org Thu Jul 23 14:00:29 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 23 Jul 2026 00:00:29 -0400 Subject: [TUHS] 1bsd compatible ar utility In-Reply-To: <15cf001d-fb26-4478-8223-2692338fd8df@gmail.com> References: <03eff3f9-a88c-4d0c-9720-8721bbb00555@gmail.com> <15cf001d-fb26-4478-8223-2692338fd8df@gmail.com> Message-ID: 2BSD was released during the V7 transition - in fact V7 was just coming up on the Cory Hall 11/70 (which was the home system for Bill before Ernie). If you look at many of the user space code on the 2BSD tape, such as Pascal and cshell to take two, they are not using Dennis standard I/O nor many of the new features of the updated C compiler. In fact, Pascal is especially dirty (I’ve never tried but I wouldn’t be surprised is the Pascal on the 1BSD tape can build on Fifth Edition). By the time of the 2BSD tape, UCB had not fully transitioned to V7 across the campus. I suspect this was a large part of why Bill tried to make it all work on V6 as well as V7. His one concession to V7 was using Ken’s replacement for tp, tar to write the tape since it didn’t gave a fixed size directory like tp. But as a acknowledgement to V6 users, if you look he puts a binary of the a V7m tar on the front of the tape that was linked so it would work in Sixth Edition to read the tape (a.k.a. v6tar). But to do that he does assume the updated magnetic tape drivers work on your V6 system - which by that point was very wide spread, since they improved the functionality from Dennis’s original version - fully supporting the idea of “files” on the tape with proper file marks and dual file marks for EOT as was standard throughout the rest of the computer industry (there is an ASA spec - X3.4 and X3.22 if I remember correctly defined the physical recording and the original Unix research tape drivers didn’t fully follow it. As I said the Harvard tape has the updated versions, which Dennis took back in V7). Note this should not be confused with the much later ANSI X3.27 logical format that was the basis for many DEC tape formats, which you can think of as analogous to tar. But under covers a program that writes/reads a X3.27 logical format tape needs/assumes that the driver and tape transport supports the physical formatting scheme which ASA had defined years earlier. Sent from a handheld expect more typos than usual On Wed, Jul 22, 2026 at 11:05 PM Will Senn wrote: > Clem, > > That sure explains a lot of the pain. I shoulda known better than to think > it'd be straightforward :).... > > V6->50 fixes->Harvard tape->typsetter C->BSD1->... BSD2? > > Where does V7 fit - post BSD2? > > Wow. On paper it all sounded reasonable, unfortunately the paper's a > little thin. I'm going to try 50 fixes as my next V6 project. > > Thanks, > > Will > On 7/22/26 8:16 PM, Clem Cole wrote: > > Will, > > The issue is you are skipping a few steps as it turns out. BSD (a.k.a. > What we call 1BSD) probably cannt be installed on virgin V6 distribution. > By the time it was released there were two important V6 updates in the wild > that most likely of us (like Joy at UCB did) had already installed. The > most important is the 50 fixes from Ken. That is likely to get the > kernel itself closer to what Bill was running (remember Jen had already > done is sabbatical at UCB so all of those were there). The second is the > first USENIX tape, often called the Harvard tape. That will have a number > of utilities such as the updated ar and two new versions of tp (the C > rewrite from assembled and super tp - stp - which already started to become > the standard as it had some more graceful error support such as a second > copy of it directory at the end of tape). Note to use tp (or v6tar which > Bill gives you a binary) you’ll need an updated tape driver. All of that > in on the Harvard tape - but I’ve forgotten exactly where. > > The other issue is the compiler. Dennis has updated C and released his > replacement for Lesk’s portable C library with his new I/O library libS.a. > This compiler was bundled with the troff kit, as is often referred to as > “Typesetter C.” It is also compiler Dennis and Brian are discussing in > K&R1. Sadly we can’t seem to find a copy of that distribution but we have > mostly reconstructed much of it from other systems. > > That compiler plus some other additions, ended up in V7 and libS.a was > folded into libc.a. > > We had that compiler at CMU by 1976/77 timeframe, and I’m fairly sure UCB > had it also. As I said it’s the compiler from K&R1 and a lot of sites (I > would suspect that most of the core USENIX sites outside of the Bell > System were using it, so Bill expecting it he there was really not > surprising. > > > Talk to me offline and I can try help you with much of your stumbles. I > have gotten much of the original BSD tape to work. FWIW Noel Chiappa’s > MIT V6++ system is probably the most comfortable V6 I’ve seen, as it has > most things you might expect. It has pretty much all the major upgrades > the we all tried to add to our V6 system. Im not 100% sure, but I would be > surprised if he don’t have Dennis compiler. If might also want to you look > at > https://www.tuhs.org/Archive/Distributions/Research/Tim_Shoppa_v6/README Tim > Shoppa V6 system from UBC is also fairly complete. > > Clem > > > Sent from a handheld expect more typos than usual > > On Wed, Jul 22, 2026 at 7:17 PM Will Senn via TUHS wrote: > >> >> On 7/22/26 3:34 PM, Will Senn wrote: >> > >> > On 7/22/26 2:56 PM, segaloco via TUHS wrote: >> >> On Wednesday, July 22nd, 2026 at 12:20, Will Senn via TUHS< >> tuhs at tuhs.org> wrote: >> >> >> >>> Hi All, >> >>> >> >>> I am working through a 1BSD installation on Research Unix V6. >> >>> The||cont.a archives use magic |0177545|, which stock V6 ar does not >> >>> understand. V7 appears to be able to, but on V6 it immediately dies >> with >> >>> |Bad system call|. Inspection shows references to later calls >> including >> >>> |access|and |ioctl|, so it appears to have been linked against a >> post-V6 >> >>> libc. I came across some old emails talking about this and an nar >> >>> utility... Does anyone know where the source for this |nar|utility >> >>> lives, or of a V6-native |ar|that supports |0177545|archives? >> >>> >> >>> newoldar on the host works fine, too, but I'd rather not extract on >> the >> >>> host. I'm hoping to do this native. I'm working with a pristine v6 >> >>> installed from tape on pdp 11/70 with split I/D and FPP (opensimh). >> >>> >> >>> 1BSD doesn't include an ar utility in the tarball on TUHS. Did folks >> not >> >>> do this from pure v6? or what? >> >>> >> >>> Thanks, >> >>> >> >>> Will >> >>> >> >> Both USG PG3 and PWB1 have copies of ar(I) featuring the NARMAG value >> of 0177545, they may prove useful. >> >> >> >> >> https://www.tuhs.org/cgi-bin/utree.pl?file=USG_PG3/usr/source/cmd1/ar.c >> >> https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s1/ar.c >> >> >> >> - Matt G. >> > >> > Thanks, Matt, >> > >> > I pulled the PWB1 |ar.c|, made a few small changes for stock V6 >> > compatibility (just enough for t and x support), and compiled it >> > natively under V6. The resulting binary successfully lists and >> > extracts the |0177545|1BSD archives. >> > >> > So the archive problem is "solved". Much appreciated. >> > >> > Will >> > >> >> The archive problem got solved, but I don't think 1bsd is truly meant >> for a pristine v6 from tape. ex, apparently requires a v7 cc, and ashell >> core dumps on syscalls that don't exist in v6: >> ./ashell >> Bad system call -- Core dumped >> >> READ_ME (for ashell): >> >> cat READ_ME >> Wed Oct 19, 1977 >> >> This directory contains the source for a shell. >> It requires floating point to do the time command which is built-in >> so you will have to cc it -f on machines without floating point. >> It also requires a version 7 C compiler. >> >> Accurate documentation is in the file "sh.6" to be nroffed with >> /usr/man/man0/naa and a new "version 7" nroff. >> >> This shell requires the "htmp" data base also used by the editor "ex". >> If you do not set it up so that the "sethome" command is done by "login" >> then you should use the old "osethome" routine in ../s6 rather than >> "sethome" >> and reenable the execl of this sethome in the file "sh.c" (with the >> correct >> pathname). >> >> Bill Joy >> CS Division >> Department of EE and CS >> UC Berkeley >> Berkeley, California 94704 >> >> (415) 524-4510 [HOME] >> (415) 642-4948 [SCHOOL] >> >> Some of the utilities work fine: >> >> # ./version >> char version[] "October 10, 1975"; >> # ./version | ./wc >> 1 5 35 >> >> but as I'm really just trying (again, but with more knowledge than >> before and an AI assist to boot) to recreate the experience of doing >> this the hard way, I want to get ashell working, pascal, ex, trek, etc. >> Any hints or tips on getting the correct starting evirons set up >> appreciated. >> >> Will >> > From tuhs at tuhs.org Thu Jul 23 15:45:14 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 23 Jul 2026 15:45:14 +1000 Subject: [TUHS] Fwd: A request to the TUHS mailing list about an IEEE Milestone for UNIX Level Six Source Code and Commentary In-Reply-To: References: Message-ID: <2097114e-e9ee-4d8e-bda5-a3cb8ad6f7e5@tuhs.org> All, I've just received this e-mail from Paul Leopardi. It's detailed but please read it all if you can. I think TUHS should definitely get behind this nomination for an IEEE Milestone. Rather than flood the TUHS list and/or Paul with details, can you look at this repository: https://github.com/DoctorWkt/IEEE_Milestone_Lions_Commentary edit the Readme.md and/or add new documents, and issue pull requests. Thanks, Warren -------- Forwarded Message -------- Subject: A request to the TUHS mailing list about an IEEE Milestone for UNIX Level Six Source Code and Commentary Date: Thu, 23 Jul 2026 02:28:54 +0000 From: Paul Leopardi To: wkt at tuhs.org CC: Paul Leopardi , Ambarish S Natu Hello Warren, I'm Paul Leopardi, a former student of John Lions and currently the Life Member Affinity Group coordinator of the IEEE ACT Section. I have been in contact with Gernot Heiser at UNSW and with the IEEE ACTand NSW Sections as well as IEEE Australia Council about preparations for an application for an IEEE Milestone for the two John Lions books published by UNSW in 1977, both the UNIX Source Code Level Six and the Commentary. The milestone would be "UNIX Level Six Source Code and Commentary" The milestone ceremony would likely coincide with the John Lions Distinguished Lecture in 2027, and the plaque would be likely to be in the John Lions Garden. See https://ethw.org/Milestones:IEEE_Milestones_Program and https://ieeemilestones.ethw.org/Milestone_Guidelines_and_How_to_Propose_a_Milestone As part of my researtch for the IEEE Milestone application, with the help of AI agents, I put together a brief history of the Lions books, including their inception and impact. You can see this at https://sites.google.com/site/paulleopardi/essays The history is probably overly detailed, but to qualify for an IEEE Milestone, an event must be a key historical achivement. To date there is no IEEE Milestone for UNIX and very few for software, let alone operating systems. An example of a milestone for an operating system is https://ethw.org/Milestones:The_CP/M_Microcomputer_Operating_System,_1974 The IEEE Milestone evidence bar is quite high, instead of citations, it requires the full text of cited references. To this end I would like to post the following to the TUHS mailing list, most likely after paraphasing: ---ooo0ooo--- Seeking TUHS archival assistance & primary evidence: IEEE Milestone nomination for John Lions’ UNIX V6 Commentary Hi everyone, In consultation with Ambarish Natu (IEEE ACT Section), I am currently working to finalize an **IEEE Milestone proposal** to formally recognize John Lions’ 1977 work at UNSW — *A Commentary on the Sixth Edition UNIX Operating System* — and its foundational role in operating systems education, open systems culture, and global software engineering. To ensure our submission package to the IEEE History Committee is historically watertight and backed by primary evidence, we are seeking specific assistance from the TUHS community: ### Actionable Evidence Requests for TUHS: 1. **UNSW Tape Archive Verification (`UNSW/88` & `UNSW/106`):**    * Has anyone inspected the file trees of the `UNSW/88` or `UNSW/106` distributions in the TUHS archive for early administrative tools (such as `give`, `submit`, or `ausam` modules) to confirm when these utilities first entered the UNSW codebase? 2. **Verification of 1977 Physical Artifacts:**    * We have access to physical copies of the Third Printing of both volumes — *Source Code* (in its original pink cover) and *Commentary* (in its original orange cover), both dated 1977. We would welcome community confirmation that these UNSW Third Printing volumes constitute sufficient primary physical evidence for the 1977 Lions books in the IEEE dossier. 3. **1994–1998 PUPS / SCO / P2P Archival Records:**    * Any surviving correspondence, memos, or Usenet petition logs from the 1994–1996 Salus/Lions/Ritchie Novell-SCO negotiations, or the 1996–1998 Toomey/Schultz/Dion Johnson $100 Ancient UNIX licence campaign, to further enrich our documentation of early UNIX preservation milestones. 4. **Western Electric / AT&T Licensing Memos (1977–1978):**    * Primary copies or scans of 1977–1978 correspondence between Bell Labs / Western Electric and UNSW regarding the prohibition of external commentary distribution, or internal Bell Labs memos referencing Lions' book. 5. **Early International Samizdat Artifacts:**    * Primary documentation or recollections regarding early samizdat distribution timelines at international universities (e.g. early Berkeley CS 162 syllabi, UK/European Unix groups, or Japanese translation initiatives prior to the 1998 ASCII release). 6. **Supporting Statements & Endorsements:**    * Short supporting statements or endorsement letters from Unix pioneers, early AUUG founders, or academics who used the *Commentary* in university courses during the 1970s–1990s to attach to the official IEEE History Committee submission package. The complete 45-source **Narrative History** (1974–2026) and bibliography are published online for review at: **https://sites.google.com/site/paulleopardi/essays** Thank you all for your extraordinary dedication to preserving UNIX history. All the best, Paul Leopardi https://sites.google.com/site/paulleopardi/essays From tuhs at tuhs.org Sat Jul 25 04:23:57 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Fri, 24 Jul 2026 13:23:57 -0500 Subject: [TUHS] =?utf-8?q?Setting_Up_UNIX=E2=80=94Sixth_Edition=3A_An_Ope?= =?utf-8?q?nSIMH_Laboratory_for_Reading_Lions?= Message-ID: <6ec791de-5727-43a3-8f6a-e981608c1d9b@gmail.com> Hi all, I support the proposed IEEE Milestone recognizing John Lions' UNIX Operating System Source Code Level Six and A Commentary on the UNIX Operating System. Few works have had a comparable influence on operating systems education, and it is fitting to see them considered for formal recognition. With that discussion underway, I thought I would mention a companion resource I have just completed. For the past several years, I have been working with V6 under OpenSIMH for a variety of purposes, and I have written up the general installation and customization process before. This is not another of those notes. Setting Up UNIX—Sixth Edition: An OpenSIMH Laboratory for Reading Lions is written in the genre of Thompson and Ritchie's original memo: a procedure, in their register, addressed to someone assembling a specific machine and environment. Its scope is both narrower than theirs and broader. It constructs a modern virtual counterpart to the laboratory in which Lions' students worked. An installation guide ends at a login prompt, but this guide goes further: to a correspondence among the running kernel, the source tree from which it was built, and the listing Lions annotates, all resolvable against one another. The original laboratory required a PDP-11/40, controllers, several RK05 drives, magnetic tape, terminals, a printer, removable media, and the accompanying source and documentation. In the reconstructed laboratory, those components take different forms. OpenSIMH supplies the processor, memory, controllers, and peripheral devices. The distribution tape and removable disk packs are represented by image files, while a modern terminal program provides access to the running system. The cabinets, motors, reels, and 14-inch platters have disappeared, but the interfaces presented to V6 remain those of the original machine. V6 does not know the difference. The guide leads readers who want to study Lions in a working laboratory environment through restoring the original V6 distribution from tape, rebuilding the kernel, installing the complete source and documentation filesystems, creating the required device files, verifying the installation, and producing a restorable baseline archive. The completed laboratory is configured to match the presumed model system described by Lions on page 1-2 of the Commentary. It allows readers to boot the system, examine the installed source, rebuild the kernel, and move directly among the running system, the source deployed from the original distribution tape, and the edited listing published as UNIX Operating System Source Code Level Six. The guide is intended to be used together with my updated and expanded edition of UNIX Operating System Source Code Level Six, which preserves Lions' original sheet numbering while adding file locations, procedure listings, indexes, cross references, and configured-kernel symbol tables keyed to the delivered source code. Together, the two resources make it possible to read Lions not only as a historical text, but against a living V6 system assembled from the original distribution materials. Guide: https://decuser.github.io/posts/setting-up-unix-sixth-edition-opensimh-laboratory-for-reading-lions/ Companion source edition: https://decuser.github.io/posts/updated-lions-v6-source-w-appendices-and-helps-v1.4/ The guide takes me about 15 minutes to work through now, but I expect a careful first reading and installation will take a couple of hours. I would be glad to hear from anyone who takes a look, even if only to let me know you had a chance to read it. Corrections, questions, and suggestions are especially welcome. Regards, Will From tuhs at tuhs.org Sat Jul 25 06:05:45 2026 From: tuhs at tuhs.org (christopher fujino via TUHS) Date: Fri, 24 Jul 2026 13:05:45 -0700 Subject: [TUHS] =?utf-8?q?Setting_Up_UNIX=E2=80=94Sixth_Edition=3A_An_Ope?= =?utf-8?q?nSIMH_Laboratory_for_Reading_Lions?= In-Reply-To: <6ec791de-5727-43a3-8f6a-e981608c1d9b@gmail.com> References: <6ec791de-5727-43a3-8f6a-e981608c1d9b@gmail.com> Message-ID: Oh nice, this is great! I'm definitely a pdp-11/simh n00b, so I think I would be a good guinea pig. I will try this today and share if I have any actionable feedback. Chris On Fri, Jul 24, 2026 at 11:33 AM Will Senn via TUHS wrote: > Hi all, > > I support the proposed IEEE Milestone recognizing John Lions' UNIX > Operating System Source Code Level Six and A Commentary on the UNIX > Operating System. Few works have had a comparable influence on operating > systems education, and it is fitting to see them considered for formal > recognition. > > With that discussion underway, I thought I would mention a companion > resource I have just completed. > > For the past several years, I have been working with V6 under OpenSIMH > for a variety of purposes, and I have written up the general > installation and customization process before. This is not another of > those notes. Setting Up UNIX—Sixth Edition: An OpenSIMH Laboratory for > Reading Lions is written in the genre of Thompson and Ritchie's original > memo: a procedure, in their register, addressed to someone assembling a > specific machine and environment. Its scope is both narrower than theirs > and broader. It constructs a modern virtual counterpart to the > laboratory in which Lions' students worked. An installation guide ends > at a login prompt, but this guide goes further: to a correspondence > among the running kernel, the source tree from which it was built, and > the listing Lions annotates, all resolvable against one another. > > The original laboratory required a PDP-11/40, controllers, several RK05 > drives, magnetic tape, terminals, a printer, removable media, and the > accompanying source and documentation. In the reconstructed laboratory, > those components take different forms. OpenSIMH supplies the processor, > memory, controllers, and peripheral devices. The distribution tape and > removable disk packs are represented by image files, while a modern > terminal program provides access to the running system. The cabinets, > motors, reels, and 14-inch platters have disappeared, but the interfaces > presented to V6 remain those of the original machine. V6 does not know > the difference. > > The guide leads readers who want to study Lions in a working laboratory > environment through restoring the original V6 distribution from tape, > rebuilding the kernel, installing the complete source and documentation > filesystems, creating the required device files, verifying the > installation, and producing a restorable baseline archive. The completed > laboratory is configured to match the presumed model system described by > Lions on page 1-2 of the Commentary. It allows readers to boot the > system, examine the installed source, rebuild the kernel, and move > directly among the running system, the source deployed from the original > distribution tape, and the edited listing published as UNIX Operating > System Source Code Level Six. > > The guide is intended to be used together with my updated and expanded > edition of UNIX Operating System Source Code Level Six, which preserves > Lions' original sheet numbering while adding file locations, procedure > listings, indexes, cross references, and configured-kernel symbol tables > keyed to the delivered source code. Together, the two resources make it > possible to read Lions not only as a historical text, but against a > living V6 system assembled from the original distribution materials. > > Guide: > > https://decuser.github.io/posts/setting-up-unix-sixth-edition-opensimh-laboratory-for-reading-lions/ > > Companion source edition: > > https://decuser.github.io/posts/updated-lions-v6-source-w-appendices-and-helps-v1.4/ > > The guide takes me about 15 minutes to work through now, but I expect a > careful first reading and installation will take a couple of hours. > > I would be glad to hear from anyone who takes a look, even if only to > let me know you had a chance to read it. Corrections, questions, and > suggestions are especially welcome. > > Regards, > Will > From tuhs at tuhs.org Sun Jul 26 15:20:45 2026 From: tuhs at tuhs.org (durtal via TUHS) Date: Sun, 26 Jul 2026 15:20:45 +1000 (AEST) Subject: [TUHS] =?utf-8?q?Setting_Up_UNIX=E2=80=94Sixth_Edition=3A_An_Ope?= =?utf-8?q?nSIMH_Laboratory_for_Reading_Lions?= In-Reply-To: <6ec791de-5727-43a3-8f6a-e981608c1d9b@gmail.com> References: <6ec791de-5727-43a3-8f6a-e981608c1d9b@gmail.com> Message-ID: <58c4f38e-0869-b2f1-928b-950457be887b@sdf.org> Thanks for this update...I found your earlier work very helpful in getting things up and running. I haven't had the time to look at the v7 info. Your Apple II assembly work has been much appreciated as well. However, I'm still trying to get my head around it % ). BTW, nine years ago a Texas boy whisked away our Aussie daughter. They live in Cedar Hill with two of our grandchildren. Rick On Fri, 24 Jul 2026, Will Senn via TUHS wrote: > Date: Fri, 24 Jul 2026 13:23:57 -0500 > From: Will Senn via TUHS > Reply-To: Will Senn > To: "tuhs at tuhs.org" > Subject: [TUHS] Setting Up UNIX?Sixth Edition: An OpenSIMH Laboratory for > Reading Lions > > Hi all, > > I support the proposed IEEE Milestone recognizing John Lions' UNIX Operating > System Source Code Level Six and A Commentary on the UNIX Operating System. > Few works have had a comparable influence on operating systems education, and > it is fitting to see them considered for formal recognition. > > With that discussion underway, I thought I would mention a companion resource > I have just completed. > > For the past several years, I have been working with V6 under OpenSIMH for a > variety of purposes, and I have written up the general installation and > customization process before. This is not another of those notes. Setting Up > UNIX?Sixth Edition: An OpenSIMH Laboratory for Reading Lions is written in > the genre of Thompson and Ritchie's original memo: a procedure, in their > register, addressed to someone assembling a specific machine and environment. > Its scope is both narrower than theirs and broader. It constructs a modern > virtual counterpart to the laboratory in which Lions' students worked. An > installation guide ends at a login prompt, but this guide goes further: to a > correspondence among the running kernel, the source tree from which it was > built, and the listing Lions annotates, all resolvable against one another. > > The original laboratory required a PDP-11/40, controllers, several RK05 > drives, magnetic tape, terminals, a printer, removable media, and the > accompanying source and documentation. In the reconstructed laboratory, those > components take different forms. OpenSIMH supplies the processor, memory, > controllers, and peripheral devices. The distribution tape and removable disk > packs are represented by image files, while a modern terminal program > provides access to the running system. The cabinets, motors, reels, and > 14-inch platters have disappeared, but the interfaces presented to V6 remain > those of the original machine. V6 does not know the difference. > > The guide leads readers who want to study Lions in a working laboratory > environment through restoring the original V6 distribution from tape, > rebuilding the kernel, installing the complete source and documentation > filesystems, creating the required device files, verifying the installation, > and producing a restorable baseline archive. The completed laboratory is > configured to match the presumed model system described by Lions on page 1-2 > of the Commentary. It allows readers to boot the system, examine the > installed source, rebuild the kernel, and move directly among the running > system, the source deployed from the original distribution tape, and the > edited listing published as UNIX Operating System Source Code Level Six. > > The guide is intended to be used together with my updated and expanded > edition of UNIX Operating System Source Code Level Six, which preserves > Lions' original sheet numbering while adding file locations, procedure > listings, indexes, cross references, and configured-kernel symbol tables > keyed to the delivered source code. Together, the two resources make it > possible to read Lions not only as a historical text, but against a living V6 > system assembled from the original distribution materials. > > Guide: > https://decuser.github.io/posts/setting-up-unix-sixth-edition-opensimh-laboratory-for-reading-lions/ > > Companion source edition: > https://decuser.github.io/posts/updated-lions-v6-source-w-appendices-and-helps-v1.4/ > > The guide takes me about 15 minutes to work through now, but I expect a > careful first reading and installation will take a couple of hours. > > I would be glad to hear from anyone who takes a look, even if only to let me > know you had a chance to read it. Corrections, questions, and suggestions are > especially welcome. > > Regards, > Will > > durtal at sdf.org SDF Public Access UNIX System - https://sdf.org From tuhs at tuhs.org Mon Jul 27 00:06:28 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Sun, 26 Jul 2026 09:06:28 -0500 Subject: [TUHS] =?utf-8?q?Setting_Up_UNIX=E2=80=94Sixth_Edition=3A_An_Ope?= =?utf-8?q?nSIMH_Laboratory_for_Reading_Lions?= In-Reply-To: <58c4f38e-0869-b2f1-928b-950457be887b@sdf.org> References: <6ec791de-5727-43a3-8f6a-e981608c1d9b@gmail.com> <58c4f38e-0869-b2f1-928b-950457be887b@sdf.org> Message-ID: <2e4c977c-7284-41cb-8002-8687e3304b48@gmail.com> Thanks, Rick. I write the things I wish I'd had and also to remind me when I forget :). This latest note is a bit different from the others, though it might look the same on surface reading. The others were to get the os working for modern folks, this one is to put it closer to the state it would have been when Lions was teaching and conducting labs. It's not as hand-holdy and it isn't meant to be comfortable, just realiably mundane. In working through it several times and then using it for experimentation many times, what strikes me is the luxury of our modern era. Where he was constrained by the era, budget, and sheer physicality of it all, I can screw up the first stage loader, second stage loader, destroy my filesystem completely (don't point two pdp11's at the same rk0, it's confusing and nightmarish), and do pretty much anything I want to it, it's just a quick cp backup/* . later and I'm back up and running pristine. Oh, yeah, Texas is awesome. I hope your daughter likes it here. One of these days, I need to get down under - lots of friends of mine are in the southern hemisphere. Later, Will On 7/26/26 12:20 AM, durtal wrote: > > Thanks for this update...I found your earlier work very helpful in > getting things up and running. I haven't had the time to look at the > v7 info. > Your Apple II assembly work has been much appreciated as well. However, > I'm still trying to get my head around it % ). > > BTW, nine years ago a Texas boy whisked away our Aussie daughter. They > live in Cedar Hill with two of our grandchildren. > > Rick > > > On Fri, 24 Jul 2026, Will Senn via TUHS wrote: > >> Date: Fri, 24 Jul 2026 13:23:57 -0500 >> From: Will Senn via TUHS >> Reply-To: Will Senn >> To: "tuhs at tuhs.org" >> Subject: [TUHS] Setting Up UNIX?Sixth Edition: An OpenSIMH Laboratory >> for >>     Reading Lions >> >> Hi all, >> >> I support the proposed IEEE Milestone recognizing John Lions' UNIX >> Operating System Source Code Level Six and A Commentary on the UNIX >> Operating System. Few works have had a comparable influence on >> operating systems education, and it is fitting to see them considered >> for formal recognition. >> >> With that discussion underway, I thought I would mention a companion >> resource I have just completed. >> >> For the past several years, I have been working with V6 under >> OpenSIMH for a variety of purposes, and I have written up the general >> installation and customization process before. This is not another of >> those notes. Setting Up UNIX?Sixth Edition: An OpenSIMH Laboratory >> for Reading Lions is written in the genre of Thompson and Ritchie's >> original memo: a procedure, in their register, addressed to someone >> assembling a specific machine and environment. Its scope is both >> narrower than theirs and broader. It constructs a modern virtual >> counterpart to the laboratory in which Lions' students worked. An >> installation guide ends at a login prompt, but this guide goes >> further: to a correspondence among the running kernel, the source >> tree from which it was built, and the listing Lions annotates, all >> resolvable against one another. >> >> The original laboratory required a PDP-11/40, controllers, several >> RK05 drives, magnetic tape, terminals, a printer, removable media, >> and the accompanying source and documentation. In the reconstructed >> laboratory, those components take different forms. OpenSIMH supplies >> the processor, memory, controllers, and peripheral devices. The >> distribution tape and removable disk packs are represented by image >> files, while a modern terminal program provides access to the running >> system. The cabinets, motors, reels, and 14-inch platters have >> disappeared, but the interfaces presented to V6 remain those of the >> original machine. V6 does not know the difference. >> >> The guide leads readers who want to study Lions in a working >> laboratory environment through restoring the original V6 distribution >> from tape, rebuilding the kernel, installing the complete source and >> documentation filesystems, creating the required device files, >> verifying the installation, and producing a restorable baseline >> archive. The completed laboratory is configured to match the presumed >> model system described by Lions on page 1-2 of the Commentary. It >> allows readers to boot the system, examine the installed source, >> rebuild the kernel, and move directly among the running system, the >> source deployed from the original distribution tape, and the edited >> listing published as UNIX Operating System Source Code Level Six. >> >> The guide is intended to be used together with my updated and >> expanded edition of UNIX Operating System Source Code Level Six, >> which preserves Lions' original sheet numbering while adding file >> locations, procedure listings, indexes, cross references, and >> configured-kernel symbol tables keyed to the delivered source code. >> Together, the two resources make it possible to read Lions not only >> as a historical text, but against a living V6 system assembled from >> the original distribution materials. >> >> Guide: >> https://decuser.github.io/posts/setting-up-unix-sixth-edition-opensimh-laboratory-for-reading-lions/ >> >> >> Companion source edition: >> https://decuser.github.io/posts/updated-lions-v6-source-w-appendices-and-helps-v1.4/ >> >> >> The guide takes me about 15 minutes to work through now, but I expect >> a careful first reading and installation will take a couple of hours. >> >> I would be glad to hear from anyone who takes a look, even if only to >> let me know you had a chance to read it. Corrections, questions, and >> suggestions are especially welcome. >> >> Regards, >> Will >> >> > > durtal at sdf.org > SDF Public Access UNIX System - https://sdf.org From tuhs at tuhs.org Tue Jul 28 02:01:24 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Mon, 27 Jul 2026 11:01:24 -0500 Subject: [TUHS] V6 Distribution Tape Message-ID: <85a64d0d-43b2-4a49-af81-ba98d64aeb8a@gmail.com> Hi all, I'm digging into the Sixth Edition standalone boot loaders and have run into a question that I haven't been able to answer from the manuals or source. The "Setting Up UNIX – Sixth Edition" document explains how to /use/the distribution tape. For example, |tmrk|copies tape block 100 to disk block 0 (the RK bootstrap), then copies blocks 101–4099 as the binary filesystem. Likewise, the source and document filesystems begin at 4101 and 8101 respectively. Looking at |/usr/source/mdec/mboot.s|, however, it appears that the beginning of the tape is itself a small |tp|-style archive. |mboot|prompts for a filename, scans what looks like a |tp|directory, finds entries such as |tmrk|, reads the corresponding records, and transfers control to the selected standalone program. I've read |mboot.s|, |tboot.s|, etc, and of course, /Setting Up UNIX – Sixth Edition/, and I understand how the boot tape is consumed. What I'm looking for is the original build/mastering process, if anyone remembers it or has documentation. Was there a script, makefile, or documented procedure that: * assembled and stripped the standalone programs, * created the |tp|archive containing |tmrk|, |htrk|, |tmrp|, etc., * installed |mboot|/|hboot|at the beginning of the tape, * positioned |rkuboot|, |rpuboot|, and |hpuboot|at their fixed record numbers, * and finally appended the three 4000-block filesystem images? Or was the tape assembled in some other way entirely? I'm not looking for modern reconstruction techniques—I can build one today. I'm interested in how Bell Labs originally mastered the V6 distribution tapes. If anyone remembers the release procedure, or knows of surviving documentation or scripts, I'd appreciate any pointers. Thanks, Will From tuhs at tuhs.org Wed Jul 29 03:14:41 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Tue, 28 Jul 2026 12:14:41 -0500 Subject: [TUHS] What It Takes to Read Lions in 2026 Message-ID: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> All, As an experiment, I tracked what it takes a modernista to understand a small portion of page 28 of Lions (Getting Started) and thought I would share. Here's the relevant portion from the page: ---snip 0615: “reset” clears and initialises all the peripheral device control and status registers The system will now be running in kernel mode with memory management disabled. 0619: KISA0 and KISD0 are the high core addresses of the first pair of kernel mode segmentation registers. The first six kernel descriptor registers are initialised to 077406, which is the description of a full size, 4K word,read/write segment. The first six kernel address registers are initialised to 0, 0200, 0400, 0600, 01000 and 01200 respectively. As a result the first six kernel segments are initialised (without any reference to the actual size of UNIX) to point to the first six 4K word segments of physical memory. Thus the “kernel to physical address” translation is trivial for kernel addresses in the range 0 to 0137777; ---snip  These few lines discuss RESET, the initial PAR/PDR (KISA/KISD) setup, and the statement that "kernel to physical address translation is trivial." Following those references led me through the source, l.s and m40.s, the PDP-11/40 Processor Handbook, and the KT11-D Memory Management Option User Manual. My notes then ran on a bit (HB is the processor handbook, MM is the memory management option user manual): ---snip 613 - "clear" button must refer to the "start" button. when "start" is pressed and the system is halted, this "clears" the system. HB 8-3. 615 - 1) HB 4-76. 2) this is as a result of following 6.1 (Operator Actions) and issuing RESET from code. 619 - PAR/PDR registers are documented in the KT11-D memory management option user manual (MM) starting on page 3-11. Table 3-1 gives the PAR/PDR address assignments and figure 3-6 gives the PDR format. Table 3-2 gives the decoding of the ACF bits of the PDR: 077406 - 0 1111111 0 0 00  0  11 0          -   PLF   - W -- ED ACF - This sets PLF to 0177, aka 127, so 128 blocks of 32 words, or 4096 words, the full-size segment. W=0 means that the hardware has not yet recorded a write to the segment since its PAR or PDR was loaded. ED=0 means the segment starts at 0 and extends upward, and ACF=11 (6) means that the segment is read or write. "the description of a full size, 4k word, read/write segment". Six PAR/PDR pairs are initialized because six 4K-word segments account for the 24K words of physical memory expected in this configuration. The PARs receive 0000, 0200, 0400, 0600, 1000, and 1200. A PAR value is expressed in units of 32 words, or 64 bytes. Thus an increment of 0200 octal represents 128 such units: 0200 × 32 words = 4096 words                = 8192 bytes                = 020000 bytes Successive PAR values therefore map successive 4K-word physical segments beginning at 000000, 020000, 040000, and so on. The six mapped ranges are: segment 0: 0000000–0017777 segment 1: 0020000–0037777 segment 2: 0040000–0057777 segment 3: 0060000–0077777 segment 4: 0100000–0117777 segment 5: 0120000–0137777 Together they span 0140000 (48K) bytes, so the last byte is 0137777. Because each kernel virtual segment maps onto the physical segment with the same base address, virtual and physical addresses are identical from 0 through 0137777; this is the “trivial” translation Lions describes. ---snip These notes are themselves compressed. "HB 4-76" really means "go spend ten minutes digging around in the Processor Handbook figuring out what Lions assumes you already know about clear aka reset." Lions is great, but today's reader needs more of a leg up. I think it illustrates how much architectural knowledge his original audience could take for granted. Nearly fifty years later, recovering that context has become part of reading the book. So, reading through Lions in 2026 is an archaeological dig, really :). That said, if you're planning to read Lions with any depth, be sure to minimally have on hand: * Lions Commentary * Lions Source Code * PDP-11/40 Processor Handbook * KT11-D Memory Management Option User Manual * Repeatable notes for setting up a working lab Later, Will From tuhs at tuhs.org Wed Jul 29 03:34:04 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Tue, 28 Jul 2026 17:34:04 +0000 Subject: [TUHS] What It Takes to Read Lions in 2026 In-Reply-To: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> References: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> Message-ID: Will, Agreed and it applies in many similar contexts. If I was writing a book on the Sinclair ZX81 / Timex Sinclair 1000, back in say 1983, I could warn readers, "16 kB RAM pack users, don't place heavy objects on the desk unless you do so slowly and with extreme care." Readers in 1983 would have already found out why but appreciate the reminder. A 2026 reader might have typed in, or poked in, in the case of Z80 assembly, something large, not yet have saved it to Compact Cassette, read the warning about heavy objects, slapped the book down beside the machine and _then_ found out why they shouldn't have done that. I totally appreciate the "on hand" list, especially as I was actually considering, in light of recent events, finally reading Lions. Have a great rest of your week, Cameron -------- Original Message -------- On Tuesday, 07/28/26 at 18:15 Will Senn via TUHS wrote, in part: These notes are themselves compressed. "HB 4-76" really means "go spend ten minutes digging around in the Processor Handbook figuring out what Lions assumes you already know about clear aka reset." Lions is great, but today's reader needs more of a leg up. I think it illustrates how much architectural knowledge his original audience could take for granted. Nearly fifty years later, recovering that context has become part of reading the book. So, reading through Lions in 2026 is an archaeological dig, really :). From tuhs at tuhs.org Wed Jul 29 04:40:48 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 28 Jul 2026 18:40:48 +0000 Subject: [TUHS] What It Takes to Read Lions in 2026 In-Reply-To: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> References: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> Message-ID: On Tuesday, July 28th, 2026 at 10:14, Will Senn via TUHS wrote: > Lions is great, but today's reader needs more of a leg up. I think it > illustrates how much architectural knowledge his original audience could > take for granted. Nearly fifty years later, recovering that context has > become part of reading the book. So, reading through Lions in 2026 is an > archaeological dig, really :). That said, if you're planning to read > Lions with any depth, be sure to minimally have on hand: > > * Lions Commentary > > * Lions Source Code > > * PDP-11/40 Processor Handbook > > * KT11-D Memory Management Option User Manual > > * Repeatable notes for setting up a working lab > > Later, > > Will > For the record, the intro does indicate what auxiliary knowledge may be necessary, pointing the reader to the manual, several papers such as C tutorials and UNIX for Beginners, as well as listing knowledge of the following PDP-11 hardware useful: - PDP11/40 - RK05 - LP11 - PC11 - KL11 You also do get a bit of hardware exposition, albeit not too much, in Chapter 2. This implies having the PDP-11 Peripherals Handbook on hand would also be helpful. Naturally our biases allow us to overlook this, but having both the UNIX Assember Manual and C Reference Manual on hand would be helpful to the uninitiated as those are the two languages at play in the source volume. Not sure how necessary this would be in practice but UNIX is an ASCII system, so non-ASCII-ites, however rare these days, would be going in with some unhelpful biases, but I don't know if that would peg the ASCII standard as required context. I'm a sucker for building complete reference documentation graphs...so I'm going to hold my urge further for now. Still, it would be an interesting exercise to pursue the full graph of primary references needed to establish a normative reference graph for Lions's Commentary. Will, I don't know if this would be a comparable follow-on project, but there is the Program Description document published with USG UNIX that serves as another detailed analysis of the UNIX kernel[1] that may be worth inspecting with a similar lens. By the way, I have a later hardcopy of [1] issued with Program Generic 3. Unfortunately its just a reprint of the Program Generic 2 version and does not include the kernel changes in PG3, but it is complete, so I plan on scanning it in my next round of documents. - Matt G. [1] - unix_program_description_jan_1976.pdf From tuhs at tuhs.org Wed Jul 29 12:07:29 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 28 Jul 2026 22:07:29 -0400 Subject: [TUHS] What It Takes to Read Lions in 2026 In-Reply-To: References: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> Message-ID: Will/Matt, You both make interesting observations, and I tried to go back a little and remember what resources I had when I encountered Lions (and made my xerographic copy). At the time (which I think was late 1977 or early 78), I had my own copy of the 1974/75 PDP-11 04/34/45/55 Processor Handbook [ https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_04-55_Processor_Handbook_1976.pdf] and the 1976 PDP-11 Peripherals Handbook† [ https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_PeripheralsHbk_1976.pdf] Note I had the 34 docs, not the 40 docs. I also had access to the docs from Sixth Edition, such as the C Reference manual. Also remember that I was not using it as a course text, which is why he wrote it. When I discovered it, the book was just a wonderful resource that helped explain in more detail a lot of things I already had an inkling of, and as I look back, probably corrected some misunderstandings too. That said, before I read Lions, I had already been programming UNIX for a year or two on the 11/40E (IUS and SUS) in the CS Dept. We had converted from Fifth Edition to Sixth (I personally had very brief experiences with Fifth - it was in my "what is this strange system and language phase," introduction to UNIX having come over from BLISS and both a DEC and IBM flavor of how OS's were supposed to present themselves). But in the summer before I saw Lions, we had received our first 11/34 in the EE Dept. We couldn't just use Dennis's distribution tape, since a 34 is a 40-class processor (which are similar but different enough; it's not going to "just work" — *i.e*., not something the stock Sixth Edition knew about). So, we bootstrapped the EE 34 from IUS, which was tricky because we had to add 34 support to mch40.s, more importantly, the 34 didn't have the CSV/CRET in the writable microcode of the 11/40Es that the C compiler on the CS systems expected (I have memories of walking back and forth between the two buildings creating yet another RK05 boot image when we found some other important program that was expecting CSV/CRET but weren't far/stable enough along in the bootstrap to correct it ourselves). FWIW: I had had some exposure to RT-11 on an 11/05 [running from DEC cassette tapes], as well as programming the PDP-8 running TSS/8 and the 10s under TOPS, as well as working for the Computer Center supporting York/APL on the IBM 360/67. But I think most importantly for my UNIX kernel experience, I had started to work on the Computer Center's version of the CMU Front End, trying to add support for the 11/45 they had running RSTS for the School of Humanities and Social Science. As I have mentioned in other emails, the CMU FE was a standalone system (no OS) with a ton of serial ports, a card reader and printer, and some sort of interface to larger systems (in the CC's case, the 360 for interactive serial ports and as an RJE station for the 360 and Univac 1008, and we were adding the then new RSTS system). At that point, it was based on an 11/15 (no MMU, of course, and the code was primarily in BLISS-11 with a very small assembler assist). The key is I was already inoculated with the core PDP-11 ISA and differences between models, so much of what you are commenting about with PDP-11-ism, such as the RESET instruction or the PARS, was already something I had learned before. To me, Lions was explaining how Ken uses them in the kernel. My point is I didn't walk into reading Lions without some core experience with the PDP-11 family. Some of the peripherals, like the KL/DLs and clock, I was certainly extremely familiar with, and I already understood about MMUs (the 67 running TSS was IBM's first VM system). Across so many different CMU systems, we had aftermarket disks on most of them [the DEC RP03/04 were made by Univac, but they were actually clones of the IBM 2314/2316 (only slightly different)]. IIRC we had CDC flavors of them which they called the 84x series, and IIRC we had to modify the rp.c driver slightly to make them work properly. So I had already learned how to hack the disk drivers by then. But I never had access to real manuals for any of the DEC peripherals other than the 76 Peripherals Handbook until we got one of the first RK07s and the RK611/711 controller. Danny Klein and I wrote the first UNIX driver for it, cribbing from the already hacked RP04/5/6 driver and reading Dennis' V6 driver manual. I had already been doing a small amount of the kernel mods by then, and we had started to write fsck(8) as well. But when I saw it (and made my own copy), I thought Lions helped me better understand the system than I had before. It certainly gave me more confidence about what subsystems I would attack (more in a minute). At some point, but it had to have been after I saw Lions, Ted Kowalski had a xerographic copy of the proofs for K&R1 in a binder (which I copied), and by late 78 I had obtained a xerographic copy of the "Unix program description" doc that Matt referred to (I think I got that from Phil Karn, but it might have been Ted). FWIW: A few years later, my old friend and then colleague at Tektronix, Mike Zuhl, made an interesting observation, which I think actually plays into your comments about Lions. Zuhl was one of the Purdue EE UNIX folks (like the late George Goble and Ward Cunningham). Zuhl said: *"Hacking on the Unix kernel is a lot like riding a motorcycle. At first you are scared sh*tless that you don't want to screw up. After a while, you get confident in your abilities and are willing to try anything. Finally, you realize it is really just an incredibly beautiful hack that works in a manner like no other, and you start to respect it and those that came before you*." For me, reading Lions was part of my transition in the third phase. He explains things I basically knew before at a more macro level. My thoughts/recollections if it is of any help, Clem † To this day, I still think the 1976 Peripherals Handbook was the best one DEC made, and if you are looking at Sixth or Seventh Editions, it is really all you need for most of the peripherals they supported. Later ones include some information about later products such as the RL01/2 and RK06/7, but they dropped many of them outright in some cases, and in others the core descriptions are not nearly as detailed/useful. On Tue, Jul 28, 2026 at 2:41 PM segaloco via TUHS wrote: > On Tuesday, July 28th, 2026 at 10:14, Will Senn via TUHS > wrote: > > > Lions is great, but today's reader needs more of a leg up. I think it > > illustrates how much architectural knowledge his original audience could > > take for granted. Nearly fifty years later, recovering that context has > > become part of reading the book. So, reading through Lions in 2026 is an > > archaeological dig, really :). That said, if you're planning to read > > Lions with any depth, be sure to minimally have on hand: > > > > * Lions Commentary > > > > * Lions Source Code > > > > * PDP-11/40 Processor Handbook > > > > * KT11-D Memory Management Option User Manual > > > > * Repeatable notes for setting up a working lab > > > > Later, > > > > Will > > > > For the record, the intro does indicate what auxiliary knowledge may be > necessary, pointing the reader to the manual, several papers such as C > tutorials and UNIX for Beginners, as well as listing knowledge of the > following PDP-11 hardware useful: > > - PDP11/40 > - RK05 > - LP11 > - PC11 > - KL11 > > You also do get a bit of hardware exposition, albeit not too much, in > Chapter 2. > > This implies having the PDP-11 Peripherals Handbook on hand would also be > helpful. Naturally our biases allow us to overlook this, but having both > the UNIX Assember Manual and C Reference Manual on hand would be helpful to > the uninitiated as those are the two languages at play in the source > volume. Not sure how necessary this would be in practice but UNIX is an > ASCII system, so non-ASCII-ites, however rare these days, would be going in > with some unhelpful biases, but I don't know if that would peg the ASCII > standard as required context. I'm a sucker for building complete reference > documentation graphs...so I'm going to hold my urge further for now. > > Still, it would be an interesting exercise to pursue the full graph of > primary references needed to establish a normative reference graph for > Lions's Commentary. > > Will, I don't know if this would be a comparable follow-on project, but > there is the Program Description document published with USG UNIX that > serves as another detailed analysis of the UNIX kernel[1] that may be worth > inspecting with a similar lens. By the way, I have a later hardcopy of [1] > issued with Program Generic 3. Unfortunately its just a reprint of the > Program Generic 2 version and does not include the kernel changes in PG3, > but it is complete, so I plan on scanning it in my next round of documents. > > - Matt G. > > [1] - unix_program_description_jan_1976.pdf > From tuhs at tuhs.org Wed Jul 29 13:12:45 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Tue, 28 Jul 2026 22:12:45 -0500 Subject: [TUHS] Anyone have a connection to Tom DeMarco? Message-ID: <20260729031245.dip26o2zpfyhrnkg@illithid> Hi folks, I know he's not really a Unix personage, but since I'm a whippersnapper I know no better place to turn--and my purpose _is_ Unix- related, if troff counts as such. I was perusing Tom DeMarco's _Structured Analysis and System Specification_ (1979) (foreword: P. J. Plauger) and noticed that, while lacking a colophon acknowledging its means of production, it looks for all the world as if it had been typeset with troff. Here are the questions I would have for Mr. DeMarco. 1. Am I right? Was troff used in its production? 2. The book has been out of print for many years. Have its rights reverted to the author as is common (but not quite universal) in publishing contracts? 3. If so, do you still have the troff input files used to prepare it? 4. If so, would you be willing to license these files to the community under FLOSS terms[1]? If someone can pass along these questions or put me in touch with Mr. DeMarco, I'd be grateful. Also, if someone could pop a copy of this book into a DeLorean traveling at 88mph and send it back in time to me at the start of my career with a note ("postpone Fred Brooks and read this first"), the younger me will put a few hundred USD into a Vanguard-managed index fund in your name. Every software engineer who winds up in a consulting gig should be gifted with a waiter's cloche and a wooden spoon. They'll figure out what they're for. Regards, Branden [1] https://en.wikipedia.org/wiki/Free_and_open-source_software -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Wed Jul 29 13:26:26 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Wed, 29 Jul 2026 13:26:26 +1000 Subject: [TUHS] What It Takes to Read Lions in 2026 In-Reply-To: References: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> Message-ID: I'd say the motorbike analogy demands extension to "... and then you forget how dangerous it is and slide off on a corner and lose a lot of skin" -G > > From tuhs at tuhs.org Wed Jul 29 14:57:09 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 28 Jul 2026 22:57:09 -0600 Subject: [TUHS] Anyone have a connection to Tom DeMarco? In-Reply-To: <20260729031245.dip26o2zpfyhrnkg@illithid> References: <20260729031245.dip26o2zpfyhrnkg@illithid> Message-ID: <202607290457.66T4v9ve075446@freefriends.org> According to www.tomdemarco.com: He lives with his wife, Sally Smyth, in Camden on the coast of Maine. Phone book searching may turn up a phone number or a postal address. There is no "contact" option on that web page. Good luck, Arnold "G. Branden Robinson via TUHS" wrote: > Hi folks, > > I know he's not really a Unix personage, but since I'm a whippersnapper > I know no better place to turn--and my purpose _is_ Unix- related, if > troff counts as such. > > I was perusing Tom DeMarco's _Structured Analysis and System > Specification_ (1979) (foreword: P. J. Plauger) and noticed that, while > lacking a colophon acknowledging its means of production, it looks for > all the world as if it had been typeset with troff. > > Here are the questions I would have for Mr. DeMarco. > > 1. Am I right? Was troff used in its production? > > 2. The book has been out of print for many years. Have its rights > reverted to the author as is common (but not quite universal) in > publishing contracts? > > 3. If so, do you still have the troff input files used to prepare it? > > 4. If so, would you be willing to license these files to the community > under FLOSS terms[1]? > > If someone can pass along these questions or put me in touch with Mr. > DeMarco, I'd be grateful. > > Also, if someone could pop a copy of this book into a DeLorean traveling > at 88mph and send it back in time to me at the start of my career with a > note ("postpone Fred Brooks and read this first"), the younger me will > put a few hundred USD into a Vanguard-managed index fund in your name. > > Every software engineer who winds up in a consulting gig should be > gifted with a waiter's cloche and a wooden spoon. > > They'll figure out what they're for. > > Regards, > Branden > > [1] https://en.wikipedia.org/wiki/Free_and_open-source_software From tuhs at tuhs.org Wed Jul 29 21:23:38 2026 From: tuhs at tuhs.org (Mark Seiden via TUHS) Date: Wed, 29 Jul 2026 13:23:38 +0200 Subject: [TUHS] Anyone have a connection to Tom DeMarco? In-Reply-To: <202607290457.66T4v9ve075446@freefriends.org> References: <20260729031245.dip26o2zpfyhrnkg@illithid> <202607290457.66T4v9ve075446@freefriends.org> Message-ID: we’re friends. i sent it on to him. > On Jul 29, 2026, at 6:57 AM, Arnold Robbins via TUHS wrote: > > According to www.tomdemarco.com: > > He lives with his wife, Sally Smyth, in Camden on the coast of Maine. > > Phone book searching may turn up a phone number or a postal address. > > There is no "contact" option on that web page. > > Good luck, > > Arnold > > "G. Branden Robinson via TUHS" wrote: > >> Hi folks, >> >> I know he's not really a Unix personage, but since I'm a whippersnapper >> I know no better place to turn--and my purpose _is_ Unix- related, if >> troff counts as such. >> >> I was perusing Tom DeMarco's _Structured Analysis and System >> Specification_ (1979) (foreword: P. J. Plauger) and noticed that, while >> lacking a colophon acknowledging its means of production, it looks for >> all the world as if it had been typeset with troff. >> >> Here are the questions I would have for Mr. DeMarco. >> >> 1. Am I right? Was troff used in its production? >> >> 2. The book has been out of print for many years. Have its rights >> reverted to the author as is common (but not quite universal) in >> publishing contracts? >> >> 3. If so, do you still have the troff input files used to prepare it? >> >> 4. If so, would you be willing to license these files to the community >> under FLOSS terms[1]? >> >> If someone can pass along these questions or put me in touch with Mr. >> DeMarco, I'd be grateful. >> >> Also, if someone could pop a copy of this book into a DeLorean traveling >> at 88mph and send it back in time to me at the start of my career with a >> note ("postpone Fred Brooks and read this first"), the younger me will >> put a few hundred USD into a Vanguard-managed index fund in your name. >> >> Every software engineer who winds up in a consulting gig should be >> gifted with a waiter's cloche and a wooden spoon. >> >> They'll figure out what they're for. >> >> Regards, >> Branden >> >> [1] https://en.wikipedia.org/wiki/Free_and_open-source_software From tuhs at tuhs.org Thu Jul 30 22:56:10 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Thu, 30 Jul 2026 07:56:10 -0500 Subject: [TUHS] What It Takes to Read Lions in 2026 In-Reply-To: References: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> Message-ID: Clem, Wow. This makes so much sense. I "randomly" picked page 28 as a starting point, never mind that the section was called "Getting Started". That was possibly the worst/best place to begin, because it is where the PDP11 -> unix transition takes place. When Lions talks about it, it's clear that he's speaking from the unix side of things with enough PDP to orient a denizen of the times, but not a techie from the future who is ot familiar with stuff like core, I/O regions of memory, or severe hardware limitations. Having struggled to parse every sentence along the way, I've made the journey from the processor handbook - where I found a typo in the 11/40 version... it says:     Certain memory locations have been reserved by the system for inter·     rupt and trap handling, processor stacks, general registers, and peripheral     device registers. K.ernel virtual addresses from 0 to 370, are always re-     served and those to 777, are reserved on large system configurations for     traps and interrupt handling. The top 4,096 word addresses (from     770000, up) have been reserved for general registers and peripheral     devices. But, after a couple of hours of head scratching it dawned on me that 770000-777777 was only 2K words and couldn't possibly be right, 760000 is the correct number. Which is click 7600, which is what's loaded into KIPAR7, which the m40 assist maps as IO. Which is properly described in the 1976 11/04/34/45/44 version as:     If the Memory Management option is not used, an octal address be-     tween 160 000 and 177 777 is interpreted as 760 000 to 777 777. That     is, if bit 15, 14 and 13 are 1 's, then bits 17 and 16 (the extended ad-     dress bits) are considered to be 1's, which relocates the last 4K words.     (8K bytes) to become the highest location accessed by the UNIBUS. Then on into the peripherals book, the memory management options book, and the v6 manual. In addition, whereas previously, I ignored the source code, now I find it invaluable. Where it says _end is some linker thing (I originally read it as a pseudo op, but it's more something the loader adds). I just pulled up the source, figured out it adds it to the binary if it's referenced in code and that it refers to the boundary of the image (one past the last byte) or in the "as" documentation where Dennis say it's a rather ordinary 2 pass assembler with no macros. I no longer take this as gospel, it's off to the as source where it turns out it's anything but ordinary, not really a two pass assembler (two programs, one that builds a very nice compact representation and the other that takes two passes)  and it trades an insane amount of language affordance for macros... heck it'll even let you define your own assembly instructions :). It's the little things :). Will On 7/28/26 9:07 PM, Clem Cole via TUHS wrote: > Will/Matt, > > You both make interesting observations, and I tried to go back a little and > remember what resources I had when I encountered Lions (and made my > xerographic copy). At the time (which I think was late 1977 or early 78), > I had my own copy of the 1974/75 PDP-11 04/34/45/55 Processor Handbook [ > https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_04-55_Processor_Handbook_1976.pdf] > and the 1976 PDP-11 Peripherals Handbook† [ > https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_PeripheralsHbk_1976.pdf] > Note I had the 34 docs, not the 40 docs. I also had access to the docs > from Sixth Edition, such as the C Reference manual. > > Also remember that I was not using it as a course text, which is why he > wrote it. When I discovered it, the book was just a wonderful resource > that helped explain in more detail a lot of things I already had an inkling > of, and as I look back, probably corrected some misunderstandings too. > > That said, before I read Lions, I had already been programming UNIX for a > year or two on the 11/40E (IUS and SUS) in the CS Dept. We had converted > from Fifth Edition to Sixth (I personally had very brief experiences with > Fifth - it was in my "what is this strange system and language phase," > introduction to UNIX having come over from BLISS and both a DEC and IBM > flavor of how OS's were supposed to present themselves). But in the summer > before I saw Lions, we had received our first 11/34 in the EE Dept. We > couldn't just use Dennis's distribution tape, since a 34 is a 40-class > processor (which are similar but different enough; it's not going to "just > work" — *i.e*., not something the stock Sixth Edition knew about). So, we > bootstrapped the EE 34 from IUS, which was tricky because we had to add 34 > support to mch40.s, more importantly, the 34 didn't have the CSV/CRET in > the writable microcode of the 11/40Es that the C compiler on the CS systems > expected (I have memories of walking back and forth between the two > buildings creating yet another RK05 boot image when we found some other > important program that was expecting CSV/CRET but weren't far/stable enough > along in the bootstrap to correct it ourselves). > > FWIW: I had had some exposure to RT-11 on an 11/05 [running from DEC > cassette tapes], as well as programming the PDP-8 running TSS/8 and the 10s > under TOPS, as well as working for the Computer Center supporting York/APL > on the IBM 360/67. But I think most importantly for my UNIX kernel > experience, I had started to work on the Computer Center's version of the > CMU Front End, trying to add support for the 11/45 they had running RSTS > for the School of Humanities and Social Science. As I have mentioned in > other emails, the CMU FE was a standalone system (no OS) with a ton of > serial ports, a card reader and printer, and some sort of interface to > larger systems (in the CC's case, the 360 for interactive serial ports and > as an RJE station for the 360 and Univac 1008, and we were adding the then > new RSTS system). At that point, it was based on an 11/15 (no MMU, of > course, and the code was primarily in BLISS-11 with a very small assembler > assist). The key is I was already inoculated with the core PDP-11 ISA and > differences between models, so much of what you are commenting about with > PDP-11-ism, such as the RESET instruction or the PARS, was already > something I had learned before. To me, Lions was explaining how Ken uses > them in the kernel. > > My point is I didn't walk into reading Lions without some core experience > with the PDP-11 family. Some of the peripherals, like the KL/DLs and > clock, I was certainly extremely familiar with, and I already understood > about MMUs (the 67 running TSS was IBM's first VM system). Across so many > different CMU systems, we had aftermarket disks on most of them [the DEC > RP03/04 were made by Univac, but they were actually clones of the IBM > 2314/2316 (only slightly different)]. IIRC we had CDC flavors of them > which they called the 84x series, and IIRC we had to modify the rp.c driver > slightly to make them work properly. So I had already learned how to hack > the disk drivers by then. But I never had access to real manuals for > any of the DEC peripherals other than the 76 Peripherals Handbook until we > got one of the first RK07s and the RK611/711 controller. Danny Klein and > I wrote the first UNIX driver for it, cribbing from the already hacked > RP04/5/6 driver and reading Dennis' V6 driver manual. I had already been > doing a small amount of the kernel mods by then, and we had started to > write fsck(8) as well. But when I saw it (and made my own copy), I thought > Lions helped me better understand the system than I had before. It > certainly gave me more confidence about what subsystems I would attack > (more in a minute). > > At some point, but it had to have been after I saw Lions, Ted Kowalski had > a xerographic copy of the proofs for K&R1 in a binder (which I copied), and > by late 78 I had obtained a xerographic copy of the "Unix program > description" doc that Matt referred to (I think I got that from Phil Karn, > but it might have been Ted). > > FWIW: A few years later, my old friend and then colleague at Tektronix, > Mike Zuhl, made an interesting observation, which I think actually plays > into your comments about Lions. Zuhl was one of the Purdue EE UNIX folks > (like the late George Goble and Ward Cunningham). Zuhl said: *"Hacking on > the Unix kernel is a lot like riding a motorcycle. At first you are scared > sh*tless that you don't want to screw up. After a while, you get > confident in your abilities and are willing to try anything. Finally, you > realize it is really just an incredibly beautiful hack that works in a > manner like no other, and you start to respect it and those that came > before you*." > > For me, reading Lions was part of my transition in the third phase. He > explains things I basically knew before at a more macro level. > > My thoughts/recollections if it is of any help, > Clem > > † To this day, I still think the 1976 Peripherals Handbook was the best > one DEC made, and if you are looking at Sixth or Seventh Editions, it is > really all you need for most of the peripherals they supported. Later > ones include some information about later products such as the RL01/2 and > RK06/7, but they dropped many of them outright in some cases, and in others > the core descriptions are not nearly as detailed/useful. > > On Tue, Jul 28, 2026 at 2:41 PM segaloco via TUHS wrote: > >> On Tuesday, July 28th, 2026 at 10:14, Will Senn via TUHS >> wrote: >> >>> Lions is great, but today's reader needs more of a leg up. I think it >>> illustrates how much architectural knowledge his original audience could >>> take for granted. Nearly fifty years later, recovering that context has >>> become part of reading the book. So, reading through Lions in 2026 is an >>> archaeological dig, really :). That said, if you're planning to read >>> Lions with any depth, be sure to minimally have on hand: >>> >>> * Lions Commentary >>> >>> * Lions Source Code >>> >>> * PDP-11/40 Processor Handbook >>> >>> * KT11-D Memory Management Option User Manual >>> >>> * Repeatable notes for setting up a working lab >>> >>> Later, >>> >>> Will >>> >> For the record, the intro does indicate what auxiliary knowledge may be >> necessary, pointing the reader to the manual, several papers such as C >> tutorials and UNIX for Beginners, as well as listing knowledge of the >> following PDP-11 hardware useful: >> >> - PDP11/40 >> - RK05 >> - LP11 >> - PC11 >> - KL11 >> >> You also do get a bit of hardware exposition, albeit not too much, in >> Chapter 2. >> >> This implies having the PDP-11 Peripherals Handbook on hand would also be >> helpful. Naturally our biases allow us to overlook this, but having both >> the UNIX Assember Manual and C Reference Manual on hand would be helpful to >> the uninitiated as those are the two languages at play in the source >> volume. Not sure how necessary this would be in practice but UNIX is an >> ASCII system, so non-ASCII-ites, however rare these days, would be going in >> with some unhelpful biases, but I don't know if that would peg the ASCII >> standard as required context. I'm a sucker for building complete reference >> documentation graphs...so I'm going to hold my urge further for now. >> >> Still, it would be an interesting exercise to pursue the full graph of >> primary references needed to establish a normative reference graph for >> Lions's Commentary. >> >> Will, I don't know if this would be a comparable follow-on project, but >> there is the Program Description document published with USG UNIX that >> serves as another detailed analysis of the UNIX kernel[1] that may be worth >> inspecting with a similar lens. By the way, I have a later hardcopy of [1] >> issued with Program Generic 3. Unfortunately its just a reprint of the >> Program Generic 2 version and does not include the kernel changes in PG3, >> but it is complete, so I plan on scanning it in my next round of documents. >> >> - Matt G. >> >> [1] - unix_program_description_jan_1976.pdf >> From tuhs at tuhs.org Fri Jul 31 14:55:41 2026 From: tuhs at tuhs.org (Otto Moerbeek via TUHS) Date: Fri, 31 Jul 2026 06:55:41 +0200 Subject: [TUHS] What It Takes to Read Lions in 2026 In-Reply-To: References: <70504aef-cbe7-42a4-9117-6777a6419c36@gmail.com> Message-ID: "Getting Started" talks about the machine, not about the reader :) -Otto On Thu, Jul 30, 2026 at 07:56:10AM -0500, Will Senn via TUHS wrote: > Clem, > > Wow. This makes so much sense. I "randomly" picked page 28 as a starting > point, never mind that the section was called "Getting Started". That was > possibly the worst/best place to begin, because it is where the PDP11 -> > unix transition takes place. When Lions talks about it, it's clear that he's > speaking from the unix side of things with enough PDP to orient a denizen of > the times, but not a techie from the future who is ot familiar with stuff > like core, I/O regions of memory, or severe hardware limitations. Having > struggled to parse every sentence along the way, I've made the journey from > the processor handbook - where I found a typo in the 11/40 version... it > says: > >     Certain memory locations have been reserved by the system for inter· >     rupt and trap handling, processor stacks, general registers, and > peripheral >     device registers. K.ernel virtual addresses from 0 to 370, are always > re- >     served and those to 777, are reserved on large system configurations for >     traps and interrupt handling. The top 4,096 word addresses (from >     770000, up) have been reserved for general registers and peripheral >     devices. > > But, after a couple of hours of head scratching it dawned on me that > 770000-777777 was only 2K words and couldn't possibly be right, 760000 is > the correct number. Which is click 7600, which is what's loaded into KIPAR7, > which the m40 assist maps as IO. Which is properly described in the 1976 > 11/04/34/45/44 version as: > >     If the Memory Management option is not used, an octal address be- >     tween 160 000 and 177 777 is interpreted as 760 000 to 777 777. That >     is, if bit 15, 14 and 13 are 1 's, then bits 17 and 16 (the extended ad- >     dress bits) are considered to be 1's, which relocates the last 4K words. >     (8K bytes) to become the highest location accessed by the UNIBUS. > > Then on into the peripherals book, the memory management options book, and > the v6 manual. In addition, whereas previously, I ignored the source code, > now I find it invaluable. Where it says _end is some linker thing (I > originally read it as a pseudo op, but it's more something the loader adds). > I just pulled up the source, figured out it adds it to the binary if it's > referenced in code and that it refers to the boundary of the image (one past > the last byte) or in the "as" documentation where Dennis say it's a rather > ordinary 2 pass assembler with no macros. I no longer take this as gospel, > it's off to the as source where it turns out it's anything but ordinary, not > really a two pass assembler (two programs, one that builds a very nice > compact representation and the other that takes two passes)  and it trades > an insane amount of language affordance for macros... heck it'll even let > you define your own assembly instructions :). > > It's the little things :). > > Will > > On 7/28/26 9:07 PM, Clem Cole via TUHS wrote: > > Will/Matt, > > > > You both make interesting observations, and I tried to go back a little and > > remember what resources I had when I encountered Lions (and made my > > xerographic copy). At the time (which I think was late 1977 or early 78), > > I had my own copy of the 1974/75 PDP-11 04/34/45/55 Processor Handbook [ > > https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_04-55_Processor_Handbook_1976.pdf] > > and the 1976 PDP-11 Peripherals Handbook† [ > > https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_PeripheralsHbk_1976.pdf] > > Note I had the 34 docs, not the 40 docs. I also had access to the docs > > from Sixth Edition, such as the C Reference manual. > > > > Also remember that I was not using it as a course text, which is why he > > wrote it. When I discovered it, the book was just a wonderful resource > > that helped explain in more detail a lot of things I already had an inkling > > of, and as I look back, probably corrected some misunderstandings too. > > > > That said, before I read Lions, I had already been programming UNIX for a > > year or two on the 11/40E (IUS and SUS) in the CS Dept. We had converted > > from Fifth Edition to Sixth (I personally had very brief experiences with > > Fifth - it was in my "what is this strange system and language phase," > > introduction to UNIX having come over from BLISS and both a DEC and IBM > > flavor of how OS's were supposed to present themselves). But in the summer > > before I saw Lions, we had received our first 11/34 in the EE Dept. We > > couldn't just use Dennis's distribution tape, since a 34 is a 40-class > > processor (which are similar but different enough; it's not going to "just > > work" — *i.e*., not something the stock Sixth Edition knew about). So, we > > bootstrapped the EE 34 from IUS, which was tricky because we had to add 34 > > support to mch40.s, more importantly, the 34 didn't have the CSV/CRET in > > the writable microcode of the 11/40Es that the C compiler on the CS systems > > expected (I have memories of walking back and forth between the two > > buildings creating yet another RK05 boot image when we found some other > > important program that was expecting CSV/CRET but weren't far/stable enough > > along in the bootstrap to correct it ourselves). > > > > FWIW: I had had some exposure to RT-11 on an 11/05 [running from DEC > > cassette tapes], as well as programming the PDP-8 running TSS/8 and the 10s > > under TOPS, as well as working for the Computer Center supporting York/APL > > on the IBM 360/67. But I think most importantly for my UNIX kernel > > experience, I had started to work on the Computer Center's version of the > > CMU Front End, trying to add support for the 11/45 they had running RSTS > > for the School of Humanities and Social Science. As I have mentioned in > > other emails, the CMU FE was a standalone system (no OS) with a ton of > > serial ports, a card reader and printer, and some sort of interface to > > larger systems (in the CC's case, the 360 for interactive serial ports and > > as an RJE station for the 360 and Univac 1008, and we were adding the then > > new RSTS system). At that point, it was based on an 11/15 (no MMU, of > > course, and the code was primarily in BLISS-11 with a very small assembler > > assist). The key is I was already inoculated with the core PDP-11 ISA and > > differences between models, so much of what you are commenting about with > > PDP-11-ism, such as the RESET instruction or the PARS, was already > > something I had learned before. To me, Lions was explaining how Ken uses > > them in the kernel. > > > > My point is I didn't walk into reading Lions without some core experience > > with the PDP-11 family. Some of the peripherals, like the KL/DLs and > > clock, I was certainly extremely familiar with, and I already understood > > about MMUs (the 67 running TSS was IBM's first VM system). Across so many > > different CMU systems, we had aftermarket disks on most of them [the DEC > > RP03/04 were made by Univac, but they were actually clones of the IBM > > 2314/2316 (only slightly different)]. IIRC we had CDC flavors of them > > which they called the 84x series, and IIRC we had to modify the rp.c driver > > slightly to make them work properly. So I had already learned how to hack > > the disk drivers by then. But I never had access to real manuals for > > any of the DEC peripherals other than the 76 Peripherals Handbook until we > > got one of the first RK07s and the RK611/711 controller. Danny Klein and > > I wrote the first UNIX driver for it, cribbing from the already hacked > > RP04/5/6 driver and reading Dennis' V6 driver manual. I had already been > > doing a small amount of the kernel mods by then, and we had started to > > write fsck(8) as well. But when I saw it (and made my own copy), I thought > > Lions helped me better understand the system than I had before. It > > certainly gave me more confidence about what subsystems I would attack > > (more in a minute). > > > > At some point, but it had to have been after I saw Lions, Ted Kowalski had > > a xerographic copy of the proofs for K&R1 in a binder (which I copied), and > > by late 78 I had obtained a xerographic copy of the "Unix program > > description" doc that Matt referred to (I think I got that from Phil Karn, > > but it might have been Ted). > > > > FWIW: A few years later, my old friend and then colleague at Tektronix, > > Mike Zuhl, made an interesting observation, which I think actually plays > > into your comments about Lions. Zuhl was one of the Purdue EE UNIX folks > > (like the late George Goble and Ward Cunningham). Zuhl said: *"Hacking on > > the Unix kernel is a lot like riding a motorcycle. At first you are scared > > sh*tless that you don't want to screw up. After a while, you get > > confident in your abilities and are willing to try anything. Finally, you > > realize it is really just an incredibly beautiful hack that works in a > > manner like no other, and you start to respect it and those that came > > before you*." > > > > For me, reading Lions was part of my transition in the third phase. He > > explains things I basically knew before at a more macro level. > > > > My thoughts/recollections if it is of any help, > > Clem > > > > † To this day, I still think the 1976 Peripherals Handbook was the best > > one DEC made, and if you are looking at Sixth or Seventh Editions, it is > > really all you need for most of the peripherals they supported. Later > > ones include some information about later products such as the RL01/2 and > > RK06/7, but they dropped many of them outright in some cases, and in others > > the core descriptions are not nearly as detailed/useful. > > > > On Tue, Jul 28, 2026 at 2:41 PM segaloco via TUHS wrote: > > > > > On Tuesday, July 28th, 2026 at 10:14, Will Senn via TUHS > > > wrote: > > > > > > > Lions is great, but today's reader needs more of a leg up. I think it > > > > illustrates how much architectural knowledge his original audience could > > > > take for granted. Nearly fifty years later, recovering that context has > > > > become part of reading the book. So, reading through Lions in 2026 is an > > > > archaeological dig, really :). That said, if you're planning to read > > > > Lions with any depth, be sure to minimally have on hand: > > > > > > > > * Lions Commentary > > > > > > > > * Lions Source Code > > > > > > > > * PDP-11/40 Processor Handbook > > > > > > > > * KT11-D Memory Management Option User Manual > > > > > > > > * Repeatable notes for setting up a working lab > > > > > > > > Later, > > > > > > > > Will > > > > > > > For the record, the intro does indicate what auxiliary knowledge may be > > > necessary, pointing the reader to the manual, several papers such as C > > > tutorials and UNIX for Beginners, as well as listing knowledge of the > > > following PDP-11 hardware useful: > > > > > > - PDP11/40 > > > - RK05 > > > - LP11 > > > - PC11 > > > - KL11 > > > > > > You also do get a bit of hardware exposition, albeit not too much, in > > > Chapter 2. > > > > > > This implies having the PDP-11 Peripherals Handbook on hand would also be > > > helpful. Naturally our biases allow us to overlook this, but having both > > > the UNIX Assember Manual and C Reference Manual on hand would be helpful to > > > the uninitiated as those are the two languages at play in the source > > > volume. Not sure how necessary this would be in practice but UNIX is an > > > ASCII system, so non-ASCII-ites, however rare these days, would be going in > > > with some unhelpful biases, but I don't know if that would peg the ASCII > > > standard as required context. I'm a sucker for building complete reference > > > documentation graphs...so I'm going to hold my urge further for now. > > > > > > Still, it would be an interesting exercise to pursue the full graph of > > > primary references needed to establish a normative reference graph for > > > Lions's Commentary. > > > > > > Will, I don't know if this would be a comparable follow-on project, but > > > there is the Program Description document published with USG UNIX that > > > serves as another detailed analysis of the UNIX kernel[1] that may be worth > > > inspecting with a similar lens. By the way, I have a later hardcopy of [1] > > > issued with Program Generic 3. Unfortunately its just a reprint of the > > > Program Generic 2 version and does not include the kernel changes in PG3, > > > but it is complete, so I plan on scanning it in my next round of documents. > > > > > > - Matt G. > > > > > > [1] - unix_program_description_jan_1976.pdf > > >