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