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: <B7527693-E694-4564-AB5B-BE6FABB69612@archibald.dev>
References: <B7527693-E694-4564-AB5B-BE6FABB69612@archibald.dev>
Message-ID: <CAC20D2Puyjdo3X8mVXthZoo3PN2HwHYhc2t6Q0nGZYC0zirJoQ@mail.gmail.com>

below

On Mon, Jun 29, 2026 at 5:12 PM Thalia Archibald via TUHS <tuhs at tuhs.org>
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: <CAC20D2Puyjdo3X8mVXthZoo3PN2HwHYhc2t6Q0nGZYC0zirJoQ@mail.gmail.com>
References: <B7527693-E694-4564-AB5B-BE6FABB69612@archibald.dev>
 <CAC20D2Puyjdo3X8mVXthZoo3PN2HwHYhc2t6Q0nGZYC0zirJoQ@mail.gmail.com>
Message-ID: <a1c7e7ce-8e17-4c51-98a8-01043a229016@bitsavers.org>


>> 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: <ZelBnaNy4M5C77Br6bGdCvvi0UK3ezt8vH1timTo6Ra_p7r71cmRY8zoPc_02fTAvjuwARjmb_tMPyQq1M4eNfDnOfJnNpGZ1jAjSl1l0xA=@protonmail.com>
References: <ZelBnaNy4M5C77Br6bGdCvvi0UK3ezt8vH1timTo6Ra_p7r71cmRY8zoPc_02fTAvjuwARjmb_tMPyQq1M4eNfDnOfJnNpGZ1jAjSl1l0xA=@protonmail.com>
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: <CAKH6PiXHqaKxGbpHBRnoGi4CQVO2h=DOod333kuUDeOofQoXbQ@mail.gmail.com>
References: <CAKH6PiXHqaKxGbpHBRnoGi4CQVO2h=DOod333kuUDeOofQoXbQ@mail.gmail.com>
Message-ID: <CAKzdPgwgMiOv_Z6kXZncVo7vfTxf4zSviySwhg-aVbKN8vH3qQ@mail.gmail.com>

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: <EA0F1E2B2211C5E85E0C0710E33F0185@gaff.inri.net>

> 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: <ZelBnaNy4M5C77Br6bGdCvvi0UK3ezt8vH1timTo6Ra_p7r71cmRY8zoPc_02fTAvjuwARjmb_tMPyQq1M4eNfDnOfJnNpGZ1jAjSl1l0xA=@protonmail.com>
References: <ZelBnaNy4M5C77Br6bGdCvvi0UK3ezt8vH1timTo6Ra_p7r71cmRY8zoPc_02fTAvjuwARjmb_tMPyQq1M4eNfDnOfJnNpGZ1jAjSl1l0xA=@protonmail.com>
Message-ID: <_ZPnpqeXOG-z90KK54srYeB-L0MtGjnxiU7Iiv4rFIMENi1T7xASQD93Fp9FezjQsLqENcKsm6DB3aAwlMtdLE8kSNxrhvGVJ5MxbU3La6I=@protonmail.com>

On Monday, June 29th, 2026 at 18:35, segaloco via TUHS <tuhs at tuhs.org> 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: <E1wgiUi-00000001HAf-2ugB@gleep.local>

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: <E1wgiUi-00000001HAf-2ugB@gleep.local>
References: <E1wgiUi-00000001HAf-2ugB@gleep.local>
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 <tuhs at tuhs.org> 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: <E1wgiUi-00000001HAf-2ugB@gleep.local>
References: <E1wgiUi-00000001HAf-2ugB@gleep.local>
Message-ID: <aku1BAbdKF6LMvjo@largo.jsg.id.au>

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: <E1wgiUi-00000001HAf-2ugB@gleep.local>
References: <E1wgiUi-00000001HAf-2ugB@gleep.local>
Message-ID: <CAC20D2PyYTyNcGgEQ0aYjRL1Q4ng5zM_7GP8ErTQs-X6VdiZAA@mail.gmail.com>

Thank you.


Sent from a handheld expect more typos than usual

On Mon, Jul 6, 2026 at 8:32 AM Aharon Robbins via TUHS <tuhs at tuhs.org>
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: <aku1BAbdKF6LMvjo@largo.jsg.id.au>
References: <E1wgiUi-00000001HAf-2ugB@gleep.local>
 <aku1BAbdKF6LMvjo@largo.jsg.id.au>
Message-ID: <202607061409.666E9gZ9007463@freefriends.org>

Jonathan Gray <jsg at jsg.id.au> 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: <E1wgiUi-00000001HAf-2ugB@gleep.local>
 <202607061342.666DglvX005321@freefriends.org>
Message-ID: <akxDeiNAOK7KoKuy@hydra.lemis.com>

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: <http://www.tuhs.org/pipermail/tuhs/attachments/20260707/f368c0d6/attachment.sig>

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: <E1wgiUi-00000001HAf-2ugB@gleep.local>
 <aku1BAbdKF6LMvjo@largo.jsg.id.au>
 <202607061409.666E9gZ9007463@freefriends.org>
Message-ID: <CAKzdPgzwZYTHTpjYESU+w6bUQr4AVO1YBLthQXZdoDmmQHsLAQ@mail.gmail.com>

No idea, sorry.

It was a while ago.

-rob


On Tue, Jul 7, 2026 at 12:19 AM Arnold Robbins via TUHS <tuhs at tuhs.org>
wrote:

> Jonathan Gray <jsg at jsg.id.au> 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: <CAKzdPgzwZYTHTpjYESU+w6bUQr4AVO1YBLthQXZdoDmmQHsLAQ@mail.gmail.com>
References: <E1wgiUi-00000001HAf-2ugB@gleep.local>
 <aku1BAbdKF6LMvjo@largo.jsg.id.au>
 <202607061409.666E9gZ9007463@freefriends.org>
 <CAKzdPgzwZYTHTpjYESU+w6bUQr4AVO1YBLthQXZdoDmmQHsLAQ@mail.gmail.com>
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 <robpike at gmail.com> wrote:

> No idea, sorry.
>
> It was a while ago.
>
> -rob
>
>
> On Tue, Jul 7, 2026 at 12:19 AM Arnold Robbins via TUHS <tuhs at tuhs.org>
> wrote:
>
> > Jonathan Gray <jsg at jsg.id.au> 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: <E1wgiUi-00000001HAf-2ugB@gleep.local>
References: <E1wgiUi-00000001HAf-2ugB@gleep.local>
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: <http://www.tuhs.org/pipermail/tuhs/attachments/20260707/52b78eb1/attachment.sig>

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: <akxDeiNAOK7KoKuy@hydra.lemis.com>
References: <E1wgiUi-00000001HAf-2ugB@gleep.local>
 <202607061342.666DglvX005321@freefriends.org>
 <akxDeiNAOK7KoKuy@hydra.lemis.com>
Message-ID: <202607070605.66765kHe084278@freefriends.org>

No worries. Thanks.

"Greg 'groggy' Lehey" <grog at lemis.com> 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: <E1wgiUi-00000001HAf-2ugB@gleep.local>
 <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" <tuhs at tuhs.org> 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: <em6f15fe67-c685-447d-bc30-dd89e5c6f5aa@ronnatalie.com>

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" <tuhs at tuhs.org>
To arnold at skeeve.com; "Arnold Robbins via TUHS" <tuhs at tuhs.org>
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: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>

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: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
References: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
Message-ID: <CANxB0bRrN-J9S_uCxoH6CNqnXYN=6Qc1rY8MoUhMxgVeSV3u1Q@mail.gmail.com>

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 <tuhs at tuhs.org> 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: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
References: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
Message-ID: <alHA4V8GLt7vik0v@minnie.tuhs.org>

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: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>

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: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
References: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
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: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
References: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
Message-ID: <20260712192727.42ED61154C11E@ary.qy>

It appears that Tom Lyon via TUHS <pugs78 at gmail.com> 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: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
 <20260712192727.42ED61154C11E@ary.qy>
Message-ID: <emdc4bca75-9a3f-499d-b12f-ef90cdcab99c@ronnatalie.com>


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: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
 <20260712192727.42ED61154C11E@ary.qy>
Message-ID: <CANxB0bQLnWqyx1nvGG+nF86YkDd8EETLhFEJ6ZEWtzevTi3UEw@mail.gmail.com>

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 <johnl at taugh.com> wrote:

> It appears that Tom Lyon via TUHS <pugs78 at gmail.com> 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: <CAC20D2M6JRKiFjvBBCnQ_pajDLPz+DPHMFQtL5ujv6ipnUEC0Q@mail.gmail.com>
References: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
 <20260712192727.42ED61154C11E@ary.qy>
 <CAC20D2M6JRKiFjvBBCnQ_pajDLPz+DPHMFQtL5ujv6ipnUEC0Q@mail.gmail.com>
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: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
 <20260712192727.42ED61154C11E@ary.qy>
Message-ID: <CAC20D2M6JRKiFjvBBCnQ_pajDLPz+DPHMFQtL5ujv6ipnUEC0Q@mail.gmail.com>

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 <tuhs at tuhs.org> wrote:

> It appears that Tom Lyon via TUHS <pugs78 at gmail.com> 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: <CAC20D2M6JRKiFjvBBCnQ_pajDLPz+DPHMFQtL5ujv6ipnUEC0Q@mail.gmail.com>
References: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
 <20260712192727.42ED61154C11E@ary.qy>
 <CAC20D2M6JRKiFjvBBCnQ_pajDLPz+DPHMFQtL5ujv6ipnUEC0Q@mail.gmail.com>
Message-ID: <c8ee3b09-5a2a-48cf-b2f8-556e73ea9b42@insinga.com>

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<tuhs at tuhs.org> wrote:
>
>> It appears that Tom Lyon via TUHS<pugs78 at gmail.com> 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: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
References: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
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 <https://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: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
 <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 <https://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: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
References: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
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 <tuhs at tuhs.org> 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: <wpQ25MbUqCSuKzYuTucImTUHf10vDGkWqusGSbSgl7GSWaeg3xpk3--n_ydE_CxDkDkEe5y3KVn8p1U_XYk9vdtSEq65Ha1UEfcM3QYqqRI=@protonmail.com>
 <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: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
References: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
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: <http://www.tuhs.org/pipermail/tuhs/attachments/20260717/f63b76e5/attachment.sig>

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: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
 <20260717185339.3m2ch64ohx24i2fg@illithid>
Message-ID: <CANxB0bRpvQS=M1sgaDtxJuw6Xhu3pMO6a9dUvN3V9eu86zHm+g@mail.gmail.com>

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: <CANxB0bRpvQS=M1sgaDtxJuw6Xhu3pMO6a9dUvN3V9eu86zHm+g@mail.gmail.com>
References: <CANxB0bS4bwJHhqAUXsTrs3o8Ak=_nn=YU836qh6YxUe3Qcgj1g@mail.gmail.com>
 <20260717185339.3m2ch64ohx24i2fg@illithid>
 <CANxB0bRpvQS=M1sgaDtxJuw6Xhu3pMO6a9dUvN3V9eu86zHm+g@mail.gmail.com>
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: <http://www.tuhs.org/pipermail/tuhs/attachments/20260717/88f3ec6a/attachment-0001.sig>

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: <S6D41xAXI-hZizeGmhNdxGFWQO7MOMmRJzwhVyH-FFJEHwHjb_WKb-fNk-ipSY5QQpEf43Kranvo9WwJuE-qHqgbCmas2WiY5G-joN9ANxs=@protonmail.com>

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: <S6D41xAXI-hZizeGmhNdxGFWQO7MOMmRJzwhVyH-FFJEHwHjb_WKb-fNk-ipSY5QQpEf43Kranvo9WwJuE-qHqgbCmas2WiY5G-joN9ANxs=@protonmail.com>
References: <S6D41xAXI-hZizeGmhNdxGFWQO7MOMmRJzwhVyH-FFJEHwHjb_WKb-fNk-ipSY5QQpEf43Kranvo9WwJuE-qHqgbCmas2WiY5G-joN9ANxs=@protonmail.com>
Message-ID: <alygJzVmKNjkEtnk@largo.jsg.id.au>

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: <alygJzVmKNjkEtnk@largo.jsg.id.au>
References: <S6D41xAXI-hZizeGmhNdxGFWQO7MOMmRJzwhVyH-FFJEHwHjb_WKb-fNk-ipSY5QQpEf43Kranvo9WwJuE-qHqgbCmas2WiY5G-joN9ANxs=@protonmail.com>
 <alygJzVmKNjkEtnk@largo.jsg.id.au>
Message-ID: <C0AjWyhl6C-H7pXjpRgmD6gk0tkklmJ2cOMSGPNFSyFSbCHXdT6xpw8ZctuQ9w47M0m9qZjLjSctqjATNdBy_AzQkc-cMg7bJdfTQeu0Wxc=@protonmail.com>

On Sunday, July 19th, 2026 at 03:00, Jonathan Gray via TUHS <tuhs at tuhs.org> 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: <E1wmC47-00000000aFE-33Ht@gleep.local>

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: <cqm2ig8hq__2fjG_vrZT5D4T36FeWRTIvpM42APnIvAA7MBbXA_uMdESo2m6d7QQdJfH06n-MzTe82XOB94sJym49gWc8SVYCw0MfCt-Sa4=@protonmail.com>

On Tuesday, July 21st, 2026 at 12:34, David Barto via TUHS <tuhs at tuhs.org> 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: <E1wmTnN-00000000m8p-3Eaz@gleep.local>

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: <E1wmTnN-00000000m8p-3Eaz@gleep.local>
References: <E1wmTnN-00000000m8p-3Eaz@gleep.local>
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: <http://www.tuhs.org/pipermail/tuhs/attachments/20260722/33de19f5/attachment.sig>

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: <E1wmTnN-00000000m8p-3Eaz@gleep.local>
 <1d0d6f3f-8e8b-4126-b3ff-7b2770df9bf3@dorfdsl.de>
Message-ID: <202607221056.66MAuuE6008335@freefriends.org>

Marco Moock via TUHS <tuhs at tuhs.org> 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

