From wkt at tuhs.org  Thu Apr  2 21:54:08 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 02 Apr 2020 21:54:08 +1000
Subject: [TUHS] Stdio and ABIs
Message-ID: <BDEF0506-BD72-45D2-9FF1-827D4441F5BA@tuhs.org>

https://fingolfin.org/blog/20200327/stdio-abi.html

An interesting look at the history of stdio and subsequent ABI choices.

Cheers, Warren
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200402/6536e0c0/attachment.html>

From pnr at planet.nl  Sat Apr  4 04:33:15 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 3 Apr 2020 20:33:15 +0200
Subject: [TUHS] Research PBX legacy
Message-ID: <1088CB8E-C53F-474B-9831-9890F75E5882@planet.nl>

About a year ago the Research telephone switch came up on this list.

Rob Pike wrote:

"But the PBX story is correct. To demonstrate how message passing was a good
model for a switching system, in particular to make a point to the
switching systems division of Bell Labs/AT&T, Ken and Joe bought a
commercial PBX and swapped out its processor for a PDP-11/23 (I think), and
programmed it up. It was just before I arrived there but I was given the
impression it had the desired strategic influence on Indian Hill.

The feature we all loved it for was that instead of ringing the phone in
the Unix room when you got a call, it would announce your name through the
voice synthesizer: "Phone call for Ken." "Phone call for Joe". One rapidly
stopped even hearing the announcement if it didn't end with your name.”

I’ve been having an off list discussion with Bill Marshall and this PBX was influential in another way as well.

First of all, Bill can confirm that it indeed was a 11/23, the same racks were used for Datakit switches. He also remembered that the software for this PDP-11 went by the nickname of “TPC” - for Tiny Phone Company. Lee McMahon was on the team writing TPC.

The first software for the Datakit switch was written by Greg Chesson and was called “CMC” (for ‘Common Control’). There are still some references to CMC in the 8th Edition source code.

This first software was later replaced by new code designed by Lee McMahon that was modelled after TPC. This new code was named “TDK”. This, too, can be seen in the 8th Edition source. The TDK protocols for building and releasing a Datakit virtual circuit appear to have been in use into the 1990’s.


From doug at cs.dartmouth.edu  Sat Apr  4 13:14:16 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 03 Apr 2020 23:14:16 -0400
Subject: [TUHS] Research PBX legacy
Message-ID: <202004040314.0343EGgH068467@tahoe.cs.Dartmouth.EDU>

Prologue to TPC. Bob Morris did a visiting-researcher stint at
AT&T, where he became aware of infelicitous software architure
proposed for ESS 5. He thought Research could do it better. Ken,
Joe, and Lee bit. Lee's architecture was indeed novel: every
device in the system, right down to each touch-tone button, was
modeled as a process.  Only after the clean model was working
were some processes--notably the buttons--jammed together to
cinch in the process table.


The team got the switch working in a matter of months--in time
to demonstrate it to Indian Hill before ESS was irrevocably
set in stone. ESS architecture was indeed rethought, taking
some ideas from TPC.

TPC was named after "TPC, The Phone Company" in the 1967 film,
"The President's Analyst".

Doug

From emu at e-bbes.com  Sat Apr  4 22:56:14 2020
From: emu at e-bbes.com (emanuel stiebler)
Date: Sat, 4 Apr 2020 08:56:14 -0400
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <CAKzdPgzQaZq4xFuPXrV9s2iXT1EE0eLtzeaUWe=Mjo=gD-=DFQ@mail.gmail.com>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
 <CAKzdPgwDJMOc8j-g4QbGLXKGK4OB3ttFtvRn7WpDD=d=D78LvA@mail.gmail.com>
 <A50FD32A-A0C6-4068-BB20-8358B341EC2D@planet.nl>
 <CAKzdPgzQaZq4xFuPXrV9s2iXT1EE0eLtzeaUWe=Mjo=gD-=DFQ@mail.gmail.com>
Message-ID: <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com>

On 2020-03-30 05:06, Rob Pike wrote:
> I've looked through my notes and unfortunately there's very little
> about this as the notes are mostly about graphics and physics.

I wouldn't mind seeing the note baout graphics, even if not on topic for
this group ...

From meillo at marmaro.de  Sun Apr  5 01:05:26 2020
From: meillo at marmaro.de (markus schnalke)
Date: Sat, 04 Apr 2020 17:05:26 +0200
Subject: [TUHS] First book on Unix for general readership
Message-ID: <1jKkMQ-2hN-00@marmaro.de>

Hoi,

found on Wikipedia:

	As well as the Bourne shell, he wrote the adb debugger
	and The UNIX System, the second book on the UNIX system,
	intended for a general readership.

https://en.wikipedia.org/wiki/Stephen_R._Bourne

Thus I now wonder what the first book on Unix, intended for a
general readership was.

Bourne's book was published 1983.

(``The UNIX Programming Environment'' was published 1984.)


Was it Banahan and Rutter's ``UNIX -- the Book''? It says 1982.

Could anyone share some background on that one? (The authors were
from Bradford University.)

I only have the German translation by Axel T. Schreiner, dated
1984. Haven't read the English original, but Schreiner's version
definitely is worth to read (if you speak German). He added lots
of footnotes, and it becomes apparent that he knows the system
better than the authors. ;-)


I'd like to get an understanding of the books in relation to each
other. How does the Banahan/Rutter book fit into the picture? Why
didn't Bell Labs write a user's book earlier? Were Bourne's and
Kernighan/Pike's books reactions to it?


meillo

From cym224 at gmail.com  Sun Apr  5 01:48:15 2020
From: cym224 at gmail.com (Nemo Nusquam)
Date: Sat, 4 Apr 2020 11:48:15 -0400
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <1jKkMQ-2hN-00@marmaro.de>
References: <1jKkMQ-2hN-00@marmaro.de>
Message-ID: <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com>

On 04/04/20 11:05, markus schnalke wrote (in part):
> Thus I now wonder what the first book on Unix, intended for a general 
> readership was.
Not to be overly pedantic but what would be a "general readership"?

For example, I understand that the patent dep't was an early Unix 
customer.  Would they been a general readership (and how were they taught)?

(I would think that many of today's grunt-and-poke UI generation would 
have difficulty with a cli.)

N.

From michael at kjorling.se  Sun Apr  5 02:12:01 2020
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 4 Apr 2020 16:12:01 +0000
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <1jKkMQ-2hN-00@marmaro.de>
References: <1jKkMQ-2hN-00@marmaro.de>
Message-ID: <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>

On 4 Apr 2020 17:05 +0200, from meillo at marmaro.de (markus schnalke):
> found on Wikipedia:
> 
> 	As well as the Bourne shell, he wrote the adb debugger
> 	and The UNIX System, the second book on the UNIX system,
> 	intended for a general readership.
> 
> https://en.wikipedia.org/wiki/Stephen_R._Bourne
> 
> Thus I now wonder what the first book on Unix, intended for a
> general readership was.

I would be careful with that claim.

First, it appears to lack a citation. (Someone here might be able to help
with that.)

Second, once you unpack it, the claim itself can be parsed in two ways,
yielding quite different meanings.

One way of parsing the claim is that Bourne wrote the book _The UNIX
System_ which was the second book on the UNIX system. It was also a book
which was intended for a general readership, presumably thereby setting it
apart from the first book which was not intended for a general readership.

The other way of parsing the claim is that he wrote the book _The UNIX
System_ which was second in the set of intended-for-a-general-readership
books on the UNIX system (as opposed to the set of books on the UNIX
system which were intended for other than a general readership, or for
_any_ readership, of which there may have been any number prior to this
book), thereby setting it apart only from the first book on the UNIX
system intended for a general readership.

I'm not a good enough UNIX historian to know which meaning is correct.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


From meillo at marmaro.de  Sun Apr  5 02:45:30 2020
From: meillo at marmaro.de (markus schnalke)
Date: Sat, 04 Apr 2020 18:45:30 +0200
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
Message-ID: <1jKlvG-4JB-00@marmaro.de>

Hoi.

[2020-04-04 16:12] Michael Kjörling <michael at kjorling.se>
> On 4 Apr 2020 17:05 +0200, from meillo at marmaro.de (markus schnalke):
> > found on Wikipedia:
> > 
> > 	As well as the Bourne shell, he wrote the adb debugger
> > 	and The UNIX System, the second book on the UNIX system,
> > 	intended for a general readership.
> > 
> > https://en.wikipedia.org/wiki/Stephen_R._Bourne
> > 
> > Thus I now wonder what the first book on Unix, intended for a
> > general readership was.
> 
> I would be careful with that claim.
> 
> First, it appears to lack a citation. (Someone here might be able to help
> with that.)

That was my thought already. I hope to get a citation out of this
mail thread, or information to remove this claim.

But that was only what started my interest in the situation around
the very first Unix books. Especially the Banahan/Rutter book
caught my interest, as I cannot really fit it into the picture of
my current understanding. (I've never read (or forgot) about the
University of Bredford in the early Unix context.)


> Second, once you unpack it, the claim itself can be parsed in two ways,
> yielding quite different meanings.

You're right. I directly assumed that ``the second book that was
intended for genereal readership (besides several earlier books
for special readership)'' was meant. But now that you bring this
question up, I'm no longer sure about earlier books that describe
the Unix system in general, not only single aspects of it.
Besides, we quickly run into the question what a book is. Is
Lions' Book a book? Are the manuals books?

Well, as I wrote above, although this claim in the Wikipedia
started it all up for me, I'm not so much interested in validating
or falsifying it, but rather like to know more about the situation
in general, to further improve my understanding of the time back
then. :-)


meillo

From imp at bsdimp.com  Sun Apr  5 03:32:17 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 4 Apr 2020 11:32:17 -0600
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <1jKkMQ-2hN-00@marmaro.de>
References: <1jKkMQ-2hN-00@marmaro.de>
Message-ID: <CANCZdfqhi_Eb4zcJ3bDZCamh76UK1PYWZRNoBA+b+rbvLC=qsw@mail.gmail.com>

On Sat, Apr 4, 2020, 9:19 AM markus schnalke <meillo at marmaro.de> wrote:

> Hoi,
>
> found on Wikipedia:
>
>         As well as the Bourne shell, he wrote the adb debugger
>         and The UNIX System, the second book on the UNIX system,
>         intended for a general readership.
>
> https://en.wikipedia.org/wiki/Stephen_R._Bourne
>
> Thus I now wonder what the first book on Unix, intended for a
> general readership was.
>
> Bourne's book was published 1983.
>
> (``The UNIX Programming Environment'' was published 1984.)
>
>
> Was it Banahan and Rutter's ``UNIX -- the Book''? It says 1982.
>
> Could anyone share some background on that one? (The authors were
> from Bradford University.)
>
> I only have the German translation by Axel T. Schreiner, dated
> 1984. Haven't read the English original, but Schreiner's version
> definitely is worth to read (if you speak German). He added lots
> of footnotes, and it becomes apparent that he knows the system
> better than the authors. ;-)
>
>
> I'd like to get an understanding of the books in relation to each
> other. How does the Banahan/Rutter book fit into the picture? Why
> didn't Bell Labs write a user's book earlier? Were Bourne's and
> Kernighan/Pike's books reactions to it?
>

All good questions. I just bought both of these 9n ebay (there are several
copies available for <$10 so I didn't feel bad about sniping a rarity from
others in this group).

But I don't know the back stories.

Warner


> meillo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200404/e82774b4/attachment.html>

From noel.hunt at gmail.com  Sun Apr  5 05:57:12 2020
From: noel.hunt at gmail.com (Noel Hunt)
Date: Sun, 5 Apr 2020 05:57:12 +1000
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
 <CAKzdPgwDJMOc8j-g4QbGLXKGK4OB3ttFtvRn7WpDD=d=D78LvA@mail.gmail.com>
 <A50FD32A-A0C6-4068-BB20-8358B341EC2D@planet.nl>
 <CAKzdPgzQaZq4xFuPXrV9s2iXT1EE0eLtzeaUWe=Mjo=gD-=DFQ@mail.gmail.com>
 <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com>
Message-ID: <CAGfO01zw9G+xK_9DmG6usvjeNdTxv1ZO3rpyQ52HVhfsxqnd=g@mail.gmail.com>

I would be interested too. That was a seminal time with the
proliferation of graphical programs, such as jim, pads/pi,
proof, the sophisticated menus of 'mhit.c' etc. It is curious
that little if any of that code made the transition to Plan9
(apart from sam, nee jim).


On Sun, Apr 5, 2020 at 12:19 AM emanuel stiebler <emu at e-bbes.com> wrote:

> On 2020-03-30 05:06, Rob Pike wrote:
> > I've looked through my notes and unfortunately there's very little
> > about this as the notes are mostly about graphics and physics.
>
> I wouldn't mind seeing the note baout graphics, even if not on topic for
> this group ...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200405/4e41b994/attachment.html>

From robpike at gmail.com  Sun Apr  5 07:32:22 2020
From: robpike at gmail.com (Rob Pike)
Date: Sun, 5 Apr 2020 07:32:22 +1000
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <CAGfO01zw9G+xK_9DmG6usvjeNdTxv1ZO3rpyQ52HVhfsxqnd=g@mail.gmail.com>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
 <CAKzdPgwDJMOc8j-g4QbGLXKGK4OB3ttFtvRn7WpDD=d=D78LvA@mail.gmail.com>
 <A50FD32A-A0C6-4068-BB20-8358B341EC2D@planet.nl>
 <CAKzdPgzQaZq4xFuPXrV9s2iXT1EE0eLtzeaUWe=Mjo=gD-=DFQ@mail.gmail.com>
 <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com>
 <CAGfO01zw9G+xK_9DmG6usvjeNdTxv1ZO3rpyQ52HVhfsxqnd=g@mail.gmail.com>
Message-ID: <CAKzdPgzc+X_x2-yTYshmCcxv3LF4N+nNfWtgfyr38fWbaWw53w@mail.gmail.com>

Sam wasn't nee jim. Jim was a toy, sam is a serious editor.

My notebooks are hundreds of pages of figuring stuff out. Perhaps
valuable information to historians, but not easily compressed for this
forum.

-rob

On Sun, Apr 5, 2020 at 5:57 AM Noel Hunt <noel.hunt at gmail.com> wrote:
>
> I would be interested too. That was a seminal time with the
> proliferation of graphical programs, such as jim, pads/pi,
> proof, the sophisticated menus of 'mhit.c' etc. It is curious
> that little if any of that code made the transition to Plan9
> (apart from sam, nee jim).
>
>
> On Sun, Apr 5, 2020 at 12:19 AM emanuel stiebler <emu at e-bbes.com> wrote:
>>
>> On 2020-03-30 05:06, Rob Pike wrote:
>> > I've looked through my notes and unfortunately there's very little
>> > about this as the notes are mostly about graphics and physics.
>>
>> I wouldn't mind seeing the note baout graphics, even if not on topic for
>> this group ...

From noel.hunt at gmail.com  Sun Apr  5 08:39:28 2020
From: noel.hunt at gmail.com (Noel Hunt)
Date: Sun, 5 Apr 2020 08:39:28 +1000
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <CAKzdPgzc+X_x2-yTYshmCcxv3LF4N+nNfWtgfyr38fWbaWw53w@mail.gmail.com>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
 <CAKzdPgwDJMOc8j-g4QbGLXKGK4OB3ttFtvRn7WpDD=d=D78LvA@mail.gmail.com>
 <A50FD32A-A0C6-4068-BB20-8358B341EC2D@planet.nl>
 <CAKzdPgzQaZq4xFuPXrV9s2iXT1EE0eLtzeaUWe=Mjo=gD-=DFQ@mail.gmail.com>
 <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com>
 <CAGfO01zw9G+xK_9DmG6usvjeNdTxv1ZO3rpyQ52HVhfsxqnd=g@mail.gmail.com>
 <CAKzdPgzc+X_x2-yTYshmCcxv3LF4N+nNfWtgfyr38fWbaWw53w@mail.gmail.com>
Message-ID: <CAGfO01y1hj2B1fsZ3SKVYm41mpCY5v+7AVPnxFXBHodqqrpEvg@mail.gmail.com>

> Sam wasn't nee jim. Jim was a toy, sam is a serious editor.

I don't doubt that, as a long-time user of sam (and jim
initially, 30 or so years ago), but it is interesting to
see the gradual sophistication of, say, the frame library
presumably in response to changes in hardware, and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200405/626b563b/attachment.html>

From doug at cs.dartmouth.edu  Sun Apr  5 08:41:31 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 04 Apr 2020 18:41:31 -0400
Subject: [TUHS] First book on Unix for general readership
Message-ID: <202004042241.034MfVJd020049@tahoe.cs.Dartmouth.EDU>

Another book from the same era--quite good--is A Unix Primer
by Ann Nichols Lomuto and Nico Lomuto, copyright 1983.

Before the title page appears an interesting endorsement:
"Prentice-Hall Software Series, Brian Kernighan, advisor

Doug

From imp at bsdimp.com  Sun Apr  5 10:53:52 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 4 Apr 2020 18:53:52 -0600
Subject: [TUHS] Xenix-11 Images
Message-ID: <CANCZdfroOY3Zq9c9q+D3MY0oKku8hO3pjS8AvCJ8GOiUgaM1fQ@mail.gmail.com>

Crazy longshot post, part 27 in an infinite series

Are there any Xenix-11 images (boot tapes or disk images) around? My
googling skillz aren't mad enough to find this.

I've seen the Xenix 86 image in the archive that was copied from pce's
image warehouse which is cool and the generation of code I'm looking for,
but is for 8086 machines...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200404/dc56ec88/attachment.html>

From aksr at t-com.me  Sun Apr  5 11:38:21 2020
From: aksr at t-com.me (aksr)
Date: Sun, 5 Apr 2020 03:38:21 +0200
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <CAKzdPgzc+X_x2-yTYshmCcxv3LF4N+nNfWtgfyr38fWbaWw53w@mail.gmail.com>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
 <CAKzdPgwDJMOc8j-g4QbGLXKGK4OB3ttFtvRn7WpDD=d=D78LvA@mail.gmail.com>
 <A50FD32A-A0C6-4068-BB20-8358B341EC2D@planet.nl>
 <CAKzdPgzQaZq4xFuPXrV9s2iXT1EE0eLtzeaUWe=Mjo=gD-=DFQ@mail.gmail.com>
 <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com>
 <CAGfO01zw9G+xK_9DmG6usvjeNdTxv1ZO3rpyQ52HVhfsxqnd=g@mail.gmail.com>
 <CAKzdPgzc+X_x2-yTYshmCcxv3LF4N+nNfWtgfyr38fWbaWw53w@mail.gmail.com>
Message-ID: <20200405013821.GA716137@lap>

On Sun, Apr 05, 2020 at 07:32:22AM +1000, Rob Pike wrote:
> Sam wasn't nee jim. Jim was a toy, sam is a serious editor.
>
> My notebooks are hundreds of pages of figuring stuff out. Perhaps
> valuable information to historians, but not easily compressed for this
> forum.

I think this info would be more than interesting.

Maybe if and when you have the time,
you could compress this (at least for your blog)?

From nw at retrocomputingtasmania.com  Sun Apr  5 12:19:54 2020
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Sun, 5 Apr 2020 12:19:54 +1000
Subject: [TUHS] Xenix-11 Images
In-Reply-To: <CANCZdfroOY3Zq9c9q+D3MY0oKku8hO3pjS8AvCJ8GOiUgaM1fQ@mail.gmail.com>
References: <CANCZdfroOY3Zq9c9q+D3MY0oKku8hO3pjS8AvCJ8GOiUgaM1fQ@mail.gmail.com>
Message-ID: <CACCFpdz4Cpiw3rdCJUfPHuf9rN_svMMnUDxLJRct7umSqmkhRw@mail.gmail.com>

On Sun, Apr 5, 2020 at 10:55 AM Warner Losh <imp at bsdimp.com> wrote:
> Crazy longshot post, part 27 in an infinite series

Xenix-11 would be good to track down, for those that need a reminder
here is an advert for it:

http://bitsavers.org/pdf/apple/lisa/xenix/brochures/PDP-11_Xenix_Brochure_Aug84.jpg

relevant text from advert:

"XENIS SYSTEM FOR THE PDP-11 AND LSI-11 FAMILIES"
"COMPLETE OPERATING SYSTEM PACKAGES LICENSED UNDER AT&T'S UNIX SYSTEM III"

"Our XENIX system is real UNIX with such commercial enhancements as
file and record locking, greater reliability, and improved system
administration facilities. A unique memory overlay method enables
complete UNIX performance on the LSI-11/23. The new LSI-11/73
processor is also fully supported. (For VAX users, 4.2 bsd virtual
memory UNIX is available.)"

and

"The Santa Cruz Operation has XENIX available on many popular personal
computers including the IBM Personal Computer, the Apple Lisa and the
DEC Professional 350."

SCO Xenix System V 2.1.3 exists for IBM PC (5160)
SCO Xenix 3.0 Rel 1.0 exists for Apple Lisa

Someone in the DEC Pro 350/380 collector community may have a copy of XENIX.

From nw at retrocomputingtasmania.com  Sun Apr  5 15:13:22 2020
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Sun, 5 Apr 2020 15:13:22 +1000
Subject: [TUHS] Xenix-11 Images
In-Reply-To: <CACCFpdz4Cpiw3rdCJUfPHuf9rN_svMMnUDxLJRct7umSqmkhRw@mail.gmail.com>
References: <CANCZdfroOY3Zq9c9q+D3MY0oKku8hO3pjS8AvCJ8GOiUgaM1fQ@mail.gmail.com>
 <CACCFpdz4Cpiw3rdCJUfPHuf9rN_svMMnUDxLJRct7umSqmkhRw@mail.gmail.com>
Message-ID: <CACCFpdya+epp+b2Gw9we6EVxgZPGaPSqO7h3QCTCR3p7hj1byg@mail.gmail.com>

LCM this weekend had a demo of their "Miss Piggy" 11/70 running Unix
v7 (apparently Microsoft's original development machine?) and it
occurred to me to have a quick look at the LCM archive and found this:

https://opac.libraryworld.com/opac/catalog_edit.php?catalog_id=671443&from_doc=standard.php&position=68

[XENIX] Tests basic.pdp 11 util / February 14, 1982.
1 9 track tape with handwritten label.

I wonder what that is? If anyone is going to have XENIX material I
would expect LCM to be a potential source for it.

From imp at bsdimp.com  Sun Apr  5 15:38:24 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 4 Apr 2020 23:38:24 -0600
Subject: [TUHS] Xenix-11 Images
In-Reply-To: <CACCFpdya+epp+b2Gw9we6EVxgZPGaPSqO7h3QCTCR3p7hj1byg@mail.gmail.com>
References: <CANCZdfroOY3Zq9c9q+D3MY0oKku8hO3pjS8AvCJ8GOiUgaM1fQ@mail.gmail.com>
 <CACCFpdz4Cpiw3rdCJUfPHuf9rN_svMMnUDxLJRct7umSqmkhRw@mail.gmail.com>
 <CACCFpdya+epp+b2Gw9we6EVxgZPGaPSqO7h3QCTCR3p7hj1byg@mail.gmail.com>
Message-ID: <CANCZdfpM9hBOjKuTbD6x9O001W6ApoSAR8zsMsJfgnuELxJNUw@mail.gmail.com>

On Sat, Apr 4, 2020 at 11:14 PM Nigel Williams <
nw at retrocomputingtasmania.com> wrote:

> LCM this weekend had a demo of their "Miss Piggy" 11/70 running Unix
> v7 (apparently Microsoft's original development machine?) and it
> occurred to me to have a quick look at the LCM archive and found this:
>
>
> https://opac.libraryworld.com/opac/catalog_edit.php?catalog_id=671443&from_doc=standard.php&position=68
>
> [XENIX] Tests basic.pdp 11 util / February 14, 1982.
> 1 9 track tape with handwritten label.
>
> I wonder what that is? If anyone is going to have XENIX material I
> would expect LCM to be a potential source for it.
>

I saw that live today... They mentioned they were looking for Xenix-11 to
try to run on misspiggy :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200404/7e935ab0/attachment.html>

From emu at e-bbes.com  Sun Apr  5 23:17:30 2020
From: emu at e-bbes.com (emanuel stiebler)
Date: Sun, 5 Apr 2020 09:17:30 -0400
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <CAKzdPgzc+X_x2-yTYshmCcxv3LF4N+nNfWtgfyr38fWbaWw53w@mail.gmail.com>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
 <CAKzdPgwDJMOc8j-g4QbGLXKGK4OB3ttFtvRn7WpDD=d=D78LvA@mail.gmail.com>
 <A50FD32A-A0C6-4068-BB20-8358B341EC2D@planet.nl>
 <CAKzdPgzQaZq4xFuPXrV9s2iXT1EE0eLtzeaUWe=Mjo=gD-=DFQ@mail.gmail.com>
 <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com>
 <CAGfO01zw9G+xK_9DmG6usvjeNdTxv1ZO3rpyQ52HVhfsxqnd=g@mail.gmail.com>
 <CAKzdPgzc+X_x2-yTYshmCcxv3LF4N+nNfWtgfyr38fWbaWw53w@mail.gmail.com>
Message-ID: <89080e46-0c50-9ff3-ed2c-43beefd8cd96@e-bbes.com>

On 2020-04-04 17:32, Rob Pike wrote:
> Sam wasn't nee jim. Jim was a toy, sam is a serious editor.
> 
> My notebooks are hundreds of pages of figuring stuff out. Perhaps
> valuable information to historians, but not easily compressed for this
> forum.

If you need anybody with a scanner an patience, please tell me ;-)

> -rob
> 
> On Sun, Apr 5, 2020 at 5:57 AM Noel Hunt <noel.hunt at gmail.com> wrote:
>>
>> I would be interested too. That was a seminal time with the
>> proliferation of graphical programs, such as jim, pads/pi,
>> proof, the sophisticated menus of 'mhit.c' etc. It is curious
>> that little if any of that code made the transition to Plan9
>> (apart from sam, nee jim).
>>
>>
>> On Sun, Apr 5, 2020 at 12:19 AM emanuel stiebler <emu at e-bbes.com> wrote:
>>>
>>> On 2020-03-30 05:06, Rob Pike wrote:
>>>> I've looked through my notes and unfortunately there's very little
>>>> about this as the notes are mostly about graphics and physics.
>>>
>>> I wouldn't mind seeing the note baout graphics, even if not on topic for
>>> this group ...


From ron at ronnatalie.com  Mon Apr  6 09:57:55 2020
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 5 Apr 2020 19:57:55 -0400
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <1jKlvG-4JB-00@marmaro.de>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de>
Message-ID: <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>

The Lions book wasn’t really published back in the day.   It was only targetted at his students in Australia (though copies leaked out).

The manuals aren’t really a book (and again, they weren’t really published as a book) and most of the prose on UNIX was more in the form of articles than an entire book.

From lm at mcvoy.com  Mon Apr  6 10:08:14 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 5 Apr 2020 17:08:14 -0700
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
Message-ID: <20200406000814.GH25105@mcvoy.com>

Do the Bell Labs technical journals count?  I have a collection of Unix
papers that were puled out and published together in two volumes.  That
stuff was a gold mine of information in the 80's.

On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote:
> The Lions book wasn???t really published back in the day.   It was only targetted at his students in Australia (though copies leaked out).
> 
> The manuals aren???t really a book (and again, they weren???t really published as a book) and most of the prose on UNIX was more in the form of articles than an entire book.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From dave at horsfall.org  Mon Apr  6 10:17:39 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 6 Apr 2020 10:17:39 +1000 (EST)
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.9999.2004061009470.36443@aneurin.horsfall.org>

On Sun, 5 Apr 2020, Ronald Natalie wrote:

> The Lions book wasn’t really published back in the day.  It was only 
> targetted at his students in Australia (though copies leaked out).

Leaked out?  Apparently it's the most photocopied book in the world!  I 
had the originals but sadly lost them in a house move (along with all 
issues of AUUGN).

> The manuals aren’t really a book (and again, they weren’t really 
> published as a book) and most of the prose on UNIX was more in the form 
> of articles than an entire book.

I still reckon that the manpage format is perfect at what it does: telling 
you what you need to know right away without going through various menu 
levels (and that's not a dig at "info" but just an observation in 
general).

-- Dave

From clemc at ccc.com  Mon Apr  6 10:27:40 2020
From: clemc at ccc.com (Clem Cole)
Date: Sun, 5 Apr 2020 20:27:40 -0400
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <20200406000814.GH25105@mcvoy.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <20200406000814.GH25105@mcvoy.com>
Message-ID: <CAC20D2PSbFt47L0g3Jw_aVGra8nzwUW+hJGgitAZEhVk44=PPQ@mail.gmail.com>

Two thoughts ...

1.) Lion's was not a general book.  It really was more of a kernel
'here-is-how-the-magic-happens.'   It's still the best I know for that.
BTW:  it did not leak.  It was purchasable from WE.   But the cost was high
and it was hard to get (you had a price you had a license and could not
buy/order it at any book store - I don't think it had an ISBN or a library
congress number originally).

I know a couple of the schools (like CMU) wanted to use it for the OS
course, but there was some hang-up associated with it in the mid-70s, which
I don't remember - we did have a couple of sections passed out for a few
lecture.  But because of how it was bound (and short), it was photocopied s
others have pointed out.

I think Michigan managed to use the whole thing for their OS course, as I
seem to remember that both Ted Kowalski and Bill Joy got copies there
(although my memory is that they both had photocopies not the original
Orange and Red bindings).  Ted brought it to CMU, which is how I first saw
it (and I think my original copy was a duplicate of his). And I remember
seeing a photocopy in wnj's office at UCB.  The first time I saw
the official Red/Orange bound version was when I ordered it at Tektronix
from WE a few years later, but I had to leave it there when I went back to
grad school.


2.) The question asked about general 'Unix' text -- my favorite is still
Rob and Brian's and I still recommend it (particularly to learn how to
>>use<< UNIX/Linux today by doing the exercises), but it was not first.
 Steve's certainly was early and I thought it was a good explanation and
until Rob and Brian became available was what I suggested when people
asked.  In fact, early Masscomp system's shipped Bourne's text, until Tim
wrote the original 'UNIX In a Nutshell' that started his empire.    That
said, I do seem to remember there was another book around the same time
(79-80 ish) that had a light blue cover that came from one 'PC-press'
publishers.   I wish I could remember the author and the name.  I remember
looking at a copy in Powell's in Portland when it came out and not being
impressed.

On Sun, Apr 5, 2020 at 8:08 PM Larry McVoy <lm at mcvoy.com> wrote:

> Do the Bell Labs technical journals count?  I have a collection of Unix
> papers that were puled out and published together in two volumes.  That
> stuff was a gold mine of information in the 80's.
>
> On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote:
> > The Lions book wasn???t really published back in the day.   It was only
> targetted at his students in Australia (though copies leaked out).
> >
> > The manuals aren???t really a book (and again, they weren???t really
> published as a book) and most of the prose on UNIX was more in the form of
> articles than an entire book.
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200405/514009d6/attachment.html>

From musher at ucsc.edu  Mon Apr  6 10:46:33 2020
From: musher at ucsc.edu (Michael Usher)
Date: Sun, 5 Apr 2020 17:46:33 -0700
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <CAC20D2PSbFt47L0g3Jw_aVGra8nzwUW+hJGgitAZEhVk44=PPQ@mail.gmail.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <20200406000814.GH25105@mcvoy.com>
 <CAC20D2PSbFt47L0g3Jw_aVGra8nzwUW+hJGgitAZEhVk44=PPQ@mail.gmail.com>
Message-ID: <CACg3+DHxyMP9fbycbvxQ37Ya+oTi40tsvJHAYb1XC1--OnH2QQ@mail.gmail.com>

I tried an ngram search on google, and came up with the following:

Richard L. Gauthier. October 1981. Using the Unix System, Reston Publishing
Co.  ISBN 978-0835981644.

That seems to precede the Bourne book.

Available at amazon:
https://www.amazon.com/Using-Unix-System-Richard-Gauthier/dp/0835981649

Michael


On Sun, Apr 5, 2020 at 5:28 PM Clem Cole <clemc at ccc.com> wrote:

> Two thoughts ...
>
> 1.) Lion's was not a general book.  It really was more of a kernel
> 'here-is-how-the-magic-happens.'   It's still the best I know for that.
> BTW:  it did not leak.  It was purchasable from WE.   But the cost was high
> and it was hard to get (you had a price you had a license and could not
> buy/order it at any book store - I don't think it had an ISBN or a library
> congress number originally).
>
> I know a couple of the schools (like CMU) wanted to use it for the OS
> course, but there was some hang-up associated with it in the mid-70s, which
> I don't remember - we did have a couple of sections passed out for a few
> lecture.  But because of how it was bound (and short), it was photocopied s
> others have pointed out.
>
> I think Michigan managed to use the whole thing for their OS course, as I
> seem to remember that both Ted Kowalski and Bill Joy got copies there
> (although my memory is that they both had photocopies not the original
> Orange and Red bindings).  Ted brought it to CMU, which is how I first saw
> it (and I think my original copy was a duplicate of his). And I remember
> seeing a photocopy in wnj's office at UCB.  The first time I saw
> the official Red/Orange bound version was when I ordered it at Tektronix
> from WE a few years later, but I had to leave it there when I went back to
> grad school.
>
>
> 2.) The question asked about general 'Unix' text -- my favorite is still
> Rob and Brian's and I still recommend it (particularly to learn how to
> >>use<< UNIX/Linux today by doing the exercises), but it was not first.
>  Steve's certainly was early and I thought it was a good explanation and
> until Rob and Brian became available was what I suggested when people
> asked.  In fact, early Masscomp system's shipped Bourne's text, until Tim
> wrote the original 'UNIX In a Nutshell' that started his empire.    That
> said, I do seem to remember there was another book around the same time
> (79-80 ish) that had a light blue cover that came from one 'PC-press'
> publishers.   I wish I could remember the author and the name.  I remember
> looking at a copy in Powell's in Portland when it came out and not being
> impressed.
>
> On Sun, Apr 5, 2020 at 8:08 PM Larry McVoy <lm at mcvoy.com> wrote:
>
>> Do the Bell Labs technical journals count?  I have a collection of Unix
>> papers that were puled out and published together in two volumes.  That
>> stuff was a gold mine of information in the 80's.
>>
>> On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote:
>> > The Lions book wasn???t really published back in the day.   It was only
>> targetted at his students in Australia (though copies leaked out).
>> >
>> > The manuals aren???t really a book (and again, they weren???t really
>> published as a book) and most of the prose on UNIX was more in the form of
>> articles than an entire book.
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>

-- 
Michael Usher
Senior Wireless Network Engineer
University of California, Santa Cruz
musher at ucsc.edu        831-459-3697
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200405/c5006d98/attachment.html>

From clemc at ccc.com  Mon Apr  6 11:41:28 2020
From: clemc at ccc.com (Clem Cole)
Date: Sun, 5 Apr 2020 21:41:28 -0400
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <CACg3+DHxyMP9fbycbvxQ37Ya+oTi40tsvJHAYb1XC1--OnH2QQ@mail.gmail.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <20200406000814.GH25105@mcvoy.com>
 <CAC20D2PSbFt47L0g3Jw_aVGra8nzwUW+hJGgitAZEhVk44=PPQ@mail.gmail.com>
 <CACg3+DHxyMP9fbycbvxQ37Ya+oTi40tsvJHAYb1XC1--OnH2QQ@mail.gmail.com>
Message-ID: <CAC20D2M7RYyzjDrOC1nWLRNQB4sry4F32T-ebvBZ5RvyKJh_Wg@mail.gmail.com>

That’s it.

On Sun, Apr 5, 2020 at 8:46 PM Michael Usher <musher at ucsc.edu> wrote:

> I tried an ngram search on google, and came up with the following:
>
> Richard L. Gauthier. October 1981. Using the Unix System, Reston
> Publishing Co.  ISBN 978-0835981644.
>
> That seems to precede the Bourne book.
>
> Available at amazon:
> https://www.amazon.com/Using-Unix-System-Richard-Gauthier/dp/0835981649
>
> Michael
>
>
> On Sun, Apr 5, 2020 at 5:28 PM Clem Cole <clemc at ccc.com> wrote:
>
>> Two thoughts ...
>>
>> 1.) Lion's was not a general book.  It really was more of a kernel
>> 'here-is-how-the-magic-happens.'   It's still the best I know for that.
>> BTW:  it did not leak.  It was purchasable from WE.   But the cost was high
>> and it was hard to get (you had a price you had a license and could not
>> buy/order it at any book store - I don't think it had an ISBN or a library
>> congress number originally).
>>
>> I know a couple of the schools (like CMU) wanted to use it for the OS
>> course, but there was some hang-up associated with it in the mid-70s, which
>> I don't remember - we did have a couple of sections passed out for a few
>> lecture.  But because of how it was bound (and short), it was photocopied s
>> others have pointed out.
>>
>> I think Michigan managed to use the whole thing for their OS course, as I
>> seem to remember that both Ted Kowalski and Bill Joy got copies there
>> (although my memory is that they both had photocopies not the original
>> Orange and Red bindings).  Ted brought it to CMU, which is how I first saw
>> it (and I think my original copy was a duplicate of his). And I remember
>> seeing a photocopy in wnj's office at UCB.  The first time I saw
>> the official Red/Orange bound version was when I ordered it at Tektronix
>> from WE a few years later, but I had to leave it there when I went back to
>> grad school.
>>
>>
>> 2.) The question asked about general 'Unix' text -- my favorite is still
>> Rob and Brian's and I still recommend it (particularly to learn how to
>> >>use<< UNIX/Linux today by doing the exercises), but it was not first.
>>  Steve's certainly was early and I thought it was a good explanation and
>> until Rob and Brian became available was what I suggested when people
>> asked.  In fact, early Masscomp system's shipped Bourne's text, until Tim
>> wrote the original 'UNIX In a Nutshell' that started his empire.    That
>> said, I do seem to remember there was another book around the same time
>> (79-80 ish) that had a light blue cover that came from one 'PC-press'
>> publishers.   I wish I could remember the author and the name.  I remember
>> looking at a copy in Powell's in Portland when it came out and not being
>> impressed.
>>
>> On Sun, Apr 5, 2020 at 8:08 PM Larry McVoy <lm at mcvoy.com> wrote:
>>
>>> Do the Bell Labs technical journals count?  I have a collection of Unix
>>> papers that were puled out and published together in two volumes.  That
>>> stuff was a gold mine of information in the 80's.
>>>
>>> On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote:
>>> > The Lions book wasn???t really published back in the day.   It was
>>> only targetted at his students in Australia (though copies leaked out).
>>> >
>>> > The manuals aren???t really a book (and again, they weren???t really
>>> published as a book) and most of the prose on UNIX was more in the form of
>>> articles than an entire book.
>>>
>>> --
>>> ---
>>> Larry McVoy                  lm at mcvoy.com
>>> http://www.mcvoy.com/lm
>>>
>>
>
> --
> Michael Usher
> Senior Wireless Network Engineer
> University of California, Santa Cruz
> musher at ucsc.edu        831-459-3697
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200405/f89c3df7/attachment.html>

From musher at ucsc.edu  Mon Apr  6 11:46:25 2020
From: musher at ucsc.edu (Michael Usher)
Date: Sun, 5 Apr 2020 18:46:25 -0700
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <CAC20D2M7RYyzjDrOC1nWLRNQB4sry4F32T-ebvBZ5RvyKJh_Wg@mail.gmail.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <20200406000814.GH25105@mcvoy.com>
 <CAC20D2PSbFt47L0g3Jw_aVGra8nzwUW+hJGgitAZEhVk44=PPQ@mail.gmail.com>
 <CACg3+DHxyMP9fbycbvxQ37Ya+oTi40tsvJHAYb1XC1--OnH2QQ@mail.gmail.com>
 <CAC20D2M7RYyzjDrOC1nWLRNQB4sry4F32T-ebvBZ5RvyKJh_Wg@mail.gmail.com>
Message-ID: <CACg3+DEORH=kdG8N_ROUt4iK+B1HN+K4Y=5ugt04ANP8A5YeeQ@mail.gmail.com>

Now that I think about it -- I suspect I did actually read that book in the
late 80s from the Fisher Library collection at Sydney Uni.  The cover looks
familiar to me.

On Sun, Apr 5, 2020 at 6:41 PM Clem Cole <clemc at ccc.com> wrote:

> That’s it.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200405/13eb598e/attachment.html>

From ron at ronnatalie.com  Tue Apr  7 00:51:05 2020
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Mon, 6 Apr 2020 10:51:05 -0400
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <CACg3+DHxyMP9fbycbvxQ37Ya+oTi40tsvJHAYb1XC1--OnH2QQ@mail.gmail.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <20200406000814.GH25105@mcvoy.com>
 <CAC20D2PSbFt47L0g3Jw_aVGra8nzwUW+hJGgitAZEhVk44=PPQ@mail.gmail.com>
 <CACg3+DHxyMP9fbycbvxQ37Ya+oTi40tsvJHAYb1XC1--OnH2QQ@mail.gmail.com>
Message-ID: <33f635bb3ea67f5cf14b46316ca3b6a6.squirrel@squirrelmail.tuffmail.net>

> I tried an ngram search on google, and came up with the following:
>
> Richard L. Gauthier. October 1981. Using the Unix System, Reston
> Publishing
> Co.  ISBN 978-0835981644.
>

Gosh, I'd forgotten about Gauthier, perhaps the worst UNIX book ever written.



From ron at ronnatalie.com  Tue Apr  7 00:54:09 2020
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Mon, 6 Apr 2020 10:54:09 -0400
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <alpine.BSF.2.21.9999.2004061009470.36443@aneurin.horsfall.org>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <alpine.BSF.2.21.9999.2004061009470.36443@aneurin.horsfall.org>
Message-ID: <9e623ba84057c27e067f9c43a8b78d29.squirrel@squirrelmail.tuffmail.net>

> On Sun, 5 Apr 2020, Ronald Natalie wrote:
>
>> The Lions book wasn’t really published back in the day.  It was only
>> targetted at his students in Australia (though copies leaked out).
>
> Leaked out?  Apparently it's the most photocopied book in the world!  I
> had the originals but sadly lost them in a house move (along with all
> issues of AUUGN).

I have one of the Xeroxes.   It's a second generation copy.   I remember
when I got a hold of someone else's copy me and five of my coworkers split
up and went to different copiers around the company and each made six
copies of their section and then we collated it together.  We didn't dare
take it to the company copy center.

>
>> The manuals aren’t really a book (and again, they weren’t really
>> published as a book) and most of the prose on UNIX was more in the form
>> of articles than an entire book.
>
> I still reckon that the manpage format is perfect at what it does: telling
Agreed, but neither the manpages nor the BSTJ articles or the few
non-manpage UNIX documents were "books."




From ron at ronnatalie.com  Tue Apr  7 00:54:08 2020
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Mon, 6 Apr 2020 10:54:08 -0400
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <alpine.BSF.2.21.9999.2004061009470.36443@aneurin.horsfall.org>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <alpine.BSF.2.21.9999.2004061009470.36443@aneurin.horsfall.org>
Message-ID: <99b6fa9e3fb3396864916117033c2799.squirrel@squirrelmail.tuffmail.net>

> On Sun, 5 Apr 2020, Ronald Natalie wrote:
>
>> The Lions book wasn’t really published back in the day.  It was only
>> targetted at his students in Australia (though copies leaked out).
>
> Leaked out?  Apparently it's the most photocopied book in the world!  I
> had the originals but sadly lost them in a house move (along with all
> issues of AUUGN).

I have one of the Xeroxes.   It's a second generation copy.   I remember
when I got a hold of someone else's copy me and five of my coworkers split
up and went to different copiers around the company and each made six
copies of their section and then we collated it together.  We didn't dare
take it to the company copy center.

>
>> The manuals aren’t really a book (and again, they weren’t really
>> published as a book) and most of the prose on UNIX was more in the form
>> of articles than an entire book.
>
> I still reckon that the manpage format is perfect at what it does: telling
Agreed, but neither the manpages nor the BSTJ articles or the few
non-manpage UNIX documents were "books."




From pnr at planet.nl  Tue Apr  7 04:12:09 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 6 Apr 2020 20:12:09 +0200
Subject: [TUHS] PK protocol
Message-ID: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl>

I ran a search for ‘Datakit’ on the archive of this maling list and came across the below message from Norman Wilson (Sep 2017). Having spent quite a bit of time recently on figuring out Datakit details and 8th Edition source, I now much better understand what he was saying — or at least I think I do.

It made me take another look at the /dev/pk[0123].c files in the V7 source code. I’d seen it before, but always thought it was UUCP code.

Now I’m wondering. It looks like UUCP packet "protocol g” is maybe much the same as the original (“Chesson”) packet algorithm for Datakit, and if so it would be “dual use”. It would seem that in V7 line discipline ‘0’ was normal tty handling, discipline ‘1’ was PK protocol over serial and line discipline ‘2’ was PK protocol over something with CRC in the driver - whatever that was.

If the above thought is correct, then it shines a light on network buffering in V7: it uses buffer space in blocks of n*32 bytes, carved out from a pool of disk buffers (see pk3.c); it pre-allocates space for one full receive window.

I have not fully figured it out, but at first glance it seems that the PK line discipline was only integrated with the DH-11 driver in the public V7 source. That would make sense in a networking context, as that board offered input buffering / DMA output to reduce the interrupt load. In 1979 Datakit seems to have connected over a DR-11C board, but there is no driver for that in the V7 source tree.

Am I on the right track?

=====

The point of the stream I/O setup with
stackable line disciplines, rather than the old single
line-discipline switch, was specifically to support networking
as well as tty processing.

Serial-device drivers in V7 used a single line-discipline
driver, used variously for canonical-tty handling and for
network protocols.  The standard system as used outside
the labs had only one line discipline configured, with
standard tty handling (see usr/sys/conf/c.c).  There were
driver source files for what I think were internal-use-only
networks (dev/pk[12].c, perhaps), but I don't think they
were used outside AT&T.

The problem Dennis wanted to solve was that tty handling
and network protocol handling interfered with one another;
you couldn't ask the kernel to do both, because there was
only one line discipline at a time.  Hence the stackable
modules.  It was possible to duplicate tty handling (probably
by placing calls to the regular tty line discipline's innards)
within the network-protocol code, but that was messy.  It also
ran into trouble when people wanted to use the C shell, which
expected its own special `new tty' line discipline, so the
network code would have to know which tty driver to call.
It made more sense to stack the modules instead, so the tty
code was there only if it was needed, and different tty
drivers could exist without the network code knowing or caring.

When I arrived at the Labs in 1984, the streams code was in
use daily by most of us in 1127.  The terminals on our desks
were plugged into serial ports on Datakit (like what we call
a terminal server now).  I would turn on my terminal in the
morning, tell the prompt which system I wanted to connect to,
and so far as I could tell I had a direct serial connection.
But in the remote host, my shell talked to an instance of the
tty line module, which exchanged data with a Datakit protocol
module, which exchanged data with the low-level Datakit driver.
If I switched to the C shell (I didn't but some did), csh would
pop off the tty module and push on the newtty module, and the
network code was none the wiser.

Later there was a TCP/IP that used the stream mechanism.  The
first version was shoehorned in by Robert T Morris, who worked
as a summer intern for us; it was later cleaned up considerably
by Paul Glick.  It's more complicated because of all the
multiplexers involved (Ethernet packets split up by protocol
number; IP packets divided by their own protocol number;
TCP packets into sessions), but it worked.  I still use it at
home.  Its major flaw is that details of the original stream
implementation make it messy to handle windows of more than
4096 bytes; there are also some quirks involving data left in
the pipe when a connection closes, something Dennis's code
doesn't handle well.

The much-messier STREAMS that came out of the official System
V people had fixes for some of that, but at the cost of quite
a bit more complexity; it could probably be done rather better.
At one point I wanted to have a go at it, but I've never had
the time, and now I doubt I ever will.

One demonstration of virtue, though: although Datakit was the
workhorse network in Research when I was there (and despite
the common bias against virtual circuits it worked pretty well;
the major drawback was that although the underlying Datakit
fabric could run at multiple megabits per second, we never had
a host interface that could reliably run at even a single megabit),
we did once arrange to run TCP/IP over a Datakit connection.
It was very simple in concept: make a Datakit connection (so the
Datakit protocol module is present); push an IP instance onto
that stream; and off you go.

I did something similar in my home V10 world when quickly writing
my own implementation of PPP from the specs many years ago.
The core of that code is still in use in my home-written PPPoE code.
PPP and PPPoE are all outside the kernel; the user-mode program
reads and writes the serial device (PPP) or an Ethernet instance
that returns just the desired protocol types (PPPoE), does the
PPP processing, and reads and writes IP packets to a (full-duplex
stream) pipe on the other end of which is pushed the IP module.

All this is very different from the socket(2) way of thinking,
and it has its vices, but it also has its virtues.

Norman Wilson
Toronto ON


From wkt at tuhs.org  Tue Apr  7 08:11:38 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 7 Apr 2020 08:11:38 +1000
Subject: [TUHS] Software Archaeology Challenge?
Message-ID: <20200406221138.GA10092@minnie.tuhs.org>

Anybody feel up for a bit of an archaeology challenge? Warner Losh is
currently poking through a bunch of bits but not having much luck decoding
them correctly. I've put a copy here: https://minnie.tuhs.org/Y5/Challenge/

If you can help, I'd suggest report major findings here, and we can use
the #TUHS channel in the ClassicCmp Discord server for chat.

Here's what Warner has found out so far:

   It's quite interesting, but in a  
   format I've so far not been able to decode more than with emacs.
   However, there's all kinds of wonderful here. This looks like it was a
   dump from a VMS (or maybe similar DEC OS) ANSI tape. There's 4 datasets
   of 2.5MB each.  The first one appears to be a V5 tree of some sort (at
   least it matches the V5 sources in places I can spot check in
   Dennis_v5. The second block looks v6ish or maybe pwbish, but no kernel
   sources. I don't think it's a continuation of the v5 stuff from the
   first dataset. The third dataset is all binaries, as far as I can tell
   so far, but things like mv and passwd. The 4th dataset appears to be
   the dump of a VENIX-11 system, complete with source.

   The 3rd dataset appears to be a Venix system. At least it has venix and
   venix.old in what looks like the root directory. Still trying to sort
   out extracting files from these datasets. v7fs hates them, but I'm
   almost positive that's what they are.

Cheers, Warren

From henry.r.bent at gmail.com  Tue Apr  7 08:48:47 2020
From: henry.r.bent at gmail.com (Henry Bent)
Date: Mon, 6 Apr 2020 18:48:47 -0400
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <20200406221138.GA10092@minnie.tuhs.org>
References: <20200406221138.GA10092@minnie.tuhs.org>
Message-ID: <CAEdTPBeA+TmkF-fT0uGuB-FuZNcgD1uLo333kmWbw+bzJsBVUw@mail.gmail.com>

On Mon, 6 Apr 2020 at 18:12, Warren Toomey <wkt at tuhs.org> wrote:

> Anybody feel up for a bit of an archaeology challenge? Warner Losh is
> currently poking through a bunch of bits but not having much luck decoding
> them correctly. I've put a copy here:
> https://minnie.tuhs.org/Y5/Challenge/
>
> If you can help, I'd suggest report major findings here, and we can use
> the #TUHS channel in the ClassicCmp Discord server for chat.
>
> Here's what Warner has found out so far:
>
>    It's quite interesting, but in a
>    format I've so far not been able to decode more than with emacs.
>    However, there's all kinds of wonderful here. This looks like it was a
>    dump from a VMS (or maybe similar DEC OS) ANSI tape. There's 4 datasets
>    of 2.5MB each.  The first one appears to be a V5 tree of some sort (at
>    least it matches the V5 sources in places I can spot check in
>    Dennis_v5. The second block looks v6ish or maybe pwbish, but no kernel
>    sources. I don't think it's a continuation of the v5 stuff from the
>    first dataset. The third dataset is all binaries, as far as I can tell
>    so far, but things like mv and passwd. The 4th dataset appears to be
>    the dump of a VENIX-11 system, complete with source.
>
>    The 3rd dataset appears to be a Venix system. At least it has venix and
>    venix.old in what looks like the root directory. Still trying to sort
>    out extracting files from these datasets. v7fs hates them, but I'm
>    almost positive that's what they are.
>

Looking at the first file as well as the later 512 byte files, this appears
to have been made on an RT-11 system.  There are entries for HDR1ZEROED.ZZZ
which shows up in the RT-11 5.07 sources:
http://www.kpxx.ru/DEC/PDP-11/Software/OS/RT-11/05.07/05.07.abl/Unpacked/DUPZMC.MAC
.  Unfortunately I have absolutely no experience with magtapes under RT-11
so I'm not currently sure how to proceed.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200406/8c258953/attachment.html>

From drb at msu.edu  Tue Apr  7 08:59:49 2020
From: drb at msu.edu (Dennis Boone)
Date: Mon, 06 Apr 2020 18:59:49 -0400
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: (Your message of Tue, 07 Apr 2020 08:11:38 +1000.)
 <20200406221138.GA10092@minnie.tuhs.org>
References: <20200406221138.GA10092@minnie.tuhs.org> 
Message-ID: <20200406225949.88C792BB520@yagi.h-net.msu.edu>

The tape was made by a PDP-11 system running RT-11.  This manual may
help a little:

http://bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PD6PA-TC_RT-11_Volume_and_File_Formats_Manual_Aug91.pdf

TL;DR - This tape was written by just copying disk files to it, so the
files which contain actual data are just images of the disk files.

File 5 - this looks like a file system image.

File 8 - appears to be some sort of archiver output, but while the .ARC
extension might lead you to suspect the old CP/M - MSDOS ARC program was
responsible, that doesn't appear to be the case.

File 11 - this is an older format tarball.

De

From wkt at tuhs.org  Tue Apr  7 09:47:58 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 7 Apr 2020 09:47:58 +1000
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <20200406221138.GA10092@minnie.tuhs.org>
References: <20200406221138.GA10092@minnie.tuhs.org>
Message-ID: <20200406234758.GA27062@minnie.tuhs.org>

On Tue, Apr 07, 2020 at 08:11:38AM +1000, Warren Toomey wrote:
> Anybody feel up for a bit of an archaeology challenge? Warner Losh is
> currently poking through a bunch of bits but not having much luck decoding
> them correctly. I've put a copy here: https://minnie.tuhs.org/Y5/Challenge/

Warner has more to report:

   set cpu 11/45 [on SimH] was the missing magic.
   The first two data sets are V6 system. Lots of dates around May 13,
   1975 for sure.
   I can also mount the venix disks (I thought it was V7/sys III which had
   a different filesystem layout). It seems to be compiled for the 11/34.
   I'll give that a shot. That almost worked. I think I need to figure out
   how to enable DL as the console since the config file has DL as the
   console.
   Warner

Cheers, Warren

From henry.r.bent at gmail.com  Tue Apr  7 10:04:57 2020
From: henry.r.bent at gmail.com (Henry Bent)
Date: Mon, 6 Apr 2020 20:04:57 -0400
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <20200406234758.GA27062@minnie.tuhs.org>
References: <20200406221138.GA10092@minnie.tuhs.org>
 <20200406234758.GA27062@minnie.tuhs.org>
Message-ID: <CAEdTPBddXfmU57w2Ju-OFboH84afe6yo-QOju2ikNwsyahNCWA@mail.gmail.com>

On Mon, 6 Apr 2020 at 19:48, Warren Toomey <wkt at tuhs.org> wrote:

> On Tue, Apr 07, 2020 at 08:11:38AM +1000, Warren Toomey wrote:
> > Anybody feel up for a bit of an archaeology challenge? Warner Losh is
> > currently poking through a bunch of bits but not having much luck
> decoding
> > them correctly. I've put a copy here:
> https://minnie.tuhs.org/Y5/Challenge/
>
> Warner has more to report:
>
>    The first two data sets are V6 system. Lots of dates around May 13,
>    1975 for sure.
>

The first tape looks like a virgin distribution with the exception of one
file in the root directory, nlsq.f, which is a version of
https://people.sc.fsu.edu/~jburkardt/f77_src/nl2sol/nl2sol.html .  It boots
to a date of October 6, 1983.
.
total 540
-rw-rw-rw-  1 root     9092 Oct  6 15:36 a.out
drwxrwxr-x  2 bin      1104 May 14  1975 bin
drwxrwxr-x  2 bin      1824 May 13  1975 dev
drwxrwxr-x  2 bin       496 Oct  6 15:39 etc
-rwxrwxrwx  1 root    28402 Jun 22  1975 hpunix
drwxrwxr-x  2 bin       464 May 13  1975 lib
drwxrwxr-x  2 bin        32 May 13  1975 mnt
-rw-rw-rw-  1 root   168561 Oct  6 15:35 nlsq.f
-rwxrwxrwx  1 root    28156 Jun 22  1975 rkunix
-rwxrwxrwx  1 root    28340 Jun 22  1975 rpunix
-rw-rw-r--  1 bin      3316 May 14  1975 run
drwxrwxrwx  2 bin       272 Oct  6 15:39 tmp
drwxrwxr-x 14 bin       224 May 13  1975 usr

bin/.
total 392
-rwxrwxr-x  1 bin      1514 May  9  1975 ar
-rwxrwxr-x  1 bin      5748 May  9  1975 as
-rwxrwxr-x  1 bin      8780 May  9  1975 bas
-rwxrwxr-x  1 bin       152 May  9  1975 cat
-rwxrwxr-x  1 bin      7186 May 18  1975 cc
-rwxrwxr-x  1 bin     12358 May 14  1975 cdb
-rwxrwxr-x  1 bin       502 May  9  1975 chgrp
-rwxrwxr-x  1 bin      1734 May  9  1975 chmod
-rwxrwxr-x  1 bin       500 May  9  1975 chown
-rwxrwxr-x  1 bin       190 May  9  1975 clri
-rwxrwxr-x  1 bin      1554 May  9  1975 cmp
-rwxrwxr-x  1 bin       838 May  9  1975 cp
-rwxrwxr-x  1 bin      2062 May  9  1975 date
-rwxrwxr-x  1 bin      4690 May 14  1975 db
-rwxrwxr-x  1 bin     10254 May  9  1975 dc
-rwxrwxr-x  1 bin      2202 May  9  1975 dcheck
-rwxrwxr-x  1 bin      4360 May  9  1975 dd
-rwxrwxr-x  1 bin      1440 May  9  1975 df
-rwxrwxr-x  1 bin       262 May  9  1975 dsw
-rwxrwxr-x  1 bin       654 May  9  1975 du
-rwxrwxr-x  1 bin      4688 May  9  1975 dump
-rwxrwxr-x  1 bin       758 May  9  1975 echo
-rwxrwxr-x  1 bin      6308 May  9  1975 ed
-rwxrwxr-x  1 bin       156 May  9  1975 exit
-rwxrwxr-x  1 bin      4886 May  9  1975 fc
-rwxrwxr-x  1 bin      3036 May  9  1975 file
-rwxrwxr-x  1 bin       788 May  9  1975 goto
-rwxrwxr-x  1 bin      3118 May  9  1975 icheck
-rwxrwxr-x  1 bin      1532 May  9  1975 if
-rwxrwxr-x  1 bin       192 May  9  1975 kill
-rwxrwxr-x  1 bin      6192 May  9  1975 ld
-rwxrwxr-x  1 bin       474 May  9  1975 ln
-rwsr-xr-x  1 root     2628 May  9  1975 login
-rwxrwxr-x  1 bin      4920 May  9  1975 ls
-rwxrwxr-x  1 bin      4370 May  9  1975 mail
-rwsr-xr-x  1 root      240 May  9  1975 mkdir
-rwsr-xr-x  1 root     2360 May  9  1975 mv
-rwxrwxr-x  1 bin      2438 May  9  1975 ncheck
-rwsr-xr-x  1 root     3086 May  9  1975 newgrp
-rwxrwxr-x  1 bin      2476 May  9  1975 nm
-rwxrwxr-x  1 bin      4476 May  9  1975 od
-rwxrwxr-x  1 bin       394 May  9  1975 opr
-rwsr-xr-x  1 bin      2254 May 14  1975 passwd
-rwxrwxr-x  1 bin      4150 May  9  1975 pr
-rwxrwxr-x  1 bin      3220 May  9  1975 ps
-rwxrwxr-x  1 bin      5598 May  9  1975 restor
-rwxrwxr-x  1 bin       114 May  9  1975 rew
-rwxrwxr-x  1 bin      1778 May  9  1975 rm
-rwsr-xr-x  1 root      292 May  9  1975 rmdir
-rwxrwxr-x  1 bin      5888 May 14  1975 sh
-rwxrwxr-x  1 bin      1086 May  9  1975 size
-rwxrwxr-x  1 bin      5032 May  9  1975 sort
-rwxrwxr-x  1 bin       520 May  9  1975 strip
-rwxrwxr-x  1 bin      2312 May  9  1975 stty
-rwsr-xr-x  1 root     1934 May  9  1975 su
-rwxrwxr-x  1 bin       202 May  9  1975 sum
-rwxrwxr-x  1 bin       100 May  9  1975 sync
-rwxrwxr-x  1 bin       610 May  9  1975 time
-rwxrwxr-x  1 bin      6798 May  9  1975 tp
-rwxrwxr-x  1 bin       158 May  9  1975 tty
-rwxrwxr-x  1 bin      1746 May  9  1975 uniq
-rwxrwxr-x  1 bin      1916 May  9  1975 who
-rwxrwxr-x  1 bin       680 May  9  1975 write

dev/.
total 0
crw-rw-r--  1 bin     8,  1 May 13  1975 kmem
c-w--w--w-  1 bin     2,  0 May 18  1975 lp
crw-rw-r--  1 bin     8,  0 May 13  1975 mem
brw-rw-rw-  1 bin     3,  0 Oct  6 14:10 mt0
crw-rw-rw-  1 bin     8,  2 May 13  1975 null
crw-rw-rw-  1 bin     1,  0 May 13  1975 ppt
brw-rw-r--  1 bin     2,  0 May 18  1975 rf0
brw-rw-r--  1 bin     0,  0 May 20  1975 rk0
brw-rw-r--  1 bin     0,  1 May 27  1975 rk1
crw-rw-rw-  1 bin    12,  0 May 13  1975 rmt0
brw-rw-r--  1 bin     1,  0 May 13  1975 rp0
crw-rw-r--  1 bin    10,  0 May 13  1975 rrf0
crw-rw-r--  1 bin     9,  0 May 13  1975 rrk0
crw-rw-r--  1 bin     9,  1 May 13  1975 rrk1
crw-rw-r--  1 bin    11,  0 May 13  1975 rrp0
brw-rw-rw-  1 bin     4,  0 May 18  1975 tap0
brw-rw-rw-  1 bin     4,  1 May 13  1975 tap1
brw-rw-rw-  1 bin     4,  2 May 13  1975 tap2
brw-rw-rw-  1 bin     4,  3 May 13  1975 tap3
brw-rw-rw-  1 bin     4,  4 May 13  1975 tap4
brw-rw-rw-  1 bin     4,  5 May 13  1975 tap5
brw-rw-rw-  1 bin     4,  6 May 13  1975 tap6
brw-rw-rw-  1 bin     4,  7 May 13  1975 tap7
crw--w--w-  1 root    0,  0 Oct  6 15:41 tty8

etc/.
total 51
-rwsrwsr--  1 daemon   3246 May 13  1975 cron
-rw-rw-rw-  1 bin         0 May 13  1975 dtab
-rwxrwxr--  1 bin       922 May 13  1975 getty
-rwxrwxr-x  1 bin      1378 May 13  1975 glob
-rw-r--r--  1 bin        26 May 13  1975 group
-rwxrwxr--  1 root     2054 May 13  1975 init
-rwsrwsr-x  1 daemon    814 May 13  1975 lpd
-rwxrwxr-x  1 bin      4368 May 13  1975 mkfs
-rwxrwxr-x  1 bin      1850 May 13  1975 mknod
-rwsrwxr-x  1 bin      2100 May 13  1975 mount
-rw-r--r--  1 bin        66 May 27  1975 passwd
-rw-rw-r--  1 bin        28 May 13  1975 rc
-rw-rw-r--  1 bin       112 May 13  1975 ttys
-rwsrwxr-x  1 bin      2010 May 13  1975 umount
-rwxrwxr-x  1 bin        48 May 13  1975 update
-rw-rw-r--  1 bin       144 Oct  6 15:39 utmp
-rwxrwxr-x  1 bin      1310 May 13  1975 wall

lib/.
total 418
-rwxrwxr-x  1 bin      5064 May 13  1975 as2
-rwxrwxr-x  1 bin     14688 May 16  1975 c0
-rwxrwxr-x  1 bin     19186 May 16  1975 c1
-rwxrwxr-x  1 bin      8020 May 16  1975 c2
-rw-rw-r--  1 bin       112 May 13  1975 crt0.o
-rwxrwxr-x  1 bin     16760 May 16  1975 fc0
-rwxrwxr-x  1 bin     21194 May 16  1975 fc1
-rw-rw-r--  1 bin       136 May 14  1975 fcrt0.o
-rw-rw-r--  1 bin     13810 May 27  1975 filib.a
-rw-rw-r--  1 bin       340 May 13  1975 fr0.o
-rw-rw-r--  1 bin     14118 May 27  1975 liba.a
-rw-rw-r--  1 bin     22042 May 27  1975 libc.a
-rw-rw-r--  1 bin     13958 May 27  1975 libf.a
-rw-rw-r--  1 bin     27606 May 27  1975 libp.a
-rw-rw-r--  1 bin      9982 May 27  1975 libs.a
-rw-rw-r--  1 bin      3530 May 27  1975 liby.a
-rwxrwxr-x  1 bin      3144 May 13  1975 lpr
-rw-rw-r--  1 bin       436 May 16  1975 mcrt0.o
-rw-rw-rw-  1 root     8794 May 27  1975 tmgb

mnt/.
total 0

tmp/.
total 0

usr/.
total 15
drwxrwxr-x  2 bin        48 May 13  1975 adm
drwxrwxr-x  2 bin      1984 Jun 22  1975 bin
drwxrwxr-x  2 bin        64 May 13  1975 fort
drwxrwxr-x  2 bin       192 May 28  1975 games
drwxrwxrwx  2 ken       128 May 28  1975 ken
drwxrwxr-x  3 bin       432 May 13  1975 lib
drwxrwxrwx  2 bin       288 May 18  1975 lpd
drwxrwxr-x  2 bin       352 Jun 26  1975 mdec
drwxrwxr-x  2 bin       256 May 13  1975 pub
drwxrwxr-x  2 bin        32 May 13  1975 source
drwxrwxr-x  5 bin       512 Jun 22  1975 sys
drwxrwxrwx  2 bin       144 May 27  1975 tmp

usr/adm/.
total 0

usr/bin/.
total 467
-rwxrwxr-x  1 bin      4984 May 13  1975 ac
-rwxrwxr-x  1 bin      1596 May 14  1975 banner
-rwxrwxr-x  1 bin     12282 May 14  1975 bc
-rwxrwxr-x  1 bin      1056 May 14  1975 bcd
-rwxrwxr-x  1 bin      1862 May 13  1975 cal
-rwxrwxr-x  1 bin        59 May 13  1975 chk
-rwxrwxr-x  1 bin      1982 Jun 22  1975 col
-rwxrwxr-x  1 bin      1938 May 13  1975 comm
-rwxrwxr-x  1 bin       504 May 14  1975 cpall
-rwxrwxr-x  1 bin      7782 May 13  1975 cref
-rwxrwxr-x  1 bin      2286 May 13  1975 crpost
-rwxrwxr-x  1 bin      1246 May 14  1975 crypt
-rwxrwxr-x  1 bin      4544 May 14  1975 diff
-rwxrwxr-x  1 bin      4826 May 13  1975 fed
-rwxrwxr-x  1 bin      5244 May 13  1975 find
-rwxrwxr-x  1 bin      4118 May 13  1975 form
-rwxrwxr-x  1 bin      2190 May 13  1975 grep
-rwxrwxr-x  1 bin      1998 May 14  1975 gsi
-rwxrwxr-x  1 bin      5812 May 13  1975 index
-rwxrwxr-x  1 bin      9798 May 13  1975 m6
-rwxrwxr-x  1 bin       576 May 13  1975 mesg
-rwxrwxr-x  1 bin     20234 May 14  1975 neqn
-rwxrwxr-x  1 bin      1134 May 13  1975 nice
-rwxrwxr-x  1 bin      1298 May 13  1975 nohup
-rwxrwxr-x  1 bin     16542 May 13  1975 nroff
-rwxrwxr-x  1 bin       240 May 13  1975 pfe
-rwxrwxr-x  1 bin      6916 May 13  1975 prof
-rwxrwxr-x  1 bin      3156 May 13  1975 ptx
-rwxrwxr-x  1 bin       834 May 13  1975 pwd
-rwxrwxr-x  1 bin      4674 May 13  1975 quiz
-rwxrwxr-x  1 bin      4898 May 13  1975 rc
-rwxrwxr-x  1 bin      8136 May 13  1975 roff
-rwxrwxr-x  1 bin      9270 May 16  1975 sa
-rwxrwxr-x  1 bin       836 May 13  1975 sleep
-rwxrwxr-x  1 bin      8624 May 13  1975 sno
-rwxrwxr-x  1 bin      1104 May 13  1975 split
-rwxrwxr-x  1 bin      8230 May 14  1975 tbl
-rwxrwxr-x  1 bin       648 May 13  1975 tee
-rwxrwxr-x  1 bin        88 May 13  1975 tmg
-rwxrwxr-x  1 bin      1632 May 13  1975 tr
-rwxrwxr-x  1 bin      7802 May 13  1975 typo
-rwxrwxr-x  1 bin      6248 May 16  1975 units
-rwxrwxr-x  1 bin      1952 May 13  1975 upost
-rwxrwxr-x  1 bin      4458 May 13  1975 usort
-rwxrwxr-x  1 bin      1664 May 13  1975 wc
-rwxrwxr-x  1 bin     16964 May 13  1975 yacc

usr/fort/.
total 32
-rw-rw-r--  1 bin      1420 May 13  1975 errors
-rwxrwxr-x  1 bin     14102 May 13  1975 fc1

usr/games/.
total 62
-rwxrwxr-x  1 bin      1562 May 13  1975 bj
-rwxrwxr-x  1 bin     16088 May 13  1975 chess
-rwxrwxr-x  1 bin      2468 May 13  1975 cubic
-rwxrwxr-x  1 bin       624 May 13  1975 moo
-rwxrwxr-x  1 bin      2192 May 13  1975 ttt
-rw-rw-rw-  1 bin       304 May 28  1975 ttt.k
-rwxrwxr-x  1 bin      5184 May 13  1975 wump

usr/lib/.
total 386
-rw-rw-r--  1 bin       658 May 13  1975 aign
-rw-rw-r--  1 bin       768 May 13  1975 atab
-rw-rw-r--  1 bin     57704 May 20  1975 book
-rw-rw-r--  1 bin       142 May 13  1975 cign
-rw-rw-r--  1 bin       768 May 13  1975 ctab
-rw-rw-r--  1 bin       706 May 13  1975 eign
-rw-rw-r--  1 bin       768 May 13  1975 etab
-rw-rw-r--  1 bin      1609 May 20  1975 lib.b
drwxrwxr-x  2 bin       352 May 13  1975 quiz
-rwxrwxr-x  1 bin     12106 May 14  1975 ratfor
-rw-rw-r--  1 bin     21200 May 13  1975 salt
-rw-rw-r--  1 bin      2168 May 13  1975 suftab
-rw-rw-r--  1 bin      1112 May 13  1975 tmac.r
-rw-rw-r--  1 bin     12347 May 20  1975 tmac.s
-rwxrwxr-x  1 bin     11156 May 14  1975 tmg
-rw-rw-r--  1 bin      2612 May 13  1975 tmga
-rw-rw-r--  1 bin      8794 May 13  1975 tmgb
-rw-rw-r--  1 bin       388 May 13  1975 tmgc
-rw-rw-r--  1 bin      7608 May 20  1975 units
-rw-rw-r--  1 bin     44816 May 13  1975 w2006

usr/lib/quiz/.
total 62
-rw-rw-r--  1 bin       904 May 13  1975 africa
-rw-rw-r--  1 bin       542 May 13  1975 america
-rw-rw-r--  1 bin      6704 May 13  1975 bard
-rw-rw-r--  1 bin      1403 May 13  1975 collectives
-rw-rw-r--  1 bin       745 May 13  1975 europe
-rw-rw-r--  1 bin       301 May 13  1975 inca
-rw-rw-r--  1 bin       811 May 13  1975 index
-rw-rw-r--  1 bin       274 May 13  1975 midearth
-rw-rw-r--  1 bin       553 May 13  1975 misspell
-rw-rw-r--  1 bin       889 May 20  1975 murders
-rw-rw-r--  1 bin      5588 May 13  1975 poetry
-rw-rw-r--  1 bin       814 May 13  1975 posneg
-rw-rw-r--  1 bin      2351 May 13  1975 pres
-rw-rw-r--  1 bin       722 May 13  1975 seq-easy
-rw-rw-r--  1 bin       872 May 13  1975 seq-hard
-rw-rw-r--  1 bin      1652 May 13  1975 sov
-rw-rw-r--  1 bin      1370 May 13  1975 state

usr/lpd/.
total 0

usr/mdec/.
total 39
-rw-rw-r--  1 bin       228 Jun 26  1975 dldr
-rw-rw-r--  1 bin      2406 Jun 26  1975 dtf
-rw-rw-r--  1 bin       460 Jun 26  1975 hboot
-rw-rw-r--  1 bin       504 Jun 26  1975 hpuboot
-rw-rw-r--  1 bin       396 Jun 26  1975 hthp
-rw-rw-r--  1 bin       356 Jun 26  1975 htrk
-rw-rw-r--  1 bin       366 Jun 26  1975 htrp
-rw-rw-r--  1 bin       442 Jun 26  1975 mboot
-rw-rw-r--  1 bin       432 Jun 26  1975 mcopy
-rw-rw-r--  1 bin      5614 Jun 26  1975 mem
-rw-rw-r--  1 bin        20 Jun 26  1975 reset
-rw-rw-r--  1 bin       128 Jun 26  1975 rkf
-rw-rw-r--  1 bin       464 Jun 26  1975 rkuboot
-rw-rw-r--  1 bin       474 Jun 26  1975 rpuboot
-rw-rw-r--  1 bin       406 Jun 26  1975 tboot
-rw-rw-r--  1 bin      2382 Jun 26  1975 tcf
-rw-rw-r--  1 bin       378 Jun 26  1975 tmhp
-rw-rw-r--  1 bin       338 Jun 26  1975 tmrk
-rw-rw-r--  1 bin       348 Jun 26  1975 tmrp
-rw-rw-r--  1 bin       512 Jun 26  1975 uboot

usr/pub/.
total 12
-rw-rw-r--  1 bin      1056 May 13  1975 ascii
-rw-rw-r--  1 bin      1561 May 13  1975 deverr
-rw-rw-r--  1 bin       477 May 13  1975 greek
-rw-rw-r--  1 bin       729 May 13  1975 hanoi
-rw-rw-r--  1 bin       244 May 13  1975 kbd
-rw-rw-r--  1 bin       232 May 13  1975 tabs

usr/source/.
total 0

usr/sys/.
total 253
-rw-rw-r--  1 bin      2886 May 13  1975 buf.h
drwxrwxr-x  2 bin       320 Jun 22  1975 conf
-rw-rw-r--  1 bin       916 May 13  1975 conf.h
drwxrwxr-x  2 bin       848 May 27  1975 dmr
-rw-rw-r--  1 bin       407 May 13  1975 file.h
-rw-rw-r--  1 bin       949 May 13  1975 filsys.h
-rw-rw-r--  1 bin       533 May 13  1975 ino.h
-rw-rw-r--  1 bin      1694 May 13  1975 inode.h
drwxrwxr-x  2 bin       688 Jun 22  1975 ken
-rw-rw-r--  1 bin     59018 Jun 22  1975 lib1
-rw-rw-r--  1 bin     43066 May 27  1975 lib2
-rw-rw-r--  1 bin      2147 May 13  1975 param.h
-rw-rw-r--  1 bin      1395 May 13  1975 proc.h
-rw-rw-r--  1 bin       274 May 13  1975 reg.h
-rw-rw-r--  1 bin       849 May 18  1975 run
-rw-rw-r--  1 bin       465 May 13  1975 seg.h
-rw-rw-r--  1 bin      1749 May 13  1975 systm.h
-rw-rw-r--  1 bin       380 May 13  1975 text.h
-rw-rw-r--  1 bin      2320 May 13  1975 tty.h
-rw-rw-r--  1 bin      2911 May 13  1975 user.h

usr/sys/conf/.
total 67
-rw-rw-r--  1 bin        70 May 13  1975 data.s
-rw-rw-r--  1 bin     10007 May 13  1975 m40.s
-rw-rw-r--  1 bin     10526 May 13  1975 m45.s
-rw-rw-r--  1 bin      8603 May 14  1975 mkconf.c
-rw-rw-r--  1 bin      2252 May 13  1975 sysfix.c

usr/sys/dmr/.
total 166
-rw-rw-r--  1 bin     12091 May 13  1975 bio.c
-rw-rw-r--  1 bin       941 May 13  1975 cat.c
-rw-rw-r--  1 bin      4380 May 13  1975 dc.c
-rw-rw-r--  1 bin      5388 May 13  1975 dh.c
-rw-rw-r--  1 bin      1569 May 13  1975 dhdm.c
-rw-rw-r--  1 bin       262 May 13  1975 dhfdm.c
-rw-rw-r--  1 bin      1313 May 13  1975 dn.c
-rw-rw-r--  1 bin      4774 May 13  1975 dp.c
-rw-rw-r--  1 bin      4355 May 13  1975 hp.c
-rw-rw-r--  1 bin      1862 May 13  1975 hs.c
-rw-rw-r--  1 bin      3898 May 13  1975 ht.c
-rw-rw-r--  1 bin      1965 May 13  1975 kl.c
-rw-rw-r--  1 bin      2310 May 13  1975 lp.c
-rw-rw-r--  1 bin      1146 May 13  1975 mem.c
-rw-rw-r--  1 bin       748 May 13  1975 partab.c
-rw-rw-r--  1 bin      2309 May 13  1975 pc.c
-rw-rw-r--  1 bin      1457 May 13  1975 rf.c
-rw-rw-r--  1 bin      1849 May 13  1975 rk.c
-rw-rw-r--  1 bin      2871 May 13  1975 rp.c
-rw-rw-r--  1 bin       748 May 13  1975 sys.c
-rw-rw-r--  1 bin      2572 May 13  1975 tc.c
-rw-rw-r--  1 bin      3764 May 13  1975 tm.c
-rw-rw-r--  1 bin     10492 May 13  1975 tty.c
-rw-rw-r--  1 bin      1593 May 13  1975 vs.c
-rw-rw-r--  1 bin       884 May 13  1975 vt.c

usr/sys/ken/.
total 182
-rw-rw-r--  1 bin      6132 Jun 18  1975 alloc.c
-rw-rw-r--  1 bin      2711 May 13  1975 clock.c
-rw-rw-r--  1 bin      4268 May 13  1975 fio.c
-rw-rw-r--  1 bin      4258 May 13  1975 iget.c
-rw-rw-r--  1 bin      4374 May 13  1975 main.c
-rw-rw-r--  1 bin      1699 May 13  1975 malloc.c
-rw-rw-r--  1 bin      3490 May 13  1975 nami.c
-rw-rw-r--  1 bin      3268 May 13  1975 pipe.c
-rw-rw-r--  1 bin      2351 May 13  1975 prf.c
-rw-rw-r--  1 bin      3776 May 13  1975 rdwri.c
-rw-rw-r--  1 bin      6100 May 20  1975 sig.c
-rw-rw-r--  1 bin      9531 Jun 22  1975 slp.c
-rw-rw-r--  1 bin      3495 May 13  1975 subr.c
-rw-rw-r--  1 bin      6937 May 20  1975 sys1.c
-rw-rw-r--  1 bin      4136 May 13  1975 sys2.c
-rw-rw-r--  1 bin      3098 May 13  1975 sys3.c
-rw-rw-r--  1 bin      3716 May 13  1975 sys4.c
-rw-rw-r--  1 bin      2181 May 13  1975 sysent.c
-rw-rw-r--  1 bin      3254 May 13  1975 text.c
-rw-rw-r--  1 bin      4386 May 20  1975 trap.c

usr/tmp/.
total 0

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200406/e5090245/attachment.html>

From henry.r.bent at gmail.com  Tue Apr  7 10:18:14 2020
From: henry.r.bent at gmail.com (Henry Bent)
Date: Mon, 6 Apr 2020 20:18:14 -0400
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <20200406234758.GA27062@minnie.tuhs.org>
References: <20200406221138.GA10092@minnie.tuhs.org>
 <20200406234758.GA27062@minnie.tuhs.org>
Message-ID: <CAEdTPBcfS6wvw3rJ4w8H_1nC4+zou6TxqUB3qek9Sdsbc6RqQw@mail.gmail.com>

On Mon, 6 Apr 2020 at 19:48, Warren Toomey <wkt at tuhs.org> wrote:

> On Tue, Apr 07, 2020 at 08:11:38AM +1000, Warren Toomey wrote:
> > Anybody feel up for a bit of an archaeology challenge? Warner Losh is
> > currently poking through a bunch of bits but not having much luck
> decoding
> > them correctly. I've put a copy here:
> https://minnie.tuhs.org/Y5/Challenge/
>
> Warner has more to report:
>
>    set cpu 11/45 [on SimH] was the missing magic.
>    The first two data sets are V6 system. Lots of dates around May 13,
>    1975 for sure.
>

The second file from the tape is /usr/source from v6:

usr/source/.
total 36
drwxrwxr-x  2 bin       368 May 27  1975 as
drwxrwxr-x  2 bin       928 May 27  1975 c
drwxrwxr-x  5 bin       128 May 13  1975 cref
drwxrwxr-x 11 bin       288 May 28  1975 fort
drwxrwxr-x  2 bin      1248 May 27  1975 iolib
drwxrwxr-x  2 bin       320 May 27  1975 m6
drwxrwxr-x  2 bin       448 Jun 26  1975 mdec
drwxrwxr-x  2 bin       256 May 27  1975 rat
-rw-rw-r--  1 bin       753 May 18  1975 run
drwxrwxr-x  2 bin      1696 Jun 22  1975 s1
drwxrwxr-x  2 bin      1280 May 27  1975 s2
drwxrwxr-x  2 bin       816 May 27  1975 s3
drwxrwxr-x  2 bin      2544 May 27  1975 s4
drwxrwxr-x  2 bin      1264 May 27  1975 s5
drwxrwxr-x  2 bin       800 May 27  1975 s7
drwxrwxr-x  2 bin       384 May 27  1975 salloc
drwxrwxr-x  2 bin       224 May 27  1975 sno
drwxrwxr-x  3 bin       176 May 27  1975 tmg
drwxrwxr-x  4 bin        80 May 13  1975 yacc

usr/source/as/.
total 97
-rw-rw-r--  1 bin      1175 May 13  1975 as11.s
-rw-rw-r--  1 bin       789 May 13  1975 as12.s
-rw-rw-r--  1 bin      1473 May 13  1975 as13.s
-rw-rw-r--  1 bin      2593 May 13  1975 as14.s
-rw-rw-r--  1 bin      1615 May 13  1975 as15.s
-rw-rw-r--  1 bin      2917 May 13  1975 as16.s
-rw-rw-r--  1 bin      2238 May 13  1975 as17.s
-rw-rw-r--  1 bin      1273 May 13  1975 as18.s
-rw-rw-r--  1 bin      6755 May 13  1975 as19.s
-rw-rw-r--  1 bin      3170 May 13  1975 as21.s
-rw-rw-r--  1 bin      1725 May 13  1975 as22.s
-rw-rw-r--  1 bin      1805 May 13  1975 as23.s
-rw-rw-r--  1 bin      1390 May 13  1975 as24.s
-rw-rw-r--  1 bin        71 May 13  1975 as25.s
-rw-rw-r--  1 bin      6056 May 13  1975 as26.s
-rw-rw-r--  1 bin      3178 May 13  1975 as27.s
-rw-rw-r--  1 bin       918 May 13  1975 as28.s
-rw-rw-r--  1 bin      3953 May 13  1975 as29.s
-rw-rw-r--  1 bin        96 May 17  1975 run

usr/source/c/.
total 261
-rw-rw-r--  1 bin     12150 May 13  1975 c00.c
-rw-rw-r--  1 bin      6477 May 13  1975 c01.c
-rw-rw-r--  1 bin     13353 May 15  1975 c02.c
-rw-rw-r--  1 bin      2520 May 13  1975 c03.c
-rw-rw-r--  1 bin      4255 May 13  1975 c04.c
-rw-rw-r--  1 bin      4452 May 13  1975 c0h.c
-rw-rw-r--  1 bin      1704 May 27  1975 c0t.s
-rw-rw-r--  1 bin     14545 May 13  1975 c10.c
-rw-rw-r--  1 bin      8931 May 13  1975 c11.c
-rw-rw-r--  1 bin     10425 May 15  1975 c12.c
-rw-rw-r--  1 bin      3036 May 13  1975 c13.c
-rw-rw-r--  1 bin      3165 May 13  1975 c1h.c
-rw-rw-r--  1 bin      1679 May 13  1975 c1t.s
-rw-rw-r--  1 bin     11086 May 13  1975 c20.c
-rw-rw-r--  1 bin      9745 May 13  1975 c21.c
-rw-rw-r--  1 bin      1735 May 13  1975 c2h.c
-rw-rw-r--  1 bin      4335 May 13  1975 cvopt.c
-rw-rw-r--  1 bin       468 May 16  1975 run
-rw-rw-r--  1 bin      8581 May 13  1975 table.s

usr/source/cref/.
total 7
-rw-rw-r--  1 bin       861 May 13  1975 ccmn.h
drwxrwxr-x  2 bin       192 May 27  1975 index
-rw-rw-r--  1 bin       489 May 13  1975 mcons.h
-rw-rw-r--  1 bin       401 May 17  1975 run
drwxrwxr-x  2 bin       208 May 27  1975 src
drwxrwxr-x  2 bin       224 May 27  1975 tab

usr/source/cref/index/.
total 25
-rw-rw-r--  1 bin       744 May 13  1975 ecmn.h
-rw-rw-r--  1 bin       362 May 13  1975 econs.h
-rw-rw-r--  1 bin      5532 May 13  1975 ind0.c
-rw-rw-r--  1 bin      3725 May 13  1975 ind1.c
-rw-rw-r--  1 bin       548 May 13  1975 ind2.c

usr/source/cref/src/.
total 44
-rw-rw-r--  1 bin      6570 May 13  1975 acts.c
-rw-rw-r--  1 bin      3409 May 13  1975 crpost.c
-rw-rw-r--  1 bin      7166 May 13  1975 dr.c
-rw-rw-r--  1 bin       800 May 13  1975 put.c
-rw-rw-r--  1 bin      2577 May 13  1975 upost.c

usr/source/cref/tab/.
total 24
-rw-rw-r--  1 bin      3032 May 13  1975 atable
-rw-rw-r--  1 bin      3073 May 13  1975 ctable
-rw-rw-r--  1 bin      2371 May 13  1975 etable
-rw-rw-r--  1 bin      3023 May 13  1975 mtab.c

usr/source/fort/.
total 24
drwxrwxr-x  2 bin       320 May 27  1975 f1
drwxrwxr-x  2 bin       224 May 27  1975 f2
drwxrwxr-x  2 bin       384 May 27  1975 f3
drwxrwxr-x  2 bin       320 May 27  1975 f4
drwxrwxr-x  2 bin       720 May 27  1975 fx
drwxrwxr-x  2 bin       192 May 27  1975 io
drwxrwxr-x  2 bin       640 May 27  1975 rt
drwxrwxr-x  2 bin      1440 May 27  1975 rt1
drwxrwxr-x  2 bin       288 May 27  1975 rt2
-rw-rw-r--  1 bin      3744 May 13  1975 run
-rw-rw-r--  1 bin      1198 May 13  1975 sum.s

usr/source/fort/f1/.
total 18
-rw-rw-r--  1 bin      1897 May 13  1975 f11.s
-rw-rw-r--  1 bin      1220 May 13  1975 f12.s
-rw-rw-r--  1 bin      1355 May 13  1975 f13.s
-rw-rw-r--  1 bin      1195 May 13  1975 f14.s
-rw-rw-r--  1 bin       945 May 13  1975 f15.s
-rw-rw-r--  1 bin       425 May 13  1975 f16.s
-rw-rw-r--  1 bin       799 May 13  1975 f17.s

usr/source/fort/f2/.
total 14
-rw-rw-r--  1 bin       303 May 13  1975 f21.s
-rw-rw-r--  1 bin      1512 May 13  1975 f22.s
-rw-rw-r--  1 bin      2019 May 13  1975 f23.s
-rw-rw-r--  1 bin      2722 May 13  1975 f24.s

usr/source/fort/f3/.
total 44
-rw-rw-r--  1 bin      2001 May 13  1975 f31.s
-rw-rw-r--  1 bin      2583 May 13  1975 f32.s
-rw-rw-r--  1 bin      1666 May 13  1975 f33.s
-rw-rw-r--  1 bin       752 May 13  1975 f34.s
-rw-rw-r--  1 bin      1095 May 13  1975 f35.s
-rw-rw-r--  1 bin      5655 May 13  1975 f36.s
-rw-rw-r--  1 bin      1151 May 13  1975 f37.s
-rw-rw-r--  1 bin      1051 May 13  1975 f38.s
-rw-rw-r--  1 bin      3004 May 13  1975 f39.s

usr/source/fort/f4/.
total 26
-rw-rw-r--  1 bin       528 May 13  1975 f41.s
-rw-rw-r--  1 bin      1216 May 13  1975 f42.s
-rw-rw-r--  1 bin       946 May 13  1975 f43.s
-rw-rw-r--  1 bin      1194 May 13  1975 f44.s
-rw-rw-r--  1 bin      1652 May 13  1975 f45.s
-rw-rw-r--  1 bin      1676 May 13  1975 f46.s
-rw-rw-r--  1 bin      3967 May 13  1975 f47.s

usr/source/fort/fx/.
total 54
-rw-rw-r--  1 bin       783 May 13  1975 fhd.s
-rw-rw-r--  1 bin       513 May 13  1975 fx1.s
-rw-rw-r--  1 bin      1450 May 13  1975 fx2.s
-rw-rw-r--  1 bin       589 May 13  1975 fx3.s
-rw-rw-r--  1 bin      4158 May 13  1975 fx4.s
-rw-rw-r--  1 bin       564 May 13  1975 fx5.s
-rw-rw-r--  1 bin       323 May 13  1975 fx6.s
-rw-rw-r--  1 bin       293 May 13  1975 fx7.s
-rw-rw-r--  1 bin      2774 May 13  1975 fx8.s
-rw-rw-r--  1 bin      1365 May 13  1975 fx9.s
-rw-rw-r--  1 bin       397 May 13  1975 fxa.s
-rw-rw-r--  1 bin       366 May 13  1975 fxb.s
-rw-rw-r--  1 bin       414 May 13  1975 fxc.s
-rw-rw-r--  1 bin       555 May 13  1975 fxd.s
-rw-rw-r--  1 bin       299 May 13  1975 fxe.s
-rw-rw-r--  1 bin       287 May 13  1975 fxf.s
-rw-rw-r--  1 bin      2869 May 13  1975 fxg.s
-rw-rw-r--  1 bin      1101 May 13  1975 fxh.s
-rw-rw-r--  1 bin      1510 May 13  1975 fxi.s
-rw-rw-r--  1 bin      1282 May 13  1975 fxx.s

usr/source/fort/io/.
total 31
-rw-rw-r--  1 bin       742 May 13  1975 io1.s
-rw-rw-r--  1 bin      2753 May 13  1975 io2.s
-rw-rw-r--  1 bin      3161 May 13  1975 io3.s
-rw-rw-r--  1 bin      2276 May 13  1975 io4.s
-rw-rw-r--  1 bin       961 May 13  1975 io5.s
-rw-rw-r--  1 bin      2268 May 13  1975 io6.s
-rw-rw-r--  1 bin       721 May 13  1975 io7.s
-rw-rw-r--  1 bin       603 May 13  1975 iox.s

usr/source/fort/rt/.
total 41
-rw-rw-r--  1 bin       557 May 13  1975 r0.s
-rw-rw-r--  1 bin      1478 May 13  1975 r1.s
-rw-rw-r--  1 bin      1305 May 13  1975 r2.s
-rw-rw-r--  1 bin       437 May 13  1975 r3.s
-rw-rw-r--  1 bin       641 May 13  1975 r4.s
-rw-rw-r--  1 bin       491 May 13  1975 r5.s
-rw-rw-r--  1 bin      1107 May 13  1975 r6.s
-rw-rw-r--  1 bin      1368 May 13  1975 r7.s
-rw-rw-r--  1 bin       339 May 13  1975 r8.s
-rw-rw-r--  1 bin       617 May 13  1975 r9.s
-rw-rw-r--  1 bin       417 May 13  1975 ra.s
-rw-rw-r--  1 bin       579 May 13  1975 rb.s
-rw-rw-r--  1 bin      2934 May 13  1975 rc.s
-rw-rw-r--  1 bin       423 May 13  1975 rd.s
-rw-rw-r--  1 bin       547 May 13  1975 re.s
-rw-rw-r--  1 bin       531 May 13  1975 rf.s
-rw-rw-r--  1 bin       959 May 13  1975 rg.s
-rw-rw-r--  1 bin      1428 May 13  1975 rh.s
-rw-rw-r--  1 bin       106 May 13  1975 rx.s

usr/source/fort/rt1/.
total 46
-rw-rw-r--  1 bin       245 May 13  1975 abs.s
-rw-rw-r--  1 bin       223 May 13  1975 aimag.s
-rw-rw-r--  1 bin       211 May 13  1975 aint.s
-rw-rw-r--  1 bin       307 May 13  1975 alog.s
-rw-rw-r--  1 bin       360 May 13  1975 alog10.s
-rw-rw-r--  1 bin       450 May 13  1975 amax0.s
-rw-rw-r--  1 bin       542 May 13  1975 amax1.s
-rw-rw-r--  1 bin       450 May 13  1975 amin0.s
-rw-rw-r--  1 bin       510 May 13  1975 amin1.s
-rw-rw-r--  1 bin       384 May 13  1975 amod.s
-rw-rw-r--  1 bin       267 May 13  1975 atan.s
-rw-rw-r--  1 bin       345 May 13  1975 atan2.s
-rw-rw-r--  1 bin       595 May 13  1975 cabs.s
-rw-rw-r--  1 bin       205 May 13  1975 ccos.f
-rw-rw-r--  1 bin       405 May 13  1975 cexp.s
-rw-rw-r--  1 bin       182 May 13  1975 clog.f
-rw-rw-r--  1 bin       361 May 13  1975 cmplx.s
-rw-rw-r--  1 bin       251 May 13  1975 conjg.s
-rw-rw-r--  1 bin       259 May 13  1975 cos.s
-rw-rw-r--  1 bin       205 May 13  1975 csin.f
-rw-rw-r--  1 bin       217 May 13  1975 csqrt.f
-rw-rw-r--  1 bin       224 May 13  1975 dble.s
-rw-rw-r--  1 bin       243 May 13  1975 dccos.f
-rw-rw-r--  1 bin       214 May 13  1975 dclog.f
-rw-rw-r--  1 bin       243 May 13  1975 dcsin.f
-rw-rw-r--  1 bin       250 May 13  1975 dcsqrt.f
-rw-rw-r--  1 bin       280 May 13  1975 dim.s
-rw-rw-r--  1 bin       225 May 13  1975 dimag.s
-rw-rw-r--  1 bin       306 May 13  1975 exp.s
-rw-rw-r--  1 bin       227 May 13  1975 float.s
-rw-rw-r--  1 bin       201 May 13  1975 iabs.s
-rw-rw-r--  1 bin       303 May 13  1975 idim.s
-rw-rw-r--  1 bin       194 May 13  1975 idint.s
-rw-rw-r--  1 bin       785 May 13  1975 ierr.s
-rw-rw-r--  1 bin       249 May 13  1975 ifix.s
-rw-rw-r--  1 bin       304 May 13  1975 isign.s
-rw-rw-r--  1 bin       337 May 13  1975 mod.s
-rw-rw-r--  1 bin       241 May 13  1975 real.s
-rw-rw-r--  1 bin       347 May 13  1975 sign.s
-rw-rw-r--  1 bin       259 May 13  1975 sin.s
-rw-rw-r--  1 bin       224 May 13  1975 sngl.s
-rw-rw-r--  1 bin       308 May 13  1975 sqrt.s
-rw-rw-r--  1 bin        75 May 13  1975 tanh.f

usr/source/fort/rt2/.
total 19
-rw-rw-r--  1 bin       196 May 13  1975 ctime.s
-rw-rw-r--  1 bin       917 May 13  1975 getarg.s
-rw-rw-r--  1 bin       219 May 13  1975 nice.s
-rw-rw-r--  1 bin       647 May 13  1975 openrw.s
-rw-rw-r--  1 bin      1772 May 13  1975 plot.s
-rw-rw-r--  1 bin       467 May 13  1975 rand.s
-rw-rw-r--  1 bin       664 May 13  1975 rio.s
-rw-rw-r--  1 bin       405 May 13  1975 setfil.s
-rw-rw-r--  1 bin      2222 May 14  1975 uio.s

usr/source/iolib/.
total 65
-rw-rw-r--  1 bin      1148 May 13  1975 alloc.c
-rw-rw-r--  1 bin        37 May 13  1975 calloc.c
-rw-rw-r--  1 bin       508 May 13  1975 cclose.c
-rw-rw-r--  1 bin       314 May 13  1975 ceof.c
-rw-rw-r--  1 bin       166 May 13  1975 cerror.c
-rw-rw-r--  1 bin       136 May 13  1975 cexit.c
-rw-rw-r--  1 bin       341 May 13  1975 cflush.c
-rw-rw-r--  1 bin        27 May 13  1975 cfree.c
-rw-rw-r--  1 bin       692 May 13  1975 cgetc.c
-rw-rw-r--  1 bin       118 May 13  1975 ciodec.c
-rw-rw-r--  1 bin       102 May 13  1975 clenf.c
-rw-rw-r--  1 bin       446 May 13  1975 copen.c
-rw-rw-r--  1 bin       601 May 13  1975 cputc.c
-rw-rw-r--  1 bin       359 May 13  1975 cwrd.c
-rw-rw-r--  1 bin        60 May 13  1975 dummy.s
-rw-rw-r--  1 bin      1766 May 13  1975 ftoa.c
-rw-rw-r--  1 bin        47 May 13  1975 getch.c
-rw-rw-r--  1 bin       251 May 13  1975 gets.c
-rw-rw-r--  1 bin        34 May 13  1975 getvec.c
-rw-rw-r--  1 bin       111 May 13  1975 iehzap.c
-rw-rw-r--  1 bin       735 May 13  1975 makbuf.c
-rw-rw-r--  1 bin       385 May 13  1975 maktab.c
-rw-rw-r--  1 bin       200 May 13  1975 nexch.c
-rw-rw-r--  1 bin       154 May 13  1975 nodig.c
-rw-rw-r--  1 bin      2276 May 13  1975 printf.c
-rw-rw-r--  1 bin        52 May 13  1975 putch.c
-rw-rw-r--  1 bin       190 May 13  1975 puts.c
-rw-rw-r--  1 bin        28 May 13  1975 relvec.c
-rw-rw-r--  1 bin       210 May 13  1975 revput.c
-rw-rw-r--  1 bin       696 May 16  1975 run
-rw-rw-r--  1 bin      2951 May 13  1975 scan1.c
-rw-rw-r--  1 bin      1675 May 13  1975 scan2.c
-rw-rw-r--  1 bin      1035 May 13  1975 scan3.c
-rw-rw-r--  1 bin       119 May 13  1975 system.c
-rw-rw-r--  1 bin        98 May 13  1975 tmpnam.c
-rw-rw-r--  1 bin       299 May 13  1975 unget.c
-rw-rw-r--  1 bin      2173 May 13  1975 unprnt.s
-rw-rw-r--  1 bin       187 May 13  1975 wdleng.c

usr/source/m6/.
total 26
-rw-rw-r--  1 bin      1753 May 13  1975 m6.h
-rw-rw-r--  1 bin       426 May 13  1975 m61.c
-rw-rw-r--  1 bin      1432 May 13  1975 m62.c
-rw-rw-r--  1 bin      1188 May 13  1975 m63.c
-rw-rw-r--  1 bin      1167 May 13  1975 m64.c
-rw-rw-r--  1 bin      1130 May 13  1975 m65.c
-rw-rw-r--  1 bin      2436 May 13  1975 m66.c
-rw-rw-r--  1 bin      1351 May 13  1975 m67.c
-rw-rw-r--  1 bin        50 May 13  1975 run

usr/source/mdec/.
total 67
-rw-rw-r--  1 bin       740 Jun 26  1975 dldr.s
-rw-rw-r--  1 bin      3794 Jun 26  1975 dtf.s
-rw-rw-r--  1 bin      2294 Jun 26  1975 fsboot.s
-rw-rw-r--  1 bin       485 Jun 26  1975 hp.s
-rw-rw-r--  1 bin       680 Jun 26  1975 ht.s
-rw-rw-r--  1 bin       645 Jun 26  1975 mak
-rw-rw-r--  1 bin      2646 Jun 26  1975 mboot.s
-rw-rw-r--  1 bin       634 Jun 26  1975 mcopy.s
-rw-rw-r--  1 bin        19 Jun 26  1975 reset.s
-rw-rw-r--  1 bin        28 Jun 26  1975 rhp.s
-rw-rw-r--  1 bin       194 Jun 26  1975 rk.s
-rw-rw-r--  1 bin       437 Jun 26  1975 rkf.s
-rw-rw-r--  1 bin       249 Jun 26  1975 rp.s
-rw-rw-r--  1 bin        27 Jun 26  1975 rrk.s
-rw-rw-r--  1 bin        27 Jun 26  1975 rrp.s
-rw-rw-r--  1 bin      1027 Jun 26  1975 run
-rw-rw-r--  1 bin      2646 Jun 26  1975 tboot.s
-rw-rw-r--  1 bin       451 Jun 26  1975 tc.s
-rw-rw-r--  1 bin      3764 Jun 26  1975 tcf.s
-rw-rw-r--  1 bin       532 Jun 26  1975 tm.s
-rw-rw-r--  1 bin      1016 Jun 26  1975 tpboot.s
-rw-rw-r--  1 bin       738 Jun 26  1975 tty.s
-rw-rw-r--  1 bin      2447 Jun 26  1975 uboot.s
-rw-rw-r--  1 bin        29 Jun 26  1975 whp.s
-rw-rw-r--  1 bin        28 Jun 26  1975 wrk.s
-rw-rw-r--  1 bin        28 Jun 26  1975 wrp.s

usr/source/rat/.
total 30
-rw-rw-r--  1 bin      5164 May 13  1975 lex.c
-rw-rw-r--  1 bin       864 May 13  1975 r.g
-rw-rw-r--  1 bin       132 May 13  1975 r.h
-rw-rw-r--  1 bin      4476 May 13  1975 r1.c
-rw-rw-r--  1 bin      1612 May 13  1975 r2.c
-rw-rw-r--  1 bin        89 May 14  1975 run

usr/source/s1/.
total 746
-rw-rw-r--  1 bin      4159 May 13  1975 ac.c
-rw-rw-r--  1 bin      5782 May 13  1975 ar.s
-rw-rw-r--  1 bin      2995 May 14  1975 banner.c
-rw-rw-r--  1 bin     23474 May 13  1975 bas.s
-rw-rw-r--  1 bin     11348 May 14  1975 bc.y
-rw-rw-r--  1 bin      1773 May 13  1975 bcd.c
-rw-rw-r--  1 bin      2606 May 13  1975 cal.c
-rw-rw-r--  1 bin       647 May 13  1975 cat.s
-rw-rw-r--  1 bin     12902 May 17  1975 cc.c
-rw-rw-r--  1 bin     14561 May 13  1975 cdb1.c
-rw-rw-r--  1 bin      6854 May 13  1975 cdb2.c
-rw-rw-r--  1 bin      1169 May 13  1975 chgrp.s
-rw-rw-r--  1 bin       381 May 13  1975 chmod.c
-rw-rw-r--  1 bin      1161 May 13  1975 chown.s
-rw-rw-r--  1 bin       737 May 13  1975 clri.s
-rw-rw-r--  1 bin      1287 May 13  1975 cmp.c
-rw-rw-r--  1 bin      1862 Jun 22  1975 col.c
-rw-rw-r--  1 bin      2122 May 13  1975 comm.c
-rw-rw-r--  1 bin      1063 May 13  1975 cp.c
-rw-rw-r--  1 bin       364 May 13  1975 cpall.c
-rw-rw-r--  1 bin      3202 May 13  1975 cron.c
-rw-rw-r--  1 bin      3020 May 13  1975 crypt.c
-rw-rw-r--  1 bin      2203 May 13  1975 date.c
-rw-rw-r--  1 bin      8758 May 13  1975 db1.s
-rw-rw-r--  1 bin      3595 May 13  1975 db2.s
-rw-rw-r--  1 bin      6575 May 13  1975 db3.s
-rw-rw-r--  1 bin       647 May 13  1975 db4.s
-rw-rw-r--  1 bin     29076 May 13  1975 dc1.s
-rw-rw-r--  1 bin      6009 May 13  1975 dc2.s
-rw-rw-r--  1 bin      5885 May 13  1975 dc3.s
-rw-rw-r--  1 bin      5396 May 13  1975 dc4.s
-rw-rw-r--  1 bin      7432 May 13  1975 dc5.s
-rw-rw-r--  1 bin      3332 May 13  1975 dcheck.c
-rw-rw-r--  1 bin      7702 May 13  1975 dd.c
-rw-rw-r--  1 bin      1282 May 13  1975 df.c
-rw-rw-r--  1 bin      9373 May 13  1975 diff1.c
-rw-rw-r--  1 bin       736 May 13  1975 diff2.s
-rw-rw-r--  1 bin      1037 May 13  1975 dsw.s
-rw-rw-r--  1 bin      2113 May 13  1975 du.s
-rw-rw-r--  1 bin      6751 May 13  1975 dump.c
-rw-rw-r--  1 bin       134 May 13  1975 echo.c
-rw-rw-r--  1 bin     17889 May 13  1975 ed.c
-rw-rw-r--  1 bin        53 May 13  1975 exit.c
-rw-rw-r--  1 bin      6864 May 13  1975 fc.c
-rw-rw-r--  1 bin      1201 May 13  1975 fed1.s
-rw-rw-r--  1 bin      5766 May 13  1975 fed2.s
-rw-rw-r--  1 bin      4192 May 13  1975 fed3.s
-rw-rw-r--  1 bin      4181 May 13  1975 file.c
-rw-rw-r--  1 bin      9159 May 13  1975 find.c
-rw-rw-r--  1 bin      2116 May 13  1975 form1.s
-rw-rw-r--  1 bin      1019 May 13  1975 form2.s
-rw-rw-r--  1 bin      1685 May 13  1975 form3.s
-rw-rw-r--  1 bin      2820 May 13  1975 form4.s
-rw-rw-r--  1 bin      9729 May 13  1975 form5.s
-rw-rw-r--  1 bin      6478 May 13  1975 form6.s
-rw-rw-r--  1 bin      3291 May 13  1975 getty.c
-rw-rw-r--  1 bin      3698 May 13  1975 glob.c
-rw-rw-r--  1 bin       844 May 13  1975 goto.c
-rw-rw-r--  1 bin      4618 May 13  1975 grep.c
-rw-rw-r--  1 bin      3951 May 13  1975 gsi.c
-rw-rw-r--  1 bin      5050 May 13  1975 icheck.c
-rw-rw-r--  1 bin      1971 May 13  1975 if.c
-rw-rw-r--  1 bin      3058 May 13  1975 init.c
-rw-rw-r--  1 bin       730 May 13  1975 kill.s
-rw-rw-r--  1 bin     15577 May 13  1975 ld.c
-rw-rw-r--  1 bin       686 May 13  1975 ln.c
-rw-rw-r--  1 bin      3017 May 13  1975 login.c
-rw-rw-r--  1 bin      2421 May 13  1975 lpd.s
-rw-rw-r--  1 bin      3366 May 13  1975 lpr.c
-rw-rw-r--  1 bin      7663 May 13  1975 ls.c
-rw-rw-r--  1 bin      2231 Jun 22  1975 run

usr/source/s2/.
total 393
-rw-rw-r--  1 bin      4155 May 13  1975 mail.c
-rw-rw-r--  1 bin       662 May 13  1975 mesg.c
-rw-rw-r--  1 bin      1088 May 13  1975 mkdir.s
-rw-rw-r--  1 bin      7581 May 13  1975 mkfs.c
-rw-rw-r--  1 bin       563 May 13  1975 mknod.c
-rw-rw-r--  1 bin      1155 May 13  1975 mount.c
-rw-rw-r--  1 bin      2996 May 13  1975 mv.c
-rw-rw-r--  1 bin      4398 May 13  1975 ncheck.c
-rw-rw-r--  1 bin      2123 May 13  1975 newgrp.c
-rw-rw-r--  1 bin       640 May 13  1975 nice.c
-rw-rw-r--  1 bin      2100 May 13  1975 nm.c
-rw-rw-r--  1 bin       530 May 13  1975 nohup.c
-rw-rw-r--  1 bin      7157 May 13  1975 od.c
-rw-rw-r--  1 bin       464 May 13  1975 opr.c
-rw-rw-r--  1 bin      2295 May 13  1975 passwd.c
-rw-rw-r--  1 bin       492 May 13  1975 pfe.s
-rw-rw-r--  1 bin      5895 May 13  1975 pr.c
-rw-rw-r--  1 bin      5486 May 13  1975 prof.c
-rw-rw-r--  1 bin      4570 May 13  1975 ps.c
-rw-rw-r--  1 bin      3260 May 13  1975 ptx.c
-rw-rw-r--  1 bin      1199 May 13  1975 pwd.c
-rw-rw-r--  1 bin      6062 May 13  1975 quiz.c
-rw-rw-r--  1 bin      5969 May 13  1975 rc.c
-rw-rw-r--  1 bin      7810 May 13  1975 restor.c
-rw-rw-r--  1 bin       451 May 13  1975 rew.s
-rw-rw-r--  1 bin      1483 May 13  1975 rm.c
-rw-rw-r--  1 bin      1197 May 13  1975 rmdir.s
-rw-rw-r--  1 bin      2153 May 14  1975 run
-rw-rw-r--  1 bin      6921 May 13  1975 sa.c
-rw-rw-r--  1 bin     11645 May 13  1975 sh.c
-rw-rw-r--  1 bin       580 May 13  1975 size.c
-rw-rw-r--  1 bin       255 May 13  1975 sleep.c
-rw-rw-r--  1 bin      8973 May 13  1975 sort.c
-rw-rw-r--  1 bin      1242 May 13  1975 split.c
-rw-rw-r--  1 bin      1725 May 13  1975 strip.s
-rw-rw-r--  1 bin      3678 May 13  1975 stty.c
-rw-rw-r--  1 bin       741 May 13  1975 su.c
-rw-rw-r--  1 bin       836 May 13  1975 sum.s
-rw-rw-r--  1 bin        21 May 13  1975 sync.c
-rw-rw-r--  1 bin      6282 May 13  1975 tbl.c
-rw-rw-r--  1 bin       696 May 13  1975 tee.c
-rw-rw-r--  1 bin      2342 May 13  1975 time.s
-rw-rw-r--  1 bin      2763 May 13  1975 tp1.s
-rw-rw-r--  1 bin      4828 May 13  1975 tp2.s
-rw-rw-r--  1 bin      5844 May 13  1975 tp3.s
-rw-rw-r--  1 bin       603 May 13  1975 tp4.s
-rw-rw-r--  1 bin      2395 May 13  1975 tr.c
-rw-rw-r--  1 bin       151 May 13  1975 tty.s
-rw-rw-r--  1 bin      6533 May 13  1975 typo.c
-rw-rw-r--  1 bin       940 May 13  1975 umount.c
-rw-rw-r--  1 bin      1955 May 13  1975 uniq.c
-rw-rw-r--  1 bin      6075 May 13  1975 units.c
-rw-rw-r--  1 bin       161 May 13  1975 update.s
-rw-rw-r--  1 bin      8936 May 13  1975 usort.c
-rw-rw-r--  1 bin       949 May 13  1975 wall.c
-rw-rw-r--  1 bin      1229 May 13  1975 wc.c
-rw-rw-r--  1 bin       954 May 13  1975 who.c
-rw-rw-r--  1 bin      2174 May 13  1975 write.s

usr/source/s3/.
total 82
-rw-rw-r--  1 bin      2587 May 13  1975 atan.s
-rw-rw-r--  1 bin      2082 May 13  1975 crypt.s
-rw-rw-r--  1 bin       211 May 13  1975 dpadd.s
-rw-rw-r--  1 bin      1958 May 13  1975 ecvt.s
-rw-rw-r--  1 bin      1917 May 13  1975 exp.s
-rw-rw-r--  1 bin       134 May 13  1975 fakfp.s
-rw-rw-r--  1 bin       385 May 13  1975 floor.s
-rw-rw-r--  1 bin       265 May 13  1975 fmod.s
-rw-rw-r--  1 bin      4506 May 13  1975 fp1.s
-rw-rw-r--  1 bin      1945 May 13  1975 fp2.s
-rw-rw-r--  1 bin      3385 May 13  1975 fp3.s
-rw-rw-r--  1 bin       332 May 13  1975 fpx.s
-rw-rw-r--  1 bin      4230 May 13  1975 gamma.s
-rw-rw-r--  1 bin      1267 May 13  1975 get.s
-rw-rw-r--  1 bin       233 May 13  1975 ldiv.s
-rw-rw-r--  1 bin      1802 May 13  1975 log.s
-rw-rw-r--  1 bin       318 May 13  1975 mesg.s
-rw-rw-r--  1 bin       552 May 13  1975 pow.s
-rw-rw-r--  1 bin      1246 May 13  1975 put.s
-rw-rw-r--  1 bin       290 May 13  1975 rand.s
-rw-rw-r--  1 bin       618 May 14  1975 run
-rw-rw-r--  1 bin        84 May 13  1975 savr5.s
-rw-rw-r--  1 bin      2012 May 13  1975 sin.s
-rw-rw-r--  1 bin       719 May 13  1975 sqrt.s
-rw-rw-r--  1 bin       508 May 13  1975 switch.s
-rw-rw-r--  1 bin       583 May 13  1975 ttyn.s

usr/source/s4/.
total 63
-rw-rw-r--  1 bin       105 May 13  1975 abort.s
-rw-rw-r--  1 bin       165 May 13  1975 abs.s
-rw-rw-r--  1 bin      2464 May 13  1975 alloc.s
-rw-rw-r--  1 bin      1232 May 13  1975 atof.s
-rw-rw-r--  1 bin       268 May 13  1975 atoi.c
-rw-rw-r--  1 bin       151 May 13  1975 cerror.s
-rw-rw-r--  1 bin       208 May 13  1975 chdir.s
-rw-rw-r--  1 bin       234 May 13  1975 chmod.s
-rw-rw-r--  1 bin       235 May 13  1975 chown.s
-rw-rw-r--  1 bin       181 May 13  1975 close.s
-rw-rw-r--  1 bin       249 May 13  1975 creat.s
-rw-rw-r--  1 bin       200 May 13  1975 crt0.s
-rw-rw-r--  1 bin       255 May 13  1975 csv.s
-rw-rw-r--  1 bin      4367 May 13  1975 ctime.c
-rw-rw-r--  1 bin       186 May 13  1975 dup.s
-rw-rw-r--  1 bin       772 May 13  1975 errlst.c
-rw-rw-r--  1 bin       218 May 13  1975 execl.s
-rw-rw-r--  1 bin       531 May 13  1975 execv.s
-rw-rw-r--  1 bin       139 May 13  1975 exit.s
-rw-rw-r--  1 bin       271 May 13  1975 fcrt0.s
-rw-rw-r--  1 bin       116 May 13  1975 ffltpr.s
-rw-rw-r--  1 bin       924 May 13  1975 fltpr.s
-rw-rw-r--  1 bin       321 May 13  1975 fork.s
-rw-rw-r--  1 bin       287 May 13  1975 fstat.s
-rw-rw-r--  1 bin       957 May 13  1975 getc.s
-rw-rw-r--  1 bin       395 May 13  1975 getchr.s
-rw-rw-r--  1 bin       122 May 13  1975 getcsw.s
-rw-rw-r--  1 bin       141 May 13  1975 getgid.s
-rw-rw-r--  1 bin       127 May 13  1975 getpid.s
-rw-rw-r--  1 bin       605 May 13  1975 getpw.c
-rw-rw-r--  1 bin       128 May 13  1975 getuid.s
-rw-rw-r--  1 bin       304 May 13  1975 gtty.s
-rw-rw-r--  1 bin        57 May 13  1975 hmul.s
-rw-rw-r--  1 bin       218 May 13  1975 kill.s
-rw-rw-r--  1 bin       480 May 13  1975 ladd.s
-rw-rw-r--  1 bin       121 May 13  1975 ldfps.s
-rw-rw-r--  1 bin       237 May 13  1975 link.s
-rw-rw-r--  1 bin       559 May 13  1975 locv.s
-rw-rw-r--  1 bin       332 May 13  1975 ltod.s
-rw-rw-r--  1 bin      1040 May 16  1975 run

usr/source/s5/.
total 59
-rw-rw-r--  1 bin       213 May 13  1975 makdir.s
-rw-rw-r--  1 bin       222 May 13  1975 mcount.s
-rw-rw-r--  1 bin       770 May 13  1975 mcrt0.s
-rw-rw-r--  1 bin       222 May 13  1975 mdate.s
-rw-rw-r--  1 bin       279 May 13  1975 mknod.s
-rw-rw-r--  1 bin       579 May 13  1975 mon.c
-rw-rw-r--  1 bin       256 May 13  1975 mount.s
-rw-rw-r--  1 bin       780 May 13  1975 nargs.s
-rw-rw-r--  1 bin       176 May 13  1975 nice.s
-rw-rw-r--  1 bin      1146 May 13  1975 nlist.s
-rw-rw-r--  1 bin       246 May 13  1975 open.s
-rw-rw-r--  1 bin       487 May 13  1975 perror.c
-rw-rw-r--  1 bin       214 May 13  1975 pipe.s
-rw-rw-r--  1 bin      2298 May 13  1975 printf.s
-rw-rw-r--  1 bin       192 May 13  1975 prof.s
-rw-rw-r--  1 bin       332 May 13  1975 ptrace.s
-rw-rw-r--  1 bin      1037 May 13  1975 putc.s
-rw-rw-r--  1 bin       585 May 13  1975 putchr.s
-rw-rw-r--  1 bin      1324 May 13  1975 qsort.c
-rw-rw-r--  1 bin       291 May 13  1975 read.s
-rw-rw-r--  1 bin       423 May 13  1975 reset.s
-rw-rw-r--  1 bin       335 May 13  1975 rin.c
-rw-rw-r--  1 bin      1059 May 16  1975 run
-rw-rw-r--  1 bin       531 May 13  1975 sbrk.s
-rw-rw-r--  1 bin       248 May 13  1975 seek.s
-rw-rw-r--  1 bin       197 May 13  1975 setgid.s
-rw-rw-r--  1 bin       184 May 13  1975 setuid.s
-rw-rw-r--  1 bin      1990 May 13  1975 signal.s
-rw-rw-r--  1 bin       107 May 13  1975 sleep.s
-rw-rw-r--  1 bin       290 May 13  1975 stat.s
-rw-rw-r--  1 bin       161 May 13  1975 stime.s
-rw-rw-r--  1 bin       304 May 13  1975 stty.s
-rw-rw-r--  1 bin        89 May 13  1975 sync.s
-rw-rw-r--  1 bin       229 May 13  1975 time.s
-rw-rw-r--  1 bin       155 May 13  1975 times.s
-rw-rw-r--  1 bin       223 May 13  1975 umount.s
-rw-rw-r--  1 bin       215 May 13  1975 unlink.s
-rw-rw-r--  1 bin       347 May 13  1975 wait.s
-rw-rw-r--  1 bin       281 May 13  1975 write.s

usr/source/s7/.
total 275
-rw-rw-r--  1 bin      3476 May 13  1975 ne.g
-rw-rw-r--  1 bin       614 May 13  1975 ne.h
-rw-rw-r--  1 bin      4856 May 13  1975 ne1.c
-rw-rw-r--  1 bin      3125 May 13  1975 ne2.c
-rw-rw-r--  1 bin      2312 May 13  1975 ne3.c
-rw-rw-r--  1 bin      3539 May 13  1975 ne4.c
-rw-rw-r--  1 bin       595 May 13  1975 ne5.c
-rw-rw-r--  1 bin      1412 May 13  1975 ne6.c
-rw-rw-r--  1 bin      5039 May 13  1975 nelex.c
-rw-rw-r--  1 bin     14884 May 13  1975 nroff1.s
-rw-rw-r--  1 bin     12516 May 13  1975 nroff2.s
-rw-rw-r--  1 bin     12693 May 13  1975 nroff3.s
-rw-rw-r--  1 bin      9504 May 13  1975 nroff4.s
-rw-rw-r--  1 bin      4520 May 13  1975 nroff5.s
-rw-rw-r--  1 bin      3071 May 13  1975 nroff8.s
-rw-rw-r--  1 bin      6518 May 13  1975 roff1.s
-rw-rw-r--  1 bin      3990 May 13  1975 roff2.s
-rw-rw-r--  1 bin      4813 May 13  1975 roff3.s
-rw-rw-r--  1 bin      5149 May 13  1975 roff4.s
-rw-rw-r--  1 bin      3036 May 13  1975 roff5.s
-rw-rw-r--  1 bin      6207 May 13  1975 roff7.s
-rw-rw-r--  1 bin      1447 May 13  1975 roff8.s
-rw-rw-r--  1 bin       254 May 13  1975 run
-rw-rw-r--  1 bin     15373 May 13  1975 suftab.s

usr/source/salloc/.
total 36
-rw-rw-r--  1 bin      2406 May 13  1975 alloc1.s
-rw-rw-r--  1 bin      3289 May 13  1975 alloc2.s
-rw-rw-r--  1 bin      6056 May 13  1975 alloc3.s
-rw-rw-r--  1 bin       936 May 13  1975 altch.s
-rw-rw-r--  1 bin       291 May 13  1975 bsp.s
-rw-rw-r--  1 bin       370 May 13  1975 bword.s
-rw-rw-r--  1 bin       300 May 13  1975 getch.s
-rw-rw-r--  1 bin       747 May 13  1975 getwd.s
-rw-rw-r--  1 bin       329 May 13  1975 length.s
-rw-rw-r--  1 bin       468 May 13  1975 rewind.s
-rw-rw-r--  1 bin       288 May 13  1975 run
-rw-rw-r--  1 bin       245 May 13  1975 zero.s

usr/source/sno/.
total 51
-rw-rw-r--  1 bin        52 May 13  1975 run
-rw-rw-r--  1 bin       338 May 13  1975 sno.h
-rw-rw-r--  1 bin      6305 May 13  1975 sno1.c
-rw-rw-r--  1 bin      7723 May 13  1975 sno2.c
-rw-rw-r--  1 bin      3644 May 13  1975 sno3.c
-rw-rw-r--  1 bin      4176 May 13  1975 sno4.c

usr/source/tmg/.
total 72
-rw-rw-r--  1 bin      1321 May 14  1975 run
-rw-rw-r--  1 bin      7577 May 13  1975 tmga.s
drwxrwxr-x  2 bin      1280 May 27  1975 tmgb
-rw-rw-r--  1 bin      1989 May 13  1975 tmgc.s
-rw-rw-r--  1 bin     14863 May 13  1975 tmgl.s
-rw-rw-r--  1 bin      6751 May 13  1975 tmgl.t

usr/source/tmg/tmgb/.
total 47
-rw-rw-r--  1 bin       178 May 13  1975 any.s
-rw-rw-r--  1 bin       165 May 13  1975 append.s
-rw-rw-r--  1 bin       787 May 13  1975 arith.s
-rw-rw-r--  1 bin       246 May 13  1975 bundle.s
-rw-rw-r--  1 bin       183 May 13  1975 char.s
-rw-rw-r--  1 bin       446 May 13  1975 copy.s
-rw-rw-r--  1 bin      1116 May 13  1975 cstr.s
-rw-rw-r--  1 bin       237 May 13  1975 ctest.s
-rw-rw-r--  1 bin       208 May 13  1975 decmal.s
-rw-rw-r--  1 bin       109 May 13  1975 discd.s
-rw-rw-r--  1 bin       592 May 13  1975 emit.s
-rw-rw-r--  1 bin        60 May 13  1975 end.s
-rw-rw-r--  1 bin       163 May 13  1975 f.s
-rw-rw-r--  1 bin      1328 May 13  1975 find.s
-rw-rw-r--  1 bin       612 May 13  1975 getnam.s
-rw-rw-r--  1 bin        94 May 13  1975 ignore.s
-rw-rw-r--  1 bin       238 May 13  1975 inc.s
-rw-rw-r--  1 bin       300 May 13  1975 infix.s
-rw-rw-r--  1 bin       470 May 13  1975 jget.s
-rw-rw-r--  1 bin       124 May 13  1975 lvrv.s
-rw-rw-r--  1 bin       249 May 13  1975 mult.s
-rw-rw-r--  1 bin       204 May 13  1975 octal.s
-rw-rw-r--  1 bin       142 May 13  1975 params.s
-rw-rw-r--  1 bin       329 May 13  1975 push.s
-rw-rw-r--  1 bin       260 May 13  1975 putcal.s
-rw-rw-r--  1 bin       309 May 13  1975 putdec.s
-rw-rw-r--  1 bin       184 May 13  1975 putoct.s
-rw-rw-r--  1 bin       393 May 13  1975 px.s
-rw-rw-r--  1 bin       431 May 13  1975 reln.s
-rw-rw-r--  1 bin       120 May 13  1975 shift.s
-rw-rw-r--  1 bin      1082 May 13  1975 stack.s
-rw-rw-r--  1 bin       194 May 13  1975 string.s
-rw-rw-r--  1 bin       231 May 13  1975 table.s
-rw-rw-r--  1 bin       353 May 13  1975 tq.s
-rw-rw-r--  1 bin       156 May 13  1975 trace.s
-rw-rw-r--  1 bin        81 May 13  1975 trans.s
-rw-rw-r--  1 bin       137 May 13  1975 tx.s
-rw-rw-r--  1 bin       168 May 13  1975 unary.s

usr/source/yacc/.
total 3
drwxrwxr-x  2 bin       208 May 27  1975 lib
-rw-rw-r--  1 bin       118 May 13  1975 run
drwxrwxr-x  2 bin       272 May 27  1975 source

usr/source/yacc/lib/.
total 11
-rw-rw-r--  1 bin       112 May 13  1975 main.c
-rw-rw-r--  1 bin      3284 May 13  1975 parser.c
-rw-rw-r--  1 bin        12 May 13  1975 zacc.c
-rw-rw-r--  1 bin       481 May 13  1975 zerr.c
-rw-rw-r--  1 bin        11 May 13  1975 zinit.c

usr/source/yacc/source/.
total 100
-rw-rw-r--  1 bin      4402 May 13  1975 dextern
-rw-rw-r--  1 bin      3976 May 13  1975 y0.c
-rw-rw-r--  1 bin      6597 May 13  1975 y1.c
-rw-rw-r--  1 bin     12020 May 13  1975 y2.c
-rw-rw-r--  1 bin      9654 May 13  1975 y3.c
-rw-rw-r--  1 bin      9996 May 13  1975 y4.c
-rw-rw-r--  1 bin       572 May 13  1975 y5.c

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200406/2909f1ec/attachment-0001.html>

From clemc at ccc.com  Tue Apr  7 10:59:53 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 6 Apr 2020 20:59:53 -0400
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <CAEdTPBcfS6wvw3rJ4w8H_1nC4+zou6TxqUB3qek9Sdsbc6RqQw@mail.gmail.com>
References: <20200406221138.GA10092@minnie.tuhs.org>
 <20200406234758.GA27062@minnie.tuhs.org>
 <CAEdTPBcfS6wvw3rJ4w8H_1nC4+zou6TxqUB3qek9Sdsbc6RqQw@mail.gmail.com>
Message-ID: <CAC20D2OVA3ODmHEPq4gOL8Q4MVwW9u_wAyrWKHVrAJyZZbweNg@mail.gmail.com>

Henry/Warren -- each is an RK05 diskpack image.

UNIX  .SYS
UNIX  .SRC
XENIX1.ARC
XENIX2.ARC

He used RT-11 to copy each disk pack sequentially.   That's an ANSI VOL1
record.   Sadly it's not a full ANSI tape (long story -- it needs HDR1
records  VMS would have been able to mount it as a foreign tape.

Take of the 4 big files, and use simh/PDP-11 and mount each of the files as
a separate RK05

Clem

On Mon, Apr 6, 2020 at 8:21 PM Henry Bent <henry.r.bent at gmail.com> wrote:

> On Mon, 6 Apr 2020 at 19:48, Warren Toomey <wkt at tuhs.org> wrote:
>
>> On Tue, Apr 07, 2020 at 08:11:38AM +1000, Warren Toomey wrote:
>> > Anybody feel up for a bit of an archaeology challenge? Warner Losh is
>> > currently poking through a bunch of bits but not having much luck
>> decoding
>> > them correctly. I've put a copy here:
>> https://minnie.tuhs.org/Y5/Challenge/
>>
>> Warner has more to report:
>>
>>    set cpu 11/45 [on SimH] was the missing magic.
>>    The first two data sets are V6 system. Lots of dates around May 13,
>>    1975 for sure.
>>
>
> The second file from the tape is /usr/source from v6:
>
> usr/source/.
> total 36
> drwxrwxr-x  2 bin       368 May 27  1975 as
> drwxrwxr-x  2 bin       928 May 27  1975 c
> drwxrwxr-x  5 bin       128 May 13  1975 cref
> drwxrwxr-x 11 bin       288 May 28  1975 fort
> drwxrwxr-x  2 bin      1248 May 27  1975 iolib
> drwxrwxr-x  2 bin       320 May 27  1975 m6
> drwxrwxr-x  2 bin       448 Jun 26  1975 mdec
> drwxrwxr-x  2 bin       256 May 27  1975 rat
> -rw-rw-r--  1 bin       753 May 18  1975 run
> drwxrwxr-x  2 bin      1696 Jun 22  1975 s1
> drwxrwxr-x  2 bin      1280 May 27  1975 s2
> drwxrwxr-x  2 bin       816 May 27  1975 s3
> drwxrwxr-x  2 bin      2544 May 27  1975 s4
> drwxrwxr-x  2 bin      1264 May 27  1975 s5
> drwxrwxr-x  2 bin       800 May 27  1975 s7
> drwxrwxr-x  2 bin       384 May 27  1975 salloc
> drwxrwxr-x  2 bin       224 May 27  1975 sno
> drwxrwxr-x  3 bin       176 May 27  1975 tmg
> drwxrwxr-x  4 bin        80 May 13  1975 yacc
>
> usr/source/as/.
> total 97
> -rw-rw-r--  1 bin      1175 May 13  1975 as11.s
> -rw-rw-r--  1 bin       789 May 13  1975 as12.s
> -rw-rw-r--  1 bin      1473 May 13  1975 as13.s
> -rw-rw-r--  1 bin      2593 May 13  1975 as14.s
> -rw-rw-r--  1 bin      1615 May 13  1975 as15.s
> -rw-rw-r--  1 bin      2917 May 13  1975 as16.s
> -rw-rw-r--  1 bin      2238 May 13  1975 as17.s
> -rw-rw-r--  1 bin      1273 May 13  1975 as18.s
> -rw-rw-r--  1 bin      6755 May 13  1975 as19.s
> -rw-rw-r--  1 bin      3170 May 13  1975 as21.s
> -rw-rw-r--  1 bin      1725 May 13  1975 as22.s
> -rw-rw-r--  1 bin      1805 May 13  1975 as23.s
> -rw-rw-r--  1 bin      1390 May 13  1975 as24.s
> -rw-rw-r--  1 bin        71 May 13  1975 as25.s
> -rw-rw-r--  1 bin      6056 May 13  1975 as26.s
> -rw-rw-r--  1 bin      3178 May 13  1975 as27.s
> -rw-rw-r--  1 bin       918 May 13  1975 as28.s
> -rw-rw-r--  1 bin      3953 May 13  1975 as29.s
> -rw-rw-r--  1 bin        96 May 17  1975 run
>
> usr/source/c/.
> total 261
> -rw-rw-r--  1 bin     12150 May 13  1975 c00.c
> -rw-rw-r--  1 bin      6477 May 13  1975 c01.c
> -rw-rw-r--  1 bin     13353 May 15  1975 c02.c
> -rw-rw-r--  1 bin      2520 May 13  1975 c03.c
> -rw-rw-r--  1 bin      4255 May 13  1975 c04.c
> -rw-rw-r--  1 bin      4452 May 13  1975 c0h.c
> -rw-rw-r--  1 bin      1704 May 27  1975 c0t.s
> -rw-rw-r--  1 bin     14545 May 13  1975 c10.c
> -rw-rw-r--  1 bin      8931 May 13  1975 c11.c
> -rw-rw-r--  1 bin     10425 May 15  1975 c12.c
> -rw-rw-r--  1 bin      3036 May 13  1975 c13.c
> -rw-rw-r--  1 bin      3165 May 13  1975 c1h.c
> -rw-rw-r--  1 bin      1679 May 13  1975 c1t.s
> -rw-rw-r--  1 bin     11086 May 13  1975 c20.c
> -rw-rw-r--  1 bin      9745 May 13  1975 c21.c
> -rw-rw-r--  1 bin      1735 May 13  1975 c2h.c
> -rw-rw-r--  1 bin      4335 May 13  1975 cvopt.c
> -rw-rw-r--  1 bin       468 May 16  1975 run
> -rw-rw-r--  1 bin      8581 May 13  1975 table.s
>
> usr/source/cref/.
> total 7
> -rw-rw-r--  1 bin       861 May 13  1975 ccmn.h
> drwxrwxr-x  2 bin       192 May 27  1975 index
> -rw-rw-r--  1 bin       489 May 13  1975 mcons.h
> -rw-rw-r--  1 bin       401 May 17  1975 run
> drwxrwxr-x  2 bin       208 May 27  1975 src
> drwxrwxr-x  2 bin       224 May 27  1975 tab
>
> usr/source/cref/index/.
> total 25
> -rw-rw-r--  1 bin       744 May 13  1975 ecmn.h
> -rw-rw-r--  1 bin       362 May 13  1975 econs.h
> -rw-rw-r--  1 bin      5532 May 13  1975 ind0.c
> -rw-rw-r--  1 bin      3725 May 13  1975 ind1.c
> -rw-rw-r--  1 bin       548 May 13  1975 ind2.c
>
> usr/source/cref/src/.
> total 44
> -rw-rw-r--  1 bin      6570 May 13  1975 acts.c
> -rw-rw-r--  1 bin      3409 May 13  1975 crpost.c
> -rw-rw-r--  1 bin      7166 May 13  1975 dr.c
> -rw-rw-r--  1 bin       800 May 13  1975 put.c
> -rw-rw-r--  1 bin      2577 May 13  1975 upost.c
>
> usr/source/cref/tab/.
> total 24
> -rw-rw-r--  1 bin      3032 May 13  1975 atable
> -rw-rw-r--  1 bin      3073 May 13  1975 ctable
> -rw-rw-r--  1 bin      2371 May 13  1975 etable
> -rw-rw-r--  1 bin      3023 May 13  1975 mtab.c
>
> usr/source/fort/.
> total 24
> drwxrwxr-x  2 bin       320 May 27  1975 f1
> drwxrwxr-x  2 bin       224 May 27  1975 f2
> drwxrwxr-x  2 bin       384 May 27  1975 f3
> drwxrwxr-x  2 bin       320 May 27  1975 f4
> drwxrwxr-x  2 bin       720 May 27  1975 fx
> drwxrwxr-x  2 bin       192 May 27  1975 io
> drwxrwxr-x  2 bin       640 May 27  1975 rt
> drwxrwxr-x  2 bin      1440 May 27  1975 rt1
> drwxrwxr-x  2 bin       288 May 27  1975 rt2
> -rw-rw-r--  1 bin      3744 May 13  1975 run
> -rw-rw-r--  1 bin      1198 May 13  1975 sum.s
>
> usr/source/fort/f1/.
> total 18
> -rw-rw-r--  1 bin      1897 May 13  1975 f11.s
> -rw-rw-r--  1 bin      1220 May 13  1975 f12.s
> -rw-rw-r--  1 bin      1355 May 13  1975 f13.s
> -rw-rw-r--  1 bin      1195 May 13  1975 f14.s
> -rw-rw-r--  1 bin       945 May 13  1975 f15.s
> -rw-rw-r--  1 bin       425 May 13  1975 f16.s
> -rw-rw-r--  1 bin       799 May 13  1975 f17.s
>
> usr/source/fort/f2/.
> total 14
> -rw-rw-r--  1 bin       303 May 13  1975 f21.s
> -rw-rw-r--  1 bin      1512 May 13  1975 f22.s
> -rw-rw-r--  1 bin      2019 May 13  1975 f23.s
> -rw-rw-r--  1 bin      2722 May 13  1975 f24.s
>
> usr/source/fort/f3/.
> total 44
> -rw-rw-r--  1 bin      2001 May 13  1975 f31.s
> -rw-rw-r--  1 bin      2583 May 13  1975 f32.s
> -rw-rw-r--  1 bin      1666 May 13  1975 f33.s
> -rw-rw-r--  1 bin       752 May 13  1975 f34.s
> -rw-rw-r--  1 bin      1095 May 13  1975 f35.s
> -rw-rw-r--  1 bin      5655 May 13  1975 f36.s
> -rw-rw-r--  1 bin      1151 May 13  1975 f37.s
> -rw-rw-r--  1 bin      1051 May 13  1975 f38.s
> -rw-rw-r--  1 bin      3004 May 13  1975 f39.s
>
> usr/source/fort/f4/.
> total 26
> -rw-rw-r--  1 bin       528 May 13  1975 f41.s
> -rw-rw-r--  1 bin      1216 May 13  1975 f42.s
> -rw-rw-r--  1 bin       946 May 13  1975 f43.s
> -rw-rw-r--  1 bin      1194 May 13  1975 f44.s
> -rw-rw-r--  1 bin      1652 May 13  1975 f45.s
> -rw-rw-r--  1 bin      1676 May 13  1975 f46.s
> -rw-rw-r--  1 bin      3967 May 13  1975 f47.s
>
> usr/source/fort/fx/.
> total 54
> -rw-rw-r--  1 bin       783 May 13  1975 fhd.s
> -rw-rw-r--  1 bin       513 May 13  1975 fx1.s
> -rw-rw-r--  1 bin      1450 May 13  1975 fx2.s
> -rw-rw-r--  1 bin       589 May 13  1975 fx3.s
> -rw-rw-r--  1 bin      4158 May 13  1975 fx4.s
> -rw-rw-r--  1 bin       564 May 13  1975 fx5.s
> -rw-rw-r--  1 bin       323 May 13  1975 fx6.s
> -rw-rw-r--  1 bin       293 May 13  1975 fx7.s
> -rw-rw-r--  1 bin      2774 May 13  1975 fx8.s
> -rw-rw-r--  1 bin      1365 May 13  1975 fx9.s
> -rw-rw-r--  1 bin       397 May 13  1975 fxa.s
> -rw-rw-r--  1 bin       366 May 13  1975 fxb.s
> -rw-rw-r--  1 bin       414 May 13  1975 fxc.s
> -rw-rw-r--  1 bin       555 May 13  1975 fxd.s
> -rw-rw-r--  1 bin       299 May 13  1975 fxe.s
> -rw-rw-r--  1 bin       287 May 13  1975 fxf.s
> -rw-rw-r--  1 bin      2869 May 13  1975 fxg.s
> -rw-rw-r--  1 bin      1101 May 13  1975 fxh.s
> -rw-rw-r--  1 bin      1510 May 13  1975 fxi.s
> -rw-rw-r--  1 bin      1282 May 13  1975 fxx.s
>
> usr/source/fort/io/.
> total 31
> -rw-rw-r--  1 bin       742 May 13  1975 io1.s
> -rw-rw-r--  1 bin      2753 May 13  1975 io2.s
> -rw-rw-r--  1 bin      3161 May 13  1975 io3.s
> -rw-rw-r--  1 bin      2276 May 13  1975 io4.s
> -rw-rw-r--  1 bin       961 May 13  1975 io5.s
> -rw-rw-r--  1 bin      2268 May 13  1975 io6.s
> -rw-rw-r--  1 bin       721 May 13  1975 io7.s
> -rw-rw-r--  1 bin       603 May 13  1975 iox.s
>
> usr/source/fort/rt/.
> total 41
> -rw-rw-r--  1 bin       557 May 13  1975 r0.s
> -rw-rw-r--  1 bin      1478 May 13  1975 r1.s
> -rw-rw-r--  1 bin      1305 May 13  1975 r2.s
> -rw-rw-r--  1 bin       437 May 13  1975 r3.s
> -rw-rw-r--  1 bin       641 May 13  1975 r4.s
> -rw-rw-r--  1 bin       491 May 13  1975 r5.s
> -rw-rw-r--  1 bin      1107 May 13  1975 r6.s
> -rw-rw-r--  1 bin      1368 May 13  1975 r7.s
> -rw-rw-r--  1 bin       339 May 13  1975 r8.s
> -rw-rw-r--  1 bin       617 May 13  1975 r9.s
> -rw-rw-r--  1 bin       417 May 13  1975 ra.s
> -rw-rw-r--  1 bin       579 May 13  1975 rb.s
> -rw-rw-r--  1 bin      2934 May 13  1975 rc.s
> -rw-rw-r--  1 bin       423 May 13  1975 rd.s
> -rw-rw-r--  1 bin       547 May 13  1975 re.s
> -rw-rw-r--  1 bin       531 May 13  1975 rf.s
> -rw-rw-r--  1 bin       959 May 13  1975 rg.s
> -rw-rw-r--  1 bin      1428 May 13  1975 rh.s
> -rw-rw-r--  1 bin       106 May 13  1975 rx.s
>
> usr/source/fort/rt1/.
> total 46
> -rw-rw-r--  1 bin       245 May 13  1975 abs.s
> -rw-rw-r--  1 bin       223 May 13  1975 aimag.s
> -rw-rw-r--  1 bin       211 May 13  1975 aint.s
> -rw-rw-r--  1 bin       307 May 13  1975 alog.s
> -rw-rw-r--  1 bin       360 May 13  1975 alog10.s
> -rw-rw-r--  1 bin       450 May 13  1975 amax0.s
> -rw-rw-r--  1 bin       542 May 13  1975 amax1.s
> -rw-rw-r--  1 bin       450 May 13  1975 amin0.s
> -rw-rw-r--  1 bin       510 May 13  1975 amin1.s
> -rw-rw-r--  1 bin       384 May 13  1975 amod.s
> -rw-rw-r--  1 bin       267 May 13  1975 atan.s
> -rw-rw-r--  1 bin       345 May 13  1975 atan2.s
> -rw-rw-r--  1 bin       595 May 13  1975 cabs.s
> -rw-rw-r--  1 bin       205 May 13  1975 ccos.f
> -rw-rw-r--  1 bin       405 May 13  1975 cexp.s
> -rw-rw-r--  1 bin       182 May 13  1975 clog.f
> -rw-rw-r--  1 bin       361 May 13  1975 cmplx.s
> -rw-rw-r--  1 bin       251 May 13  1975 conjg.s
> -rw-rw-r--  1 bin       259 May 13  1975 cos.s
> -rw-rw-r--  1 bin       205 May 13  1975 csin.f
> -rw-rw-r--  1 bin       217 May 13  1975 csqrt.f
> -rw-rw-r--  1 bin       224 May 13  1975 dble.s
> -rw-rw-r--  1 bin       243 May 13  1975 dccos.f
> -rw-rw-r--  1 bin       214 May 13  1975 dclog.f
> -rw-rw-r--  1 bin       243 May 13  1975 dcsin.f
> -rw-rw-r--  1 bin       250 May 13  1975 dcsqrt.f
> -rw-rw-r--  1 bin       280 May 13  1975 dim.s
> -rw-rw-r--  1 bin       225 May 13  1975 dimag.s
> -rw-rw-r--  1 bin       306 May 13  1975 exp.s
> -rw-rw-r--  1 bin       227 May 13  1975 float.s
> -rw-rw-r--  1 bin       201 May 13  1975 iabs.s
> -rw-rw-r--  1 bin       303 May 13  1975 idim.s
> -rw-rw-r--  1 bin       194 May 13  1975 idint.s
> -rw-rw-r--  1 bin       785 May 13  1975 ierr.s
> -rw-rw-r--  1 bin       249 May 13  1975 ifix.s
> -rw-rw-r--  1 bin       304 May 13  1975 isign.s
> -rw-rw-r--  1 bin       337 May 13  1975 mod.s
> -rw-rw-r--  1 bin       241 May 13  1975 real.s
> -rw-rw-r--  1 bin       347 May 13  1975 sign.s
> -rw-rw-r--  1 bin       259 May 13  1975 sin.s
> -rw-rw-r--  1 bin       224 May 13  1975 sngl.s
> -rw-rw-r--  1 bin       308 May 13  1975 sqrt.s
> -rw-rw-r--  1 bin        75 May 13  1975 tanh.f
>
> usr/source/fort/rt2/.
> total 19
> -rw-rw-r--  1 bin       196 May 13  1975 ctime.s
> -rw-rw-r--  1 bin       917 May 13  1975 getarg.s
> -rw-rw-r--  1 bin       219 May 13  1975 nice.s
> -rw-rw-r--  1 bin       647 May 13  1975 openrw.s
> -rw-rw-r--  1 bin      1772 May 13  1975 plot.s
> -rw-rw-r--  1 bin       467 May 13  1975 rand.s
> -rw-rw-r--  1 bin       664 May 13  1975 rio.s
> -rw-rw-r--  1 bin       405 May 13  1975 setfil.s
> -rw-rw-r--  1 bin      2222 May 14  1975 uio.s
>
> usr/source/iolib/.
> total 65
> -rw-rw-r--  1 bin      1148 May 13  1975 alloc.c
> -rw-rw-r--  1 bin        37 May 13  1975 calloc.c
> -rw-rw-r--  1 bin       508 May 13  1975 cclose.c
> -rw-rw-r--  1 bin       314 May 13  1975 ceof.c
> -rw-rw-r--  1 bin       166 May 13  1975 cerror.c
> -rw-rw-r--  1 bin       136 May 13  1975 cexit.c
> -rw-rw-r--  1 bin       341 May 13  1975 cflush.c
> -rw-rw-r--  1 bin        27 May 13  1975 cfree.c
> -rw-rw-r--  1 bin       692 May 13  1975 cgetc.c
> -rw-rw-r--  1 bin       118 May 13  1975 ciodec.c
> -rw-rw-r--  1 bin       102 May 13  1975 clenf.c
> -rw-rw-r--  1 bin       446 May 13  1975 copen.c
> -rw-rw-r--  1 bin       601 May 13  1975 cputc.c
> -rw-rw-r--  1 bin       359 May 13  1975 cwrd.c
> -rw-rw-r--  1 bin        60 May 13  1975 dummy.s
> -rw-rw-r--  1 bin      1766 May 13  1975 ftoa.c
> -rw-rw-r--  1 bin        47 May 13  1975 getch.c
> -rw-rw-r--  1 bin       251 May 13  1975 gets.c
> -rw-rw-r--  1 bin        34 May 13  1975 getvec.c
> -rw-rw-r--  1 bin       111 May 13  1975 iehzap.c
> -rw-rw-r--  1 bin       735 May 13  1975 makbuf.c
> -rw-rw-r--  1 bin       385 May 13  1975 maktab.c
> -rw-rw-r--  1 bin       200 May 13  1975 nexch.c
> -rw-rw-r--  1 bin       154 May 13  1975 nodig.c
> -rw-rw-r--  1 bin      2276 May 13  1975 printf.c
> -rw-rw-r--  1 bin        52 May 13  1975 putch.c
> -rw-rw-r--  1 bin       190 May 13  1975 puts.c
> -rw-rw-r--  1 bin        28 May 13  1975 relvec.c
> -rw-rw-r--  1 bin       210 May 13  1975 revput.c
> -rw-rw-r--  1 bin       696 May 16  1975 run
> -rw-rw-r--  1 bin      2951 May 13  1975 scan1.c
> -rw-rw-r--  1 bin      1675 May 13  1975 scan2.c
> -rw-rw-r--  1 bin      1035 May 13  1975 scan3.c
> -rw-rw-r--  1 bin       119 May 13  1975 system.c
> -rw-rw-r--  1 bin        98 May 13  1975 tmpnam.c
> -rw-rw-r--  1 bin       299 May 13  1975 unget.c
> -rw-rw-r--  1 bin      2173 May 13  1975 unprnt.s
> -rw-rw-r--  1 bin       187 May 13  1975 wdleng.c
>
> usr/source/m6/.
> total 26
> -rw-rw-r--  1 bin      1753 May 13  1975 m6.h
> -rw-rw-r--  1 bin       426 May 13  1975 m61.c
> -rw-rw-r--  1 bin      1432 May 13  1975 m62.c
> -rw-rw-r--  1 bin      1188 May 13  1975 m63.c
> -rw-rw-r--  1 bin      1167 May 13  1975 m64.c
> -rw-rw-r--  1 bin      1130 May 13  1975 m65.c
> -rw-rw-r--  1 bin      2436 May 13  1975 m66.c
> -rw-rw-r--  1 bin      1351 May 13  1975 m67.c
> -rw-rw-r--  1 bin        50 May 13  1975 run
>
> usr/source/mdec/.
> total 67
> -rw-rw-r--  1 bin       740 Jun 26  1975 dldr.s
> -rw-rw-r--  1 bin      3794 Jun 26  1975 dtf.s
> -rw-rw-r--  1 bin      2294 Jun 26  1975 fsboot.s
> -rw-rw-r--  1 bin       485 Jun 26  1975 hp.s
> -rw-rw-r--  1 bin       680 Jun 26  1975 ht.s
> -rw-rw-r--  1 bin       645 Jun 26  1975 mak
> -rw-rw-r--  1 bin      2646 Jun 26  1975 mboot.s
> -rw-rw-r--  1 bin       634 Jun 26  1975 mcopy.s
> -rw-rw-r--  1 bin        19 Jun 26  1975 reset.s
> -rw-rw-r--  1 bin        28 Jun 26  1975 rhp.s
> -rw-rw-r--  1 bin       194 Jun 26  1975 rk.s
> -rw-rw-r--  1 bin       437 Jun 26  1975 rkf.s
> -rw-rw-r--  1 bin       249 Jun 26  1975 rp.s
> -rw-rw-r--  1 bin        27 Jun 26  1975 rrk.s
> -rw-rw-r--  1 bin        27 Jun 26  1975 rrp.s
> -rw-rw-r--  1 bin      1027 Jun 26  1975 run
> -rw-rw-r--  1 bin      2646 Jun 26  1975 tboot.s
> -rw-rw-r--  1 bin       451 Jun 26  1975 tc.s
> -rw-rw-r--  1 bin      3764 Jun 26  1975 tcf.s
> -rw-rw-r--  1 bin       532 Jun 26  1975 tm.s
> -rw-rw-r--  1 bin      1016 Jun 26  1975 tpboot.s
> -rw-rw-r--  1 bin       738 Jun 26  1975 tty.s
> -rw-rw-r--  1 bin      2447 Jun 26  1975 uboot.s
> -rw-rw-r--  1 bin        29 Jun 26  1975 whp.s
> -rw-rw-r--  1 bin        28 Jun 26  1975 wrk.s
> -rw-rw-r--  1 bin        28 Jun 26  1975 wrp.s
>
> usr/source/rat/.
> total 30
> -rw-rw-r--  1 bin      5164 May 13  1975 lex.c
> -rw-rw-r--  1 bin       864 May 13  1975 r.g
> -rw-rw-r--  1 bin       132 May 13  1975 r.h
> -rw-rw-r--  1 bin      4476 May 13  1975 r1.c
> -rw-rw-r--  1 bin      1612 May 13  1975 r2.c
> -rw-rw-r--  1 bin        89 May 14  1975 run
>
> usr/source/s1/.
> total 746
> -rw-rw-r--  1 bin      4159 May 13  1975 ac.c
> -rw-rw-r--  1 bin      5782 May 13  1975 ar.s
> -rw-rw-r--  1 bin      2995 May 14  1975 banner.c
> -rw-rw-r--  1 bin     23474 May 13  1975 bas.s
> -rw-rw-r--  1 bin     11348 May 14  1975 bc.y
> -rw-rw-r--  1 bin      1773 May 13  1975 bcd.c
> -rw-rw-r--  1 bin      2606 May 13  1975 cal.c
> -rw-rw-r--  1 bin       647 May 13  1975 cat.s
> -rw-rw-r--  1 bin     12902 May 17  1975 cc.c
> -rw-rw-r--  1 bin     14561 May 13  1975 cdb1.c
> -rw-rw-r--  1 bin      6854 May 13  1975 cdb2.c
> -rw-rw-r--  1 bin      1169 May 13  1975 chgrp.s
> -rw-rw-r--  1 bin       381 May 13  1975 chmod.c
> -rw-rw-r--  1 bin      1161 May 13  1975 chown.s
> -rw-rw-r--  1 bin       737 May 13  1975 clri.s
> -rw-rw-r--  1 bin      1287 May 13  1975 cmp.c
> -rw-rw-r--  1 bin      1862 Jun 22  1975 col.c
> -rw-rw-r--  1 bin      2122 May 13  1975 comm.c
> -rw-rw-r--  1 bin      1063 May 13  1975 cp.c
> -rw-rw-r--  1 bin       364 May 13  1975 cpall.c
> -rw-rw-r--  1 bin      3202 May 13  1975 cron.c
> -rw-rw-r--  1 bin      3020 May 13  1975 crypt.c
> -rw-rw-r--  1 bin      2203 May 13  1975 date.c
> -rw-rw-r--  1 bin      8758 May 13  1975 db1.s
> -rw-rw-r--  1 bin      3595 May 13  1975 db2.s
> -rw-rw-r--  1 bin      6575 May 13  1975 db3.s
> -rw-rw-r--  1 bin       647 May 13  1975 db4.s
> -rw-rw-r--  1 bin     29076 May 13  1975 dc1.s
> -rw-rw-r--  1 bin      6009 May 13  1975 dc2.s
> -rw-rw-r--  1 bin      5885 May 13  1975 dc3.s
> -rw-rw-r--  1 bin      5396 May 13  1975 dc4.s
> -rw-rw-r--  1 bin      7432 May 13  1975 dc5.s
> -rw-rw-r--  1 bin      3332 May 13  1975 dcheck.c
> -rw-rw-r--  1 bin      7702 May 13  1975 dd.c
> -rw-rw-r--  1 bin      1282 May 13  1975 df.c
> -rw-rw-r--  1 bin      9373 May 13  1975 diff1.c
> -rw-rw-r--  1 bin       736 May 13  1975 diff2.s
> -rw-rw-r--  1 bin      1037 May 13  1975 dsw.s
> -rw-rw-r--  1 bin      2113 May 13  1975 du.s
> -rw-rw-r--  1 bin      6751 May 13  1975 dump.c
> -rw-rw-r--  1 bin       134 May 13  1975 echo.c
> -rw-rw-r--  1 bin     17889 May 13  1975 ed.c
> -rw-rw-r--  1 bin        53 May 13  1975 exit.c
> -rw-rw-r--  1 bin      6864 May 13  1975 fc.c
> -rw-rw-r--  1 bin      1201 May 13  1975 fed1.s
> -rw-rw-r--  1 bin      5766 May 13  1975 fed2.s
> -rw-rw-r--  1 bin      4192 May 13  1975 fed3.s
> -rw-rw-r--  1 bin      4181 May 13  1975 file.c
> -rw-rw-r--  1 bin      9159 May 13  1975 find.c
> -rw-rw-r--  1 bin      2116 May 13  1975 form1.s
> -rw-rw-r--  1 bin      1019 May 13  1975 form2.s
> -rw-rw-r--  1 bin      1685 May 13  1975 form3.s
> -rw-rw-r--  1 bin      2820 May 13  1975 form4.s
> -rw-rw-r--  1 bin      9729 May 13  1975 form5.s
> -rw-rw-r--  1 bin      6478 May 13  1975 form6.s
> -rw-rw-r--  1 bin      3291 May 13  1975 getty.c
> -rw-rw-r--  1 bin      3698 May 13  1975 glob.c
> -rw-rw-r--  1 bin       844 May 13  1975 goto.c
> -rw-rw-r--  1 bin      4618 May 13  1975 grep.c
> -rw-rw-r--  1 bin      3951 May 13  1975 gsi.c
> -rw-rw-r--  1 bin      5050 May 13  1975 icheck.c
> -rw-rw-r--  1 bin      1971 May 13  1975 if.c
> -rw-rw-r--  1 bin      3058 May 13  1975 init.c
> -rw-rw-r--  1 bin       730 May 13  1975 kill.s
> -rw-rw-r--  1 bin     15577 May 13  1975 ld.c
> -rw-rw-r--  1 bin       686 May 13  1975 ln.c
> -rw-rw-r--  1 bin      3017 May 13  1975 login.c
> -rw-rw-r--  1 bin      2421 May 13  1975 lpd.s
> -rw-rw-r--  1 bin      3366 May 13  1975 lpr.c
> -rw-rw-r--  1 bin      7663 May 13  1975 ls.c
> -rw-rw-r--  1 bin      2231 Jun 22  1975 run
>
> usr/source/s2/.
> total 393
> -rw-rw-r--  1 bin      4155 May 13  1975 mail.c
> -rw-rw-r--  1 bin       662 May 13  1975 mesg.c
> -rw-rw-r--  1 bin      1088 May 13  1975 mkdir.s
> -rw-rw-r--  1 bin      7581 May 13  1975 mkfs.c
> -rw-rw-r--  1 bin       563 May 13  1975 mknod.c
> -rw-rw-r--  1 bin      1155 May 13  1975 mount.c
> -rw-rw-r--  1 bin      2996 May 13  1975 mv.c
> -rw-rw-r--  1 bin      4398 May 13  1975 ncheck.c
> -rw-rw-r--  1 bin      2123 May 13  1975 newgrp.c
> -rw-rw-r--  1 bin       640 May 13  1975 nice.c
> -rw-rw-r--  1 bin      2100 May 13  1975 nm.c
> -rw-rw-r--  1 bin       530 May 13  1975 nohup.c
> -rw-rw-r--  1 bin      7157 May 13  1975 od.c
> -rw-rw-r--  1 bin       464 May 13  1975 opr.c
> -rw-rw-r--  1 bin      2295 May 13  1975 passwd.c
> -rw-rw-r--  1 bin       492 May 13  1975 pfe.s
> -rw-rw-r--  1 bin      5895 May 13  1975 pr.c
> -rw-rw-r--  1 bin      5486 May 13  1975 prof.c
> -rw-rw-r--  1 bin      4570 May 13  1975 ps.c
> -rw-rw-r--  1 bin      3260 May 13  1975 ptx.c
> -rw-rw-r--  1 bin      1199 May 13  1975 pwd.c
> -rw-rw-r--  1 bin      6062 May 13  1975 quiz.c
> -rw-rw-r--  1 bin      5969 May 13  1975 rc.c
> -rw-rw-r--  1 bin      7810 May 13  1975 restor.c
> -rw-rw-r--  1 bin       451 May 13  1975 rew.s
> -rw-rw-r--  1 bin      1483 May 13  1975 rm.c
> -rw-rw-r--  1 bin      1197 May 13  1975 rmdir.s
> -rw-rw-r--  1 bin      2153 May 14  1975 run
> -rw-rw-r--  1 bin      6921 May 13  1975 sa.c
> -rw-rw-r--  1 bin     11645 May 13  1975 sh.c
> -rw-rw-r--  1 bin       580 May 13  1975 size.c
> -rw-rw-r--  1 bin       255 May 13  1975 sleep.c
> -rw-rw-r--  1 bin      8973 May 13  1975 sort.c
> -rw-rw-r--  1 bin      1242 May 13  1975 split.c
> -rw-rw-r--  1 bin      1725 May 13  1975 strip.s
> -rw-rw-r--  1 bin      3678 May 13  1975 stty.c
> -rw-rw-r--  1 bin       741 May 13  1975 su.c
> -rw-rw-r--  1 bin       836 May 13  1975 sum.s
> -rw-rw-r--  1 bin        21 May 13  1975 sync.c
> -rw-rw-r--  1 bin      6282 May 13  1975 tbl.c
> -rw-rw-r--  1 bin       696 May 13  1975 tee.c
> -rw-rw-r--  1 bin      2342 May 13  1975 time.s
> -rw-rw-r--  1 bin      2763 May 13  1975 tp1.s
> -rw-rw-r--  1 bin      4828 May 13  1975 tp2.s
> -rw-rw-r--  1 bin      5844 May 13  1975 tp3.s
> -rw-rw-r--  1 bin       603 May 13  1975 tp4.s
> -rw-rw-r--  1 bin      2395 May 13  1975 tr.c
> -rw-rw-r--  1 bin       151 May 13  1975 tty.s
> -rw-rw-r--  1 bin      6533 May 13  1975 typo.c
> -rw-rw-r--  1 bin       940 May 13  1975 umount.c
> -rw-rw-r--  1 bin      1955 May 13  1975 uniq.c
> -rw-rw-r--  1 bin      6075 May 13  1975 units.c
> -rw-rw-r--  1 bin       161 May 13  1975 update.s
> -rw-rw-r--  1 bin      8936 May 13  1975 usort.c
> -rw-rw-r--  1 bin       949 May 13  1975 wall.c
> -rw-rw-r--  1 bin      1229 May 13  1975 wc.c
> -rw-rw-r--  1 bin       954 May 13  1975 who.c
> -rw-rw-r--  1 bin      2174 May 13  1975 write.s
>
> usr/source/s3/.
> total 82
> -rw-rw-r--  1 bin      2587 May 13  1975 atan.s
> -rw-rw-r--  1 bin      2082 May 13  1975 crypt.s
> -rw-rw-r--  1 bin       211 May 13  1975 dpadd.s
> -rw-rw-r--  1 bin      1958 May 13  1975 ecvt.s
> -rw-rw-r--  1 bin      1917 May 13  1975 exp.s
> -rw-rw-r--  1 bin       134 May 13  1975 fakfp.s
> -rw-rw-r--  1 bin       385 May 13  1975 floor.s
> -rw-rw-r--  1 bin       265 May 13  1975 fmod.s
> -rw-rw-r--  1 bin      4506 May 13  1975 fp1.s
> -rw-rw-r--  1 bin      1945 May 13  1975 fp2.s
> -rw-rw-r--  1 bin      3385 May 13  1975 fp3.s
> -rw-rw-r--  1 bin       332 May 13  1975 fpx.s
> -rw-rw-r--  1 bin      4230 May 13  1975 gamma.s
> -rw-rw-r--  1 bin      1267 May 13  1975 get.s
> -rw-rw-r--  1 bin       233 May 13  1975 ldiv.s
> -rw-rw-r--  1 bin      1802 May 13  1975 log.s
> -rw-rw-r--  1 bin       318 May 13  1975 mesg.s
> -rw-rw-r--  1 bin       552 May 13  1975 pow.s
> -rw-rw-r--  1 bin      1246 May 13  1975 put.s
> -rw-rw-r--  1 bin       290 May 13  1975 rand.s
> -rw-rw-r--  1 bin       618 May 14  1975 run
> -rw-rw-r--  1 bin        84 May 13  1975 savr5.s
> -rw-rw-r--  1 bin      2012 May 13  1975 sin.s
> -rw-rw-r--  1 bin       719 May 13  1975 sqrt.s
> -rw-rw-r--  1 bin       508 May 13  1975 switch.s
> -rw-rw-r--  1 bin       583 May 13  1975 ttyn.s
>
> usr/source/s4/.
> total 63
> -rw-rw-r--  1 bin       105 May 13  1975 abort.s
> -rw-rw-r--  1 bin       165 May 13  1975 abs.s
> -rw-rw-r--  1 bin      2464 May 13  1975 alloc.s
> -rw-rw-r--  1 bin      1232 May 13  1975 atof.s
> -rw-rw-r--  1 bin       268 May 13  1975 atoi.c
> -rw-rw-r--  1 bin       151 May 13  1975 cerror.s
> -rw-rw-r--  1 bin       208 May 13  1975 chdir.s
> -rw-rw-r--  1 bin       234 May 13  1975 chmod.s
> -rw-rw-r--  1 bin       235 May 13  1975 chown.s
> -rw-rw-r--  1 bin       181 May 13  1975 close.s
> -rw-rw-r--  1 bin       249 May 13  1975 creat.s
> -rw-rw-r--  1 bin       200 May 13  1975 crt0.s
> -rw-rw-r--  1 bin       255 May 13  1975 csv.s
> -rw-rw-r--  1 bin      4367 May 13  1975 ctime.c
> -rw-rw-r--  1 bin       186 May 13  1975 dup.s
> -rw-rw-r--  1 bin       772 May 13  1975 errlst.c
> -rw-rw-r--  1 bin       218 May 13  1975 execl.s
> -rw-rw-r--  1 bin       531 May 13  1975 execv.s
> -rw-rw-r--  1 bin       139 May 13  1975 exit.s
> -rw-rw-r--  1 bin       271 May 13  1975 fcrt0.s
> -rw-rw-r--  1 bin       116 May 13  1975 ffltpr.s
> -rw-rw-r--  1 bin       924 May 13  1975 fltpr.s
> -rw-rw-r--  1 bin       321 May 13  1975 fork.s
> -rw-rw-r--  1 bin       287 May 13  1975 fstat.s
> -rw-rw-r--  1 bin       957 May 13  1975 getc.s
> -rw-rw-r--  1 bin       395 May 13  1975 getchr.s
> -rw-rw-r--  1 bin       122 May 13  1975 getcsw.s
> -rw-rw-r--  1 bin       141 May 13  1975 getgid.s
> -rw-rw-r--  1 bin       127 May 13  1975 getpid.s
> -rw-rw-r--  1 bin       605 May 13  1975 getpw.c
> -rw-rw-r--  1 bin       128 May 13  1975 getuid.s
> -rw-rw-r--  1 bin       304 May 13  1975 gtty.s
> -rw-rw-r--  1 bin        57 May 13  1975 hmul.s
> -rw-rw-r--  1 bin       218 May 13  1975 kill.s
> -rw-rw-r--  1 bin       480 May 13  1975 ladd.s
> -rw-rw-r--  1 bin       121 May 13  1975 ldfps.s
> -rw-rw-r--  1 bin       237 May 13  1975 link.s
> -rw-rw-r--  1 bin       559 May 13  1975 locv.s
> -rw-rw-r--  1 bin       332 May 13  1975 ltod.s
> -rw-rw-r--  1 bin      1040 May 16  1975 run
>
> usr/source/s5/.
> total 59
> -rw-rw-r--  1 bin       213 May 13  1975 makdir.s
> -rw-rw-r--  1 bin       222 May 13  1975 mcount.s
> -rw-rw-r--  1 bin       770 May 13  1975 mcrt0.s
> -rw-rw-r--  1 bin       222 May 13  1975 mdate.s
> -rw-rw-r--  1 bin       279 May 13  1975 mknod.s
> -rw-rw-r--  1 bin       579 May 13  1975 mon.c
> -rw-rw-r--  1 bin       256 May 13  1975 mount.s
> -rw-rw-r--  1 bin       780 May 13  1975 nargs.s
> -rw-rw-r--  1 bin       176 May 13  1975 nice.s
> -rw-rw-r--  1 bin      1146 May 13  1975 nlist.s
> -rw-rw-r--  1 bin       246 May 13  1975 open.s
> -rw-rw-r--  1 bin       487 May 13  1975 perror.c
> -rw-rw-r--  1 bin       214 May 13  1975 pipe.s
> -rw-rw-r--  1 bin      2298 May 13  1975 printf.s
> -rw-rw-r--  1 bin       192 May 13  1975 prof.s
> -rw-rw-r--  1 bin       332 May 13  1975 ptrace.s
> -rw-rw-r--  1 bin      1037 May 13  1975 putc.s
> -rw-rw-r--  1 bin       585 May 13  1975 putchr.s
> -rw-rw-r--  1 bin      1324 May 13  1975 qsort.c
> -rw-rw-r--  1 bin       291 May 13  1975 read.s
> -rw-rw-r--  1 bin       423 May 13  1975 reset.s
> -rw-rw-r--  1 bin       335 May 13  1975 rin.c
> -rw-rw-r--  1 bin      1059 May 16  1975 run
> -rw-rw-r--  1 bin       531 May 13  1975 sbrk.s
> -rw-rw-r--  1 bin       248 May 13  1975 seek.s
> -rw-rw-r--  1 bin       197 May 13  1975 setgid.s
> -rw-rw-r--  1 bin       184 May 13  1975 setuid.s
> -rw-rw-r--  1 bin      1990 May 13  1975 signal.s
> -rw-rw-r--  1 bin       107 May 13  1975 sleep.s
> -rw-rw-r--  1 bin       290 May 13  1975 stat.s
> -rw-rw-r--  1 bin       161 May 13  1975 stime.s
> -rw-rw-r--  1 bin       304 May 13  1975 stty.s
> -rw-rw-r--  1 bin        89 May 13  1975 sync.s
> -rw-rw-r--  1 bin       229 May 13  1975 time.s
> -rw-rw-r--  1 bin       155 May 13  1975 times.s
> -rw-rw-r--  1 bin       223 May 13  1975 umount.s
> -rw-rw-r--  1 bin       215 May 13  1975 unlink.s
> -rw-rw-r--  1 bin       347 May 13  1975 wait.s
> -rw-rw-r--  1 bin       281 May 13  1975 write.s
>
> usr/source/s7/.
> total 275
> -rw-rw-r--  1 bin      3476 May 13  1975 ne.g
> -rw-rw-r--  1 bin       614 May 13  1975 ne.h
> -rw-rw-r--  1 bin      4856 May 13  1975 ne1.c
> -rw-rw-r--  1 bin      3125 May 13  1975 ne2.c
> -rw-rw-r--  1 bin      2312 May 13  1975 ne3.c
> -rw-rw-r--  1 bin      3539 May 13  1975 ne4.c
> -rw-rw-r--  1 bin       595 May 13  1975 ne5.c
> -rw-rw-r--  1 bin      1412 May 13  1975 ne6.c
> -rw-rw-r--  1 bin      5039 May 13  1975 nelex.c
> -rw-rw-r--  1 bin     14884 May 13  1975 nroff1.s
> -rw-rw-r--  1 bin     12516 May 13  1975 nroff2.s
> -rw-rw-r--  1 bin     12693 May 13  1975 nroff3.s
> -rw-rw-r--  1 bin      9504 May 13  1975 nroff4.s
> -rw-rw-r--  1 bin      4520 May 13  1975 nroff5.s
> -rw-rw-r--  1 bin      3071 May 13  1975 nroff8.s
> -rw-rw-r--  1 bin      6518 May 13  1975 roff1.s
> -rw-rw-r--  1 bin      3990 May 13  1975 roff2.s
> -rw-rw-r--  1 bin      4813 May 13  1975 roff3.s
> -rw-rw-r--  1 bin      5149 May 13  1975 roff4.s
> -rw-rw-r--  1 bin      3036 May 13  1975 roff5.s
> -rw-rw-r--  1 bin      6207 May 13  1975 roff7.s
> -rw-rw-r--  1 bin      1447 May 13  1975 roff8.s
> -rw-rw-r--  1 bin       254 May 13  1975 run
> -rw-rw-r--  1 bin     15373 May 13  1975 suftab.s
>
> usr/source/salloc/.
> total 36
> -rw-rw-r--  1 bin      2406 May 13  1975 alloc1.s
> -rw-rw-r--  1 bin      3289 May 13  1975 alloc2.s
> -rw-rw-r--  1 bin      6056 May 13  1975 alloc3.s
> -rw-rw-r--  1 bin       936 May 13  1975 altch.s
> -rw-rw-r--  1 bin       291 May 13  1975 bsp.s
> -rw-rw-r--  1 bin       370 May 13  1975 bword.s
> -rw-rw-r--  1 bin       300 May 13  1975 getch.s
> -rw-rw-r--  1 bin       747 May 13  1975 getwd.s
> -rw-rw-r--  1 bin       329 May 13  1975 length.s
> -rw-rw-r--  1 bin       468 May 13  1975 rewind.s
> -rw-rw-r--  1 bin       288 May 13  1975 run
> -rw-rw-r--  1 bin       245 May 13  1975 zero.s
>
> usr/source/sno/.
> total 51
> -rw-rw-r--  1 bin        52 May 13  1975 run
> -rw-rw-r--  1 bin       338 May 13  1975 sno.h
> -rw-rw-r--  1 bin      6305 May 13  1975 sno1.c
> -rw-rw-r--  1 bin      7723 May 13  1975 sno2.c
> -rw-rw-r--  1 bin      3644 May 13  1975 sno3.c
> -rw-rw-r--  1 bin      4176 May 13  1975 sno4.c
>
> usr/source/tmg/.
> total 72
> -rw-rw-r--  1 bin      1321 May 14  1975 run
> -rw-rw-r--  1 bin      7577 May 13  1975 tmga.s
> drwxrwxr-x  2 bin      1280 May 27  1975 tmgb
> -rw-rw-r--  1 bin      1989 May 13  1975 tmgc.s
> -rw-rw-r--  1 bin     14863 May 13  1975 tmgl.s
> -rw-rw-r--  1 bin      6751 May 13  1975 tmgl.t
>
> usr/source/tmg/tmgb/.
> total 47
> -rw-rw-r--  1 bin       178 May 13  1975 any.s
> -rw-rw-r--  1 bin       165 May 13  1975 append.s
> -rw-rw-r--  1 bin       787 May 13  1975 arith.s
> -rw-rw-r--  1 bin       246 May 13  1975 bundle.s
> -rw-rw-r--  1 bin       183 May 13  1975 char.s
> -rw-rw-r--  1 bin       446 May 13  1975 copy.s
> -rw-rw-r--  1 bin      1116 May 13  1975 cstr.s
> -rw-rw-r--  1 bin       237 May 13  1975 ctest.s
> -rw-rw-r--  1 bin       208 May 13  1975 decmal.s
> -rw-rw-r--  1 bin       109 May 13  1975 discd.s
> -rw-rw-r--  1 bin       592 May 13  1975 emit.s
> -rw-rw-r--  1 bin        60 May 13  1975 end.s
> -rw-rw-r--  1 bin       163 May 13  1975 f.s
> -rw-rw-r--  1 bin      1328 May 13  1975 find.s
> -rw-rw-r--  1 bin       612 May 13  1975 getnam.s
> -rw-rw-r--  1 bin        94 May 13  1975 ignore.s
> -rw-rw-r--  1 bin       238 May 13  1975 inc.s
> -rw-rw-r--  1 bin       300 May 13  1975 infix.s
> -rw-rw-r--  1 bin       470 May 13  1975 jget.s
> -rw-rw-r--  1 bin       124 May 13  1975 lvrv.s
> -rw-rw-r--  1 bin       249 May 13  1975 mult.s
> -rw-rw-r--  1 bin       204 May 13  1975 octal.s
> -rw-rw-r--  1 bin       142 May 13  1975 params.s
> -rw-rw-r--  1 bin       329 May 13  1975 push.s
> -rw-rw-r--  1 bin       260 May 13  1975 putcal.s
> -rw-rw-r--  1 bin       309 May 13  1975 putdec.s
> -rw-rw-r--  1 bin       184 May 13  1975 putoct.s
> -rw-rw-r--  1 bin       393 May 13  1975 px.s
> -rw-rw-r--  1 bin       431 May 13  1975 reln.s
> -rw-rw-r--  1 bin       120 May 13  1975 shift.s
> -rw-rw-r--  1 bin      1082 May 13  1975 stack.s
> -rw-rw-r--  1 bin       194 May 13  1975 string.s
> -rw-rw-r--  1 bin       231 May 13  1975 table.s
> -rw-rw-r--  1 bin       353 May 13  1975 tq.s
> -rw-rw-r--  1 bin       156 May 13  1975 trace.s
> -rw-rw-r--  1 bin        81 May 13  1975 trans.s
> -rw-rw-r--  1 bin       137 May 13  1975 tx.s
> -rw-rw-r--  1 bin       168 May 13  1975 unary.s
>
> usr/source/yacc/.
> total 3
> drwxrwxr-x  2 bin       208 May 27  1975 lib
> -rw-rw-r--  1 bin       118 May 13  1975 run
> drwxrwxr-x  2 bin       272 May 27  1975 source
>
> usr/source/yacc/lib/.
> total 11
> -rw-rw-r--  1 bin       112 May 13  1975 main.c
> -rw-rw-r--  1 bin      3284 May 13  1975 parser.c
> -rw-rw-r--  1 bin        12 May 13  1975 zacc.c
> -rw-rw-r--  1 bin       481 May 13  1975 zerr.c
> -rw-rw-r--  1 bin        11 May 13  1975 zinit.c
>
> usr/source/yacc/source/.
> total 100
> -rw-rw-r--  1 bin      4402 May 13  1975 dextern
> -rw-rw-r--  1 bin      3976 May 13  1975 y0.c
> -rw-rw-r--  1 bin      6597 May 13  1975 y1.c
> -rw-rw-r--  1 bin     12020 May 13  1975 y2.c
> -rw-rw-r--  1 bin      9654 May 13  1975 y3.c
> -rw-rw-r--  1 bin      9996 May 13  1975 y4.c
> -rw-rw-r--  1 bin       572 May 13  1975 y5.c
>
> -Henry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200406/21e37384/attachment.html>

From imp at bsdimp.com  Tue Apr  7 11:59:57 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Apr 2020 19:59:57 -0600
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <20200406225949.88C792BB520@yagi.h-net.msu.edu>
References: <20200406221138.GA10092@minnie.tuhs.org>
 <20200406225949.88C792BB520@yagi.h-net.msu.edu>
Message-ID: <CANCZdfpZ+CmrfZgdTVnfBJWSTiqGXh8WJgUCrF_Y3EAPqnC+AA@mail.gmail.com>

On Mon, Apr 6, 2020 at 5:00 PM Dennis Boone <drb at msu.edu> wrote:

> The tape was made by a PDP-11 system running RT-11.  This manual may
> help a little:
>
>
> http://bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PD6PA-TC_RT-11_Volume_and_File_Formats_Manual_Aug91.pdf
>
> TL;DR - This tape was written by just copying disk files to it, so the
> files which contain actual data are just images of the disk files.
>
> File 2 is a V6 image that's bootable like so

%pdp11
sim> set cpu 11/45
sim> att rk0 2.tape
sim> boot rk0
@rkunnix

login:

File 5 - this looks like a file system image.
>

It's the rest of the sources from the last disk. You can mount it like so
if you add a 'att rk1 5.tape' to the above

# mkdir /rk1
# /etc/mount /dev/rk1 /rk1


> File 8 - appears to be some sort of archiver output, but while the .ARC
> extension might lead you to suspect the old CP/M - MSDOS ARC program was
> responsible, that doesn't appear to be the case.
>

You'd think that from the name, but you can mount it also like the above.
With the 'att rk2 8.tape' and 'att rk3 11.tape'

# chdir /dev
# /etc/mknod rk2 b 0 2
# /etc/mknod rk3 b 0 3
# mkdir /rk2 /rk3
# /etc/mount /dev/rk2 /rk2
# /etc/mount /deev/rk3 /rk3


> File 11 - this is an older format tarball.
>

Nah, somebody else used the disk before for TAR, and then this was
overwritten with a unix filesystem.

What's weird is that this is a VENIX system, which should be V7 which
should have a different filesystem layout from V6. I'd think I wouldn't be
able to see some directories. I'll have to create a V7 system and mount it
there...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200406/91bd0341/attachment.html>

From dave at horsfall.org  Tue Apr  7 12:03:01 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 7 Apr 2020 12:03:01 +1000 (EST)
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <CAC20D2OVA3ODmHEPq4gOL8Q4MVwW9u_wAyrWKHVrAJyZZbweNg@mail.gmail.com>
References: <20200406221138.GA10092@minnie.tuhs.org>
 <20200406234758.GA27062@minnie.tuhs.org>
 <CAEdTPBcfS6wvw3rJ4w8H_1nC4+zou6TxqUB3qek9Sdsbc6RqQw@mail.gmail.com>
 <CAC20D2OVA3ODmHEPq4gOL8Q4MVwW9u_wAyrWKHVrAJyZZbweNg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2004071104580.36443@aneurin.horsfall.org>

On Mon, 6 Apr 2020, Clem Cole wrote:

> He used RT-11 to copy each disk pack sequentially.   That's an ANSI VOL1 
> record.   Sadly it's not a full ANSI tape (long story -- it needs HDR1 
> records  VMS would have been able to mount it as a foreign tape.   

[ Probably getting COFF-ish now ]

Blimey, but that takes me back to my OS/360 days...  I once wrote a little 
utility (in assembly, of course) that dumped all the HDR/VOL/etc records.

It was a swine to debug (overnight processing because I was a student); I 
had to leave instructions to the operator to "ABEND with core dump" if the 
tape merely oscillated back and forth (which it did early on).

The first time, I got a snotty note from the operator saying that after 
watching the tape for half an hour he had to kill it; ah, the joys of 
overnight remote debugging...  Later on I became a volunteer operator on 
the graveyard shift and was able to sneak in the occasional "foreign 
order".

-- Dave

From jsteve at superglobalmegacorp.com  Tue Apr  7 12:40:02 2020
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Tue, 7 Apr 2020 10:40:02 +0800
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <20200406221138.GA10092@minnie.tuhs.org>
References: <20200406221138.GA10092@minnie.tuhs.org>
Message-ID: <a53e1745-9f3f-42eb-8ffe-fe12ebec78f4@PU1APC01FT004.eop-APC01.prod.protection.outlook.com>

Strings tells me it’s from Venturcom

“VENTURCOM INC.  1981, 1982”

Maybe these guys?

https://www.businesswire.com/news/home/20041111005095/en/VenturCom-Launches-Enhanced-RTX-Version-6.0

“IntervalZero’s experience and expertise in embedded technology extends back to 1980 with the founding of its predecessor company, VenturCom, which developed the technology that led to Microsoft’s first embedded operating system.”



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200407/afa6d566/attachment.html>

From imp at bsdimp.com  Tue Apr  7 13:39:17 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Apr 2020 21:39:17 -0600
Subject: [TUHS] Software Archaeology Challenge?
In-Reply-To: <a53e1745-9f3f-42eb-8ffe-fe12ebec78f4@PU1APC01FT004.eop-APC01.prod.protection.outlook.com>
References: <20200406221138.GA10092@minnie.tuhs.org>
 <a53e1745-9f3f-42eb-8ffe-fe12ebec78f4@PU1APC01FT004.eop-APC01.prod.protection.outlook.com>
Message-ID: <CANCZdfpmQAp74ZWdJSqD1RMdF--gJmKTQrPPvnc-dOb9LgyhZg@mail.gmail.com>

On Mon, Apr 6, 2020 at 8:40 PM Jason Stevens <jsteve at superglobalmegacorp.com>
wrote:

> Strings tells me it’s from Venturcom
>
>
>
> “VENTURCOM INC.  1981, 1982”
>
>
>
> Maybe these guys?
>
>
>
>
> https://www.businesswire.com/news/home/20041111005095/en/VenturCom-Launches-Enhanced-RTX-Version-6.0
>
>
>
> “IntervalZero’s experience and expertise in embedded technology extends
> back to 1980 with the founding of its predecessor company, VenturCom, which
> developed the technology that led to Microsoft’s first embedded operating
> system.”
>

This is either Venix 1.0 or 2.0. I've not decided. I think 1.0, but maybe
2.0. I'll know more after I look at it some more.

Warner

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200406/3961e434/attachment.html>

From dfawcus+lists-tuhs at employees.org  Tue Apr  7 20:42:51 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 7 Apr 2020 11:42:51 +0100
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
Message-ID: <20200407104251.GA89097@clarinet.employees.org>

On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote:
> 
> The manuals aren’t really a book (and again, they weren’t really published as a book)

A bit later on but...

I'm prettry sure I managed to read the man pages published as a book while
at Uni, so between '86 and '90.  I found it in the University Library.

It was published by Western Electric, and had either a dark blue or black cover.

It also didn't appear to be a particularly recent book, but could just have
been well worn.  Possibly about System III, I don't think it was about System V.

However, there were books of System V man pages published, since I bought
some of them.

DF

From jpl.jpl at gmail.com  Wed Apr  8 04:10:08 2020
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Tue, 7 Apr 2020 14:10:08 -0400
Subject: [TUHS] Manuals
Message-ID: <CAC0cEp_Eg3EXch0NCkWCeNxa-dmAwn6m3gddd9O=f1UMrniadA@mail.gmail.com>

Andrew Hume (andrew at humeweb.com) has had trouble posting this, and asked me
to try. Reply directly to Andrew, not to me.

============================

I have the following manuals available:

3 Eight Edition Unix manuals (2 shrink-wrapped, one not (but still good
condition))
Unix programmers manual, Release 3.0 (Dolotta et al, 1980)
Sixth Edition programmers manual (Bell Labs cardboard cover)
Sixth Edition Documents manual (Bell Labs cardboard cover)
Seventh Edition programmers manual Volume 2a, Jan 1979. (actually documents
such as make, lint, troff etc)
Documents for UNIX, Volume 2 (Dolotta et al, 1981) sections E and F (make,
lex, security etc)

All the above are in pretty good condition, given they are bound in
cardboard covers and are 40ish years old.

I’d prefer to give them to someone archival, but otherwise, first come,
first served.

Andrew Hume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200407/fd38e8dc/attachment.html>

From dave at horsfall.org  Wed Apr  8 08:21:49 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 8 Apr 2020 08:21:49 +1000 (EST)
Subject: [TUHS] Manuals
In-Reply-To: <CAC0cEp_Eg3EXch0NCkWCeNxa-dmAwn6m3gddd9O=f1UMrniadA@mail.gmail.com>
References: <CAC0cEp_Eg3EXch0NCkWCeNxa-dmAwn6m3gddd9O=f1UMrniadA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2004080813420.36443@aneurin.horsfall.org>

On Tue, 7 Apr 2020, John P. Linderman wrote:

> Andrew Hume (andrew at humeweb.com) has had trouble posting this, and asked 
> me to try. Reply directly to Andrew, not to me.

Andrew Hume?  He first came to UNSW when in his final school year (I 
think) and quickly outstripped his mentors.  He damned near threw a 
keyboard into a screen because of Pascal's proclivity for reading ahead; 
doubleplus ungood on an interactive session...

(And yes, I've seen that photo of him wearing a tee-shirt and shorts in 
the snow; that's typical of him)

-- Dave

From pnr at planet.nl  Thu Apr  9 04:50:25 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 8 Apr 2020 20:50:25 +0200
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
Message-ID: <3FA2A5AF-F4E9-4AD8-9A06-6864DD855498@planet.nl>

As was suggested on the list, I’ve reached out to Peter Weinberger to better understand the time line of the File System Switch and the 8th edition network file system. He has been very helpful, but the one line summary is that it is unfortunately too long ago to remember specific details with any certainty. In general Peter remembers that he was concerned that the project was too big for one person to do, and hence always looked for design choices that would leave the work scope manageable.

Time line.

Since my last post on this subject I have found that the ACM conference talk of March 1985 was also held 9 months earlier at a Usenix conference - leaving a time slot between end of 1981 and summer 1984. Peter vaguely remembers that the essential ideas were done "before 1983”. It would stand to reason that 1983 was spent on getting corner cases of the network file system right, but all this is no more than plausible conjecture.

File system switch (FSS).

The guiding thought for the FSS was to extend the philosophy of ‘everything is a file’ to new areas, also other than network files. Early implementations already included a simple, read-only ‘/proc’ file system for example. I asked if any experiments had been done with virtualising ‘/dev', but Peter could not recall any such work.

I personally find that the FSS has an elegance that fits with other parts of Research Unix and asked Peter about its origins. He does not recall any special "a-ha” moments, but does recall that the way it was done just felt natural to him. Other options would have included to do the switch at the sys call level (which felt too complicated) or at the block device level (which felt too limited).

I also asked about how his reworking of ’namei’ and centralising all namespace operations in that function came about (in my view it is key to a concise switch). Here, too, it is too long ago to remember any specifics, but Peter comments that he never liked to write much code and that spending time on finding ways to make the amount of coding as small and straightforward as possible would have been in character.

Eighth edition network file system

Once the FSS exists, a simplistic network file system is not hard - just do RPC to a remote server. Peter chose to do a user level file server in order to keep the work scope and complexity down to manageable levels. As highlighted in the ACM paper, the devil is in the detail of replicating all the semantics of normal local disk files. Cases like a file being kept alive if a process still has it open, the complexities of cross-mounted network files (let alone recursively mounted), handling failed connections, etc. were hard to sort out and get right.


> On 29 Mar 2020, at 20:12, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> On 29 Mar 2020, at 16:04, arnold at skeeve.com wrote:
>> 
>> Paul Ruizendaal <pnr at planet.nl> wrote:
>> 
>>> Related is the question when the "file system switch" was added. It must
>>> have been later than 1981 and before 1985, but I have not been able to
>>> pinpoint it further.
>> 
>> IIRC there was a "paper" (only an abstract) on the file system
>> switch published in a USENIX conference proceedings. That woud help
>> trace it down.
> 
> I have that paper (“The Unix 8th Edition Network File System”), it was presented at a March 1985 ACM conference. However, there are indications that the roots of the file system switch existed earlier, possibly much earlier.
> 
> I think Doug McIlroy once described 1973 as a pivotal year for Unix, with many concepts devised that would blossom in the following 3-5 years. I’m increasingly tempted to think that Summer ’81 - Summer ’82 was a similarly pivotal year.
> 
>> Peter Weinberger, who did it, is at Google; you could ask him
>> directly, as well.
> 
> That is a good idea. If someone has the email address I’d appreciate an off list message.
> 
> Paul


From thomas.paulsen at firemail.de  Thu Apr  9 04:58:38 2020
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Wed, 08 Apr 2020 20:58:38 +0200
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <3FA2A5AF-F4E9-4AD8-9A06-6864DD855498@planet.nl>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
 <3FA2A5AF-F4E9-4AD8-9A06-6864DD855498@planet.nl>
Message-ID: <b86ac02f64adfbc237a01135f76a305d@firemail.de>


>As was suggested on the list, I’ve reached out to Peter Weinberger to better
>understand the time line of the File System Switch and the 8th edition network
f>ile system. 

'Introduced with System V Release 3.0, the File System Switch (FSS) architecture introduced a framework under which multiple different filesystem types could coexist in parallel.'
https://www.oreilly.com/library/view/unix-filesystems-evolution/9780471456759/chap07-sec003.html



From pnr at planet.nl  Thu Apr  9 06:13:29 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 8 Apr 2020 22:13:29 +0200
Subject: [TUHS] 8th Edition timeline
In-Reply-To: <b86ac02f64adfbc237a01135f76a305d@firemail.de>
References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl>
 <202003291404.02TE4dAI022916@freefriends.org>
 <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl>
 <3FA2A5AF-F4E9-4AD8-9A06-6864DD855498@planet.nl>
 <b86ac02f64adfbc237a01135f76a305d@firemail.de>
Message-ID: <0A39F8F1-C1C3-408F-9715-1D8B9C19A00C@planet.nl>

On Apr 8, 2020, at 8:58 PM, Thomas Paulsen <thomas.paulsen at firemail.de> wrote:
> 
>> As was suggested on the list, I’ve reached out to Peter Weinberger to better
>> understand the time line of the File System Switch and the 8th edition network
> f>ile system. 
> 
> 'Introduced with System V Release 3.0, the File System Switch (FSS) architecture introduced a framework under which multiple different filesystem types could coexist in parallel.'
> https://www.oreilly.com/library/view/unix-filesystems-evolution/9780471456759/chap07-sec003.html <https://www.oreilly.com/library/view/unix-filesystems-evolution/9780471456759/chap07-sec003.html>

Thanks for that link!

The SysV R3 source floats around on the web. Its FSS is very different from what is in 8th edition.

In 8th edition the switch has 11 entries (i.e. a file system is an object with 11 virtual methods).
https://github.com/Alhadis/Research-Unix-v8/blob/master/v8/usr/sys/h/conf.h
I have never really studied R3 but at quick inspection the FSS there has 27 (!) entries and seems to be more a sys call switch.

In 10th edition it is still 11 entries, although some refactoring has taken place. Also later work from Research keeps it concise: the 9P protocol from Plan 9 has 14 messages.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200408/6e7de829/attachment.html>

From woods at robohack.ca  Thu Apr  9 08:16:20 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Wed, 08 Apr 2020 15:16:20 -0700
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <20200407104251.GA89097@clarinet.employees.org>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <20200407104251.GA89097@clarinet.employees.org>
Message-ID: <m1jMIze-0036tRC@more.local>

At Tue, 7 Apr 2020 11:42:51 +0100, Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
Subject: Re: [TUHS] First book on Unix for general readership
> 
> On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote:
> > 
> > The manuals aren’t really a book (and again, they weren’t really published as a book)
> 
> A bit later on but...
> 
> I'm prettry sure I managed to read the man pages published as a book while
> at Uni, so between '86 and '90.  I found it in the University Library.
> 
> It was published by Western Electric, and had either a dark blue or black cover.

Indeed the Unix manuals were available as printed books.  Volume One was
the manual pages and Volume Two the articles from /usr/doc.  I remember
seeing soft-cover bound copies of the 7th Edition manuals, first in
someone's collection, then for sale, probably in the Computer Literacy
bookshop on Lawrence in Sunnyvale, I think with a dark red cover on the
ones I saw there.  For some reason I never acquired a copy (probably
because by then I already had several other sets of Unix manuals,
including a complete set of boxed AT&T manuals.

I think the next time this happened in the exact same way was with the
"Unix Research System Tenth Edition" books published by Saunders College
Publishing in 1990.  (Which I probably bought at Computer Literacy.)

There were also of course 4.4BSD manuals published and printed jointly
by The USENIX Association and O'Reilly & Associates in 1994.

> However, there were books of System V man pages published, since I bought
> some of them.

Yes, Prentice Hall's "UNIX System V/386" manuals from 1988 grace my
shelves, along with an incomplete set of the UNIX Press "SVR4" manuals
from 1992.

-- 
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200408/dafd448d/attachment.sig>

From woods at robohack.ca  Thu Apr  9 08:23:09 2020
From: woods at robohack.ca (Greg A. Woods)
Date: Wed, 08 Apr 2020 15:23:09 -0700
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <33f635bb3ea67f5cf14b46316ca3b6a6.squirrel@squirrelmail.tuffmail.net>
References: <1jKkMQ-2hN-00@marmaro.de>
 <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost>
 <1jKlvG-4JB-00@marmaro.de>
 <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com>
 <20200406000814.GH25105@mcvoy.com>
 <CAC20D2PSbFt47L0g3Jw_aVGra8nzwUW+hJGgitAZEhVk44=PPQ@mail.gmail.com>
 <CACg3+DHxyMP9fbycbvxQ37Ya+oTi40tsvJHAYb1XC1--OnH2QQ@mail.gmail.com>
 <33f635bb3ea67f5cf14b46316ca3b6a6.squirrel@squirrelmail.tuffmail.net>
Message-ID: <m1jMJ6D-0036tRC@more.local>

At Mon, 6 Apr 2020 10:51:05 -0400, ron at ronnatalie.com wrote:
Subject: Re: [TUHS] First book on Unix for general readership
>
> > I tried an ngram search on google, and came up with the following:
> >
> > Richard L. Gauthier. October 1981. Using the Unix System, Reston
> > Publishing
> > Co.  ISBN 978-0835981644.
> >
>
> Gosh, I'd forgotten about Gauthier, perhaps the worst UNIX book ever written.

I was going to mention this book as one I thought might be the first
book on Unix for a truly general readership.  I bought a copy in 1982.

Not a very good book indeed.  Horribly typeset.  Content reminds me of
many of the early poor-quality O'Reilly books.

But it was available in 1981, a few years before K&P's almost infinitely
greater "TUPE" (though TUPE is targeted far more to programmers than
general users).

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200408/74e70d93/attachment.sig>

From pnr at planet.nl  Thu Apr  9 20:22:49 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 9 Apr 2020 12:22:49 +0200
Subject: [TUHS] PK protocol
In-Reply-To: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl>
References: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl>
Message-ID: <585EA404-7C39-46A1-BD72-E5493D62103B@planet.nl>


> On 6 Apr 2020, at 20:12, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> Now I’m wondering. It looks like UUCP packet "protocol g” is maybe much the same as the original (“Chesson”) packet algorithm for Datakit, and if so it would be “dual use”. It would seem that in V7 line discipline ‘0’ was normal tty handling, discipline ‘1’ was PK protocol over serial and line discipline ‘2’ was PK protocol over something with CRC in the driver - whatever that was.
> 
> Am I on the right track?

It seems the story is more complicated. In a 1993 retrospective Fraser writes:

"The first Datakit protocols used a packet structure that was aligned with cell boundaries. Chesson designed a file transfer protocol that transported data in variable length packets, each ending with a trailer. There was no packet header. It was argued that it is easy to generate a trailer after the body of a packet has been transmitted, and that control information in a trailer arrives at the receiver just when the receiver is ready to process that information.”

Fraser uses the plural “the first protocols”: it would seem that there is not a single reference point. It also mentions that the protocols used a trailer, which does not match with the PK protocol. On the other hand this is a reference to a “file transfer protocol” which is not the same as a “link protocol”.

Also, Chesson wrote a note on the PK driver a few years after the V7 release (e.g. here: https://pd.spuddy.org/fs/simtel20/uucp/uucproto.des). In this note he writes:

"The resemblance between the flow control procedure in the packet driver and that defined for X.25 is no accident. The packet driver protocol began life as an attempt at cleaning up X.25.  That is why, for example, control information is uniform in length (one byte), there is no RNR message (not needed), and there is but one timeout defined in the sender.”

Earlier in the note Chesson also emphasised that the PK protocol was used for variation and experimentation. In the X.25 context, the reference to a CRC-based driver in the PK source may refer to a HDLC-like physical link.

All in all it would seem that the PK driver is *not* what was used as an early Datakit protocol. However, it is probably the best proxy for what such a driver looked like that we  have. It would seem likely to me that for instance the buffer strategy used in the PK driver would be about the same as that used for the Datakit driver(s) in V7.

It is possible that a variation of the PK protocol was used for Datakit around V7 time.


From wkt at tuhs.org  Fri Apr 10 18:53:29 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 10 Apr 2020 18:53:29 +1000
Subject: [TUHS] Discord chat in about 13 hours?
Message-ID: <DF2A44FA-F218-4541-8D49-DC38A5FE3EED@tuhs.org>

Anybody feel like a text/voice chat on the ClassicCmp Discord server in about 13 hours, say 2200 UTC?
#coff and the General voice channel.
I'll pop on for an hour but start whenever you feel like.
Cheers, Warren
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200410/29539ca2/attachment.html>

From sburjak at systech.com.au  Fri Apr 10 19:11:36 2020
From: sburjak at systech.com.au (Serge Burjak)
Date: Fri, 10 Apr 2020 19:11:36 +1000
Subject: [TUHS] Discord chat in about 13 hours?
In-Reply-To: <DF2A44FA-F218-4541-8D49-DC38A5FE3EED@tuhs.org>
References: <DF2A44FA-F218-4541-8D49-DC38A5FE3EED@tuhs.org>
Message-ID: <4F952DD2-4942-4438-B907-6260EEA09803@systech.com.au>

Hi,

How do I get access to Discord server?

Serge

> On 10 Apr 2020, at 18:55, Warren Toomey <wkt at tuhs.org> wrote:
> 
> ﻿Anybody feel like a text/voice chat on the ClassicCmp Discord server in about 13 hours, say 2200 UTC?
> #coff and the General voice channel.
> I'll pop on for an hour but start whenever you feel like.
> Cheers, Warren
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From pnr at planet.nl  Sat Apr 11 01:34:44 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 10 Apr 2020 17:34:44 +0200
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
Message-ID: <58126C92-CB5E-4647-ACA6-3E6B1665FF4C@planet.nl>

Warren has been nice enough to put 8th, 9th and 10th edition on the TUHS “Unix Tree” web page.

There is the following question on each entry web page: “Who wants to write something here?”

Below my suggested draft text for Eight Edition. All suggestions for improvement welcome.

===

Shortly after the release of 7th Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved: Eighth Edition of Unix was released by Bell Laboratories in February 1985, six years after Seventh Edition.

Key innovations in 8th Edition include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable applications built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system.

Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal.

Several of the new ideas from Eigth Edition found their way into the 3rd release of System V, although in a much modified way.

===


From robpike at gmail.com  Sat Apr 11 06:50:31 2020
From: robpike at gmail.com (Rob Pike)
Date: Sat, 11 Apr 2020 06:50:31 +1000
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
In-Reply-To: <58126C92-CB5E-4647-ACA6-3E6B1665FF4C@planet.nl>
References: <58126C92-CB5E-4647-ACA6-3E6B1665FF4C@planet.nl>
Message-ID: <CAKzdPgzc3Z816FLUPLd-RE2C41kPeTZXuR5wkDA=PgGsVg3V9Q@mail.gmail.com>

It wasn't that "shortly", it was several years. Maybe just drop the
adverb, or put in actual dates. Otherwise this seems OK (except for a
typo in "Eigth".)


-rob

On Sat, Apr 11, 2020 at 1:35 AM Paul Ruizendaal <pnr at planet.nl> wrote:
>
> Warren has been nice enough to put 8th, 9th and 10th edition on the TUHS “Unix Tree” web page.
>
> There is the following question on each entry web page: “Who wants to write something here?”
>
> Below my suggested draft text for Eight Edition. All suggestions for improvement welcome.
>
> ===
>
> Shortly after the release of 7th Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved: Eighth Edition of Unix was released by Bell Laboratories in February 1985, six years after Seventh Edition.
>
> Key innovations in 8th Edition include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable applications built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system.
>
> Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal.
>
> Several of the new ideas from Eigth Edition found their way into the 3rd release of System V, although in a much modified way.
>
> ===
>

From wkt at tuhs.org  Sat Apr 11 08:11:31 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 11 Apr 2020 08:11:31 +1000
Subject: [TUHS] [COFF] Discord chat in about 13 hours?
In-Reply-To: <DF2A44FA-F218-4541-8D49-DC38A5FE3EED@tuhs.org>
References: <DF2A44FA-F218-4541-8D49-DC38A5FE3EED@tuhs.org>
Message-ID: <20200410221131.GA31654@minnie.tuhs.org>

On Fri, Apr 10, 2020 at 06:53:29PM +1000, Warren Toomey wrote:
>    Anybody feel like a text/voice chat on the ClassicCmp Discord server in
>    about 13 hours, say 2200 UTC?
>    #coff and the General voice channel.

Looks like just Charles and I chatting right now.

	Warren

From imp at bsdimp.com  Sat Apr 11 13:48:44 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 10 Apr 2020 21:48:44 -0600
Subject: [TUHS] [COFF] Discord chat in about 13 hours?
In-Reply-To: <20200410221131.GA31654@minnie.tuhs.org>
References: <DF2A44FA-F218-4541-8D49-DC38A5FE3EED@tuhs.org>
 <20200410221131.GA31654@minnie.tuhs.org>
Message-ID: <CANCZdfpBDTT2y=HJUQK5W3hK4u_H4ZCkD+NMCvkXp=G6whmr3Q@mail.gmail.com>

On Fri, Apr 10, 2020, 4:12 PM Warren Toomey <wkt at tuhs.org> wrote:

> On Fri, Apr 10, 2020 at 06:53:29PM +1000, Warren Toomey wrote:
> >    Anybody feel like a text/voice chat on the ClassicCmp Discord server
> in
> >    about 13 hours, say 2200 UTC?
> >    #coff and the General voice channel.
>
> Looks like just Charles and I chatting right now.
>

Doh... missed this... was busy gardening today.

Warner

>         Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200410/1737158d/attachment.html>

From doug at cs.dartmouth.edu  Sun Apr 12 00:47:40 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 11 Apr 2020 10:47:40 -0400
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
Message-ID: <202004111447.03BElenq005540@tahoe.cs.Dartmouth.EDU>

The v8 manual was printed in 1985, but the system was
not "released" in the ordinary sense until a couple of
years ago. Some v8 features made it out into the world
via USG; some were described in open literature or
Usenix presentations, but I believe none were formally
shipped out of the company.

Doug

From norman at oclsc.org  Sun Apr 12 01:24:03 2020
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 11 Apr 2020 11:24:03 -0400 (EDT)
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
Message-ID: <20200411152403.5CB384422F@lignose.oclsc.org>

Doug McIlroy:

  The v8 manual was printed in 1985, but the system was
  not "released" in the ordinary sense until a couple of
  years ago. Some v8 features made it out into the world
  via USG; some were described in open literature or
  Usenix presentations, but I believe none were formally
  shipped out of the company.

I'm surprised; I thought copies of the V8 manual existed
when I arrived at the Labs in mid-1984, but the date on
the title page is indeed February 1985.

There was no general release of V8 like those for earlier
Research systems, but there was a quasi-official V8 tape
sent to a handful of universities under a special letter
agreement.  I remember working on that with Dennis,
checking that everything compiled and worked properly
in a chroot environment before the tape was written.
I think that happened in the summer of 1985.

I don't remember our doing that work, to make a single
coherent consistency-checked release tape, for any
subsequent system; just one-off caveat-emptor snapshots.

Norman Wilson
Toronto ON

From norman at oclsc.org  Sun Apr 12 01:38:44 2020
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 11 Apr 2020 11:38:44 -0400 (EDT)
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
Message-ID: <20200411153844.910A04422F@lignose.oclsc.org>

Minor corrections to the material in Paul's text.
This is meant to be a laundry-list of facts, not a
suggested set of words; I'm feeling too prolix this
morning to produce the latter, and figure those on the
list may be interested in the petty details anyway.

The initial user-mode environment was a mix of 32V,
subsequent work within 1127, and imports from 4.1BSD.
I don't know the exact heritage: whether it was 1127's
work with 4.1BSD stuff added or vice-versa.

The kernel was a clean break, however: 4.1xBSD for some
value of x (probably 4.1a but I don't remember which)
with Research changes.  By the time of V8, that means:
-- All trace of BSD's original network interfaces removed,
except that select(2) remained in a slightly-different
form.
-- Stream I/O system added; all communication-device
drivers (serial ports, Ethernet, Datakit) changed to
work with streams.  Pipes were streams.
-- File system switch added, supporting Killian's /proc
and Weinberger's first-generation (neta) network file
system.
-- Berkeley FFS replaced by Weinberger's bitmapped
file system: essentially the V7 file system except
the free list was a bitmap and the blocksize was 4KiB.
Hacky implementation, depending on a flag bit in the
minor device number; didn't use the file system switch.
Old 512-byte-block file systems had to be supported
partly to ease the changeover, partly because the first
version had a limited bitmap size so file systems larger
than about 120MiB wouldn't work.  This limit was removed
later.  (In retrospect I'm surprised I didn't then insist
on converting any remaining old-format file systems in
our domain and then removing the old-format code from
the kernel, since user-mode tools--including a user-mode
file server!--could be used to access any old disks
discovered later.)

For the purposes of Paul's note it probably suffices
just to say that there was a restart with a 4.1-series
kernel with changes as he describes, except also the
new file system format.

Norman Wilson
Toronto ON

From lm at mcvoy.com  Sun Apr 12 01:44:28 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 11 Apr 2020 08:44:28 -0700
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
In-Reply-To: <20200411153844.910A04422F@lignose.oclsc.org>
References: <20200411153844.910A04422F@lignose.oclsc.org>
Message-ID: <20200411154428.GF10016@mcvoy.com>

On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote:
> -- Stream I/O system added; all communication-device
> drivers (serial ports, Ethernet, Datakit) changed to
> work with streams.  Pipes were streams.

How was performance?  Was this Dennis' streams, not Sys V STREAMS?

I ported Lachmans/Convergents STREAMS based TCP/IP stack to the
ETA 10 Unix and SCO Unix and performance just sucked.  Ditto for
the Solaris port (which I did not do, I don't think it made any
difference who did the port though).

From arnold at skeeve.com  Sun Apr 12 04:49:00 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 11 Apr 2020 12:49:00 -0600
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
In-Reply-To: <20200411152403.5CB384422F@lignose.oclsc.org>
References: <20200411152403.5CB384422F@lignose.oclsc.org>
Message-ID: <202004111849.03BIn08J029073@freefriends.org>

norman at oclsc.org (Norman Wilson) wrote:

> There was no general release of V8 like those for earlier
> Research systems, but there was a quasi-official V8 tape
> sent to a handful of universities under a special letter
> agreement.  I remember working on that with Dennis,
> checking that everything compiled and worked properly
> in a chroot environment before the tape was written.
> I think that happened in the summer of 1985.

Sounds about right. Circa late '86 or early '87, IIRC correctly, DMR spoke
at Georgia Tech, and Gene Spafford, who was still there arranged to
get a copy of the V8 tape.

I got a friend who worked there to send me the man page sources
and printed a copy for myself. :-)  I later got an official (but used)
copy via BWK.

(I also arranged to buy a V9 manual in the early 90s.)

Arnold

From arnold at skeeve.com  Sun Apr 12 04:52:47 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 11 Apr 2020 12:52:47 -0600
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
In-Reply-To: <20200411153844.910A04422F@lignose.oclsc.org>
References: <20200411153844.910A04422F@lignose.oclsc.org>
Message-ID: <202004111852.03BIqlsD029181@freefriends.org>

norman at oclsc.org (Norman Wilson) wrote:

> The kernel was a clean break, however: 4.1xBSD for some
> value of x (probably 4.1a but I don't remember which)
> with Research changes.  By the time of V8, that means:
> ....
> -- Berkeley FFS replaced by Weinberger's bitmapped
> file system:

As far as I understand it, the Berkeley FFS didn't appear
until much closer to 4.2; it was definitely not in 4.1 and
was likely not in 4.1a.

Which would explain why V8 would have still had the 14 character
filename limit.

> essentially the V7 file system except
> the free list was a bitmap and the blocksize was 4KiB.

ISTR that System V picked this up at some point also, although I don't
recall if the bigger block size was 1K or 4K.  I may be misremembering
though.

Thanks,

Arnold

From angus at fairhaven.za.net  Sun Apr 12 17:33:16 2020
From: angus at fairhaven.za.net (Angus Robinson)
Date: Sun, 12 Apr 2020 09:33:16 +0200
Subject: [TUHS] Discord chat in about 13 hours?
In-Reply-To: <DF2A44FA-F218-4541-8D49-DC38A5FE3EED@tuhs.org>
References: <DF2A44FA-F218-4541-8D49-DC38A5FE3EED@tuhs.org>
Message-ID: <CAE49LGkY_oFnQb47xZE8oiARcs1BcPUCDamOuOtD6KBTLbtG3A@mail.gmail.com>

could you send an invite ? Would love to be on the next one or just browse
the channels.

On Fri, Apr 10, 2020 at 10:54 AM Warren Toomey <wkt at tuhs.org> wrote:

> Anybody feel like a text/voice chat on the ClassicCmp Discord server in
> about 13 hours, say 2200 UTC?
> #coff and the General voice channel.
> I'll pop on for an hour but start whenever you feel like.
> Cheers, Warren
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200412/33a10904/attachment.html>

From pnr at planet.nl  Sun Apr 12 18:51:58 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 12 Apr 2020 10:51:58 +0200
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
In-Reply-To: <CAKzdPgzc3Z816FLUPLd-RE2C41kPeTZXuR5wkDA=PgGsVg3V9Q@mail.gmail.com>
References: <58126C92-CB5E-4647-ACA6-3E6B1665FF4C@planet.nl>
 <CAKzdPgzc3Z816FLUPLd-RE2C41kPeTZXuR5wkDA=PgGsVg3V9Q@mail.gmail.com>
Message-ID: <E0E588AB-C9E6-4ECC-AC9E-BF7F3DC9F562@planet.nl>

Below an update with comments reflected.

===

After the Seventh Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved and an Eighth Edition manual was completed by Bell Laboratories in February 1985, six years after 7th Edition. The 8th Edition source code was not as widely distributed as the 6th and 7th Edition sources had been.

The file system in 8th Edition was rewritten to work with a bitmapped free list and allocation clusters of 4KB (8 blocks); it also supported the V7 filesystem for backwards compatibility with disk clusters of 1, 2 or 4 blocks.

Key innovations in the 8th Edition kernel include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable developments built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system.

Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal.

Several of the new ideas from Eighth Edition found their way into the 3rd release of System V, although in a much modified form.

===

> On Sat, Apr 11, 2020 at 1:35 AM Paul Ruizendaal <pnr at planet.nl> wrote:
>> 
>> Warren has been nice enough to put 8th, 9th and 10th edition on the TUHS “Unix Tree” web page.
>> 
>> There is the following question on each entry web page: “Who wants to write something here?”
>> 
>> Below my suggested draft text for Eight Edition. All suggestions for improvement welcome.
>> 
>> ===
>> 
>> Shortly after the release of 7th Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved: Eighth Edition of Unix was released by Bell Laboratories in February 1985, six years after Seventh Edition.
>> 
>> Key innovations in 8th Edition include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable applications built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system.
>> 
>> Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal.
>> 
>> Several of the new ideas from Eigth Edition found their way into the 3rd release of System V, although in a much modified way.
>> 
>> ===
>> 


From pnr at planet.nl  Sun Apr 12 19:26:44 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 12 Apr 2020 11:26:44 +0200
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
Message-ID: <60425F60-2759-423B-8C8F-916BF14CC221@planet.nl>

Many thanks for the below notes!

Some comments in line below:

> The initial user-mode environment was a mix of 32V,
> subsequent work within 1127, and imports from 4.1BSD.
> I don't know the exact heritage: whether it was 1127's
> work with 4.1BSD stuff added or vice-versa.

Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later.

> The kernel was a clean break, however: 4.1xBSD for some
> value of x (probably 4.1a but I don't remember which)
> with Research changes.

I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort.

As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/*	vmmem.c	4.7	81/07/09	*/“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?)

For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition.

As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet).

> -- Berkeley FFS replaced by Weinberger's bitmapped
> file system: essentially the V7 file system except
> the free list was a bitmap and the blocksize was 4KiB.

Thank you for pointing this out. With my focus on networking I had completely missed that.

> Hacky implementation, depending on a flag bit in the
> minor device number; didn't use the file system switch.
> Old 512-byte-block file systems had to be supported
> partly to ease the changeover, partly because the first
> version had a limited bitmap size so file systems larger
> than about 120MiB wouldn't work.

For those interested, some of the relevant files are:
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit)
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union)
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’)

And indeed the bitmap was fitted inside the 4KB superblock, 
> This limit was removed
> later.  (In retrospect I'm surprised I didn't then insist
> on converting any remaining old-format file systems in
> our domain and then removing the old-format code from
> the kernel, since user-mode tools--including a user-mode
> file server!--could be used to access any old disks
> discovered later.)
> 
> For the purposes of Paul's note it probably suffices
> just to say that there was a restart with a 4.1-series
> kernel with changes as he describes, except also the
> new file system format.

From pnr at planet.nl  Sun Apr 12 19:30:39 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 12 Apr 2020 11:30:39 +0200
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
Message-ID: <D1DFB9DE-BAE7-410F-9332-4C7FCAA285D9@planet.nl>

Oops - pressed send too soon - apologies

—

Many thanks for the below notes!

Some comments in line below:

> The initial user-mode environment was a mix of 32V,
> subsequent work within 1127, and imports from 4.1BSD.
> I don't know the exact heritage: whether it was 1127's
> work with 4.1BSD stuff added or vice-versa.

Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later.

> The kernel was a clean break, however: 4.1xBSD for some
> value of x (probably 4.1a but I don't remember which)
> with Research changes.

I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort.

As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/*	vmmem.c	4.7	81/07/09	*/“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?)

For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition.

As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet).

> -- Berkeley FFS replaced by Weinberger's bitmapped
> file system: essentially the V7 file system except
> the free list was a bitmap and the blocksize was 4KiB.

Thank you for pointing this out. With my focus on networking I had completely missed that.

> Hacky implementation, depending on a flag bit in the
> minor device number; didn't use the file system switch.
> Old 512-byte-block file systems had to be supported
> partly to ease the changeover, partly because the first
> version had a limited bitmap size so file systems larger
> than about 120MiB wouldn't work.

For those interested, some of the relevant files are:
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit)
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union)
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’)

And indeed the bitmap was fitted inside the 4KB superblock, 961 longs.
961 x 32 bits x 4KB = 120MB

I’m not sure I understand the link between cluster and page size that is mentioned in param.h

> This limit was removed
> later.  (In retrospect I'm surprised I didn't then insist
> on converting any remaining old-format file systems in
> our domain and then removing the old-format code from
> the kernel, since user-mode tools--including a user-mode
> file server!--could be used to access any old disks
> discovered later.)


From robpike at gmail.com  Sun Apr 12 20:00:56 2020
From: robpike at gmail.com (Rob Pike)
Date: Sun, 12 Apr 2020 20:00:56 +1000
Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree"
In-Reply-To: <D1DFB9DE-BAE7-410F-9332-4C7FCAA285D9@planet.nl>
References: <D1DFB9DE-BAE7-410F-9332-4C7FCAA285D9@planet.nl>
Message-ID: <CAKzdPgy0Hj6SaJ-8qJoPUuYuHD0xnOGRL=o4f1+G6ousi_TvSQ@mail.gmail.com>

My favorite use of the file system switch was the "face server"
(analogous to name server), documented in a paper by myself and Dave
Presotto at the Portland USENIX in 1985.
http://doc.cat-v.org/bell_labs/face_the_nation/

We believe this was the first networked delivery of facial images to
indicate the sender of an arriving mail message. The associated vismon
program was also of interest in what it showed, and how small the code
was given the uniform system interface to resources.

-rob

On Sun, Apr 12, 2020 at 7:31 PM Paul Ruizendaal <pnr at planet.nl> wrote:
>
> Oops - pressed send too soon - apologies
>
> —
>
> Many thanks for the below notes!
>
> Some comments in line below:
>
> > The initial user-mode environment was a mix of 32V,
> > subsequent work within 1127, and imports from 4.1BSD.
> > I don't know the exact heritage: whether it was 1127's
> > work with 4.1BSD stuff added or vice-versa.
>
> Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later.
>
> > The kernel was a clean break, however: 4.1xBSD for some
> > value of x (probably 4.1a but I don't remember which)
> > with Research changes.
>
> I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort.
>
> As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/*     vmmem.c 4.7     81/07/09        */“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?)
>
> For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition.
>
> As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet).
>
> > -- Berkeley FFS replaced by Weinberger's bitmapped
> > file system: essentially the V7 file system except
> > the free list was a bitmap and the blocksize was 4KiB.
>
> Thank you for pointing this out. With my focus on networking I had completely missed that.
>
> > Hacky implementation, depending on a flag bit in the
> > minor device number; didn't use the file system switch.
> > Old 512-byte-block file systems had to be supported
> > partly to ease the changeover, partly because the first
> > version had a limited bitmap size so file systems larger
> > than about 120MiB wouldn't work.
>
> For those interested, some of the relevant files are:
> https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit)
> https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union)
> https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’)
>
> And indeed the bitmap was fitted inside the 4KB superblock, 961 longs.
> 961 x 32 bits x 4KB = 120MB
>
> I’m not sure I understand the link between cluster and page size that is mentioned in param.h
>
> > This limit was removed
> > later.  (In retrospect I'm surprised I didn't then insist
> > on converting any remaining old-format file systems in
> > our domain and then removing the old-format code from
> > the kernel, since user-mode tools--including a user-mode
> > file server!--could be used to access any old disks
> > discovered later.)
>

From pnr at planet.nl  Sun Apr 12 20:03:23 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 12 Apr 2020 12:03:23 +0200
Subject: [TUHS] STREAMS performance
Message-ID: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>


> Date: Sat, 11 Apr 2020 08:44:28 -0700
> From: Larry McVoy
> 
> On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote:
>> -- Stream I/O system added; all communication-device
>> drivers (serial ports, Ethernet, Datakit) changed to
>> work with streams.  Pipes were streams.
> 
> How was performance?  Was this Dennis' streams, not Sys V STREAMS?

It was streams, not STREAMS.

> I ported Lachmans/Convergents STREAMS based TCP/IP stack to the
> ETA 10 Unix and SCO Unix and performance just sucked.  Ditto for
> the Solaris port (which I did not do, I don't think it made any
> difference who did the port though).

STREAMS are outside the limited scope I try to restrain myself to, but I’m intrigued.

What in the above case drove/caused the poor performance?

There was a debate on the LKML in the late 1990’s where Caldera wanted STREAMS support in Linux and to the extent the arguments were technical *), my understanding of them is that the main show stopper was that STREAMS would make ‘zero copy’ networking impossible. If so, then it is a comment more about the underlying buffer strategy than STREAMS itself.

Did STREAMS also perform poorly in the 1986 context they were developed in?

Paul

*) Other arguments pro- and con included forward maintenance and market need, but I’m not so interested in those aspects of the debate.


From ality at pbrane.org  Mon Apr 13 09:15:03 2020
From: ality at pbrane.org (Anthony Martin)
Date: Sun, 12 Apr 2020 16:15:03 -0700
Subject: [TUHS] STREAMS performance
In-Reply-To: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>
References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>
Message-ID: <20200412231503.GA48389@alice>

As an aside, Plan 9 began with a descendant of dmr's streams
but replaced it in mid-1993 with a simple queued i/o scheme.
This was done for performance and to simplify the code since
they didn't end up using much of the streams functionality.

  Anthony

From joe at via.net  Mon Apr 13 08:55:48 2020
From: joe at via.net (joe mcguckin)
Date: Sun, 12 Apr 2020 15:55:48 -0700
Subject: [TUHS] STREAMS performance
In-Reply-To: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>
References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>
Message-ID: <37F9655C-D42C-4504-9926-129F6DF5C158@via.net>


I seem to remember that Sun was trying to sell boxes to the airline / reservation industry, and one of the ways they came up with
to make Solaris handle thousands of ascii terminals was to push the character discipline code into streams in order to eliminate the multiple user/kernel
crossings per character being handled…

Joe


Joe McGuckin
ViaNet Communications

joe at via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Apr 12, 2020, at 3:03 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> 
>> Date: Sat, 11 Apr 2020 08:44:28 -0700
>> From: Larry McVoy
>> 
>> On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote:
>>> -- Stream I/O system added; all communication-device
>>> drivers (serial ports, Ethernet, Datakit) changed to
>>> work with streams.  Pipes were streams.
>> 
>> How was performance?  Was this Dennis' streams, not Sys V STREAMS?
> 
> It was streams, not STREAMS.
> 
>> I ported Lachmans/Convergents STREAMS based TCP/IP stack to the
>> ETA 10 Unix and SCO Unix and performance just sucked.  Ditto for
>> the Solaris port (which I did not do, I don't think it made any
>> difference who did the port though).
> 
> STREAMS are outside the limited scope I try to restrain myself to, but I’m intrigued.
> 
> What in the above case drove/caused the poor performance?
> 
> There was a debate on the LKML in the late 1990’s where Caldera wanted STREAMS support in Linux and to the extent the arguments were technical *), my understanding of them is that the main show stopper was that STREAMS would make ‘zero copy’ networking impossible. If so, then it is a comment more about the underlying buffer strategy than STREAMS itself.
> 
> Did STREAMS also perform poorly in the 1986 context they were developed in?
> 
> Paul
> 
> *) Other arguments pro- and con included forward maintenance and market need, but I’m not so interested in those aspects of the debate.
> 


From robpike at gmail.com  Mon Apr 13 11:43:03 2020
From: robpike at gmail.com (Rob Pike)
Date: Mon, 13 Apr 2020 11:43:03 +1000
Subject: [TUHS] STREAMS performance
In-Reply-To: <20200412231503.GA48389@alice>
References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>
 <20200412231503.GA48389@alice>
Message-ID: <CAKzdPgyGk3jYyVjs3hkdqQWhKyPyhGGCCGG8kq2G9BAJYtUH+g@mail.gmail.com>

It did? I think a version of streams showed up at some point, and were
replaced; of that you are correct. But it certainly didn't begin with
anything like streams. It began with a file system mux.

-rob

On Mon, Apr 13, 2020 at 9:16 AM Anthony Martin <ality at pbrane.org> wrote:
>
> As an aside, Plan 9 began with a descendant of dmr's streams
> but replaced it in mid-1993 with a simple queued i/o scheme.
> This was done for performance and to simplify the code since
> they didn't end up using much of the streams functionality.
>
>   Anthony

From ality at pbrane.org  Mon Apr 13 13:00:20 2020
From: ality at pbrane.org (Anthony Martin)
Date: Sun, 12 Apr 2020 20:00:20 -0700
Subject: [TUHS] STREAMS performance
In-Reply-To: <CAKzdPgyGk3jYyVjs3hkdqQWhKyPyhGGCCGG8kq2G9BAJYtUH+g@mail.gmail.com>
References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>
 <20200412231503.GA48389@alice>
 <CAKzdPgyGk3jYyVjs3hkdqQWhKyPyhGGCCGG8kq2G9BAJYtUH+g@mail.gmail.com>
Message-ID: <20200413030020.GA67784@alice>

Rob Pike <robpike at gmail.com> once said:
> It did? I think a version of streams showed up at some point, and were
> replaced; of that you are correct. But it certainly didn't begin with
> anything like streams. It began with a file system mux.

I realize you would probably know better, but ...

I didn't mean that streams was the first thing in Plan 9, just that the
I/O system for pipes, network devices, etc. was descended from streams.
That was the case at least as far back as 1990.

Look at the early Plan 9 code for the pipe¹ and ethernet² devices, the
code for Streams, Queues, and Blocks in port/stream.c³ and power/dat.h⁴,
and tell me that doesn't descend from v8 streams. :)

Also, thanks for Plan 9. It's lovely.

  Anthony

1. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devpipe.c
2. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devlance.c#L256
3. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/stream.c
4. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/power/dat.h#L338

From robpike at gmail.com  Mon Apr 13 13:14:55 2020
From: robpike at gmail.com (Rob Pike)
Date: Mon, 13 Apr 2020 13:14:55 +1000
Subject: [TUHS] STREAMS performance
In-Reply-To: <20200413030020.GA67784@alice>
References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>
 <20200412231503.GA48389@alice>
 <CAKzdPgyGk3jYyVjs3hkdqQWhKyPyhGGCCGG8kq2G9BAJYtUH+g@mail.gmail.com>
 <20200413030020.GA67784@alice>
Message-ID: <CAKzdPgzXtrbLD_te9GNRxOs82rZNh68dG0d_u=w=X9rmWgKmXw@mail.gmail.com>

Nice to see Egreg again.

-rob

On Mon, Apr 13, 2020 at 1:00 PM Anthony Martin <ality at pbrane.org> wrote:
>
> Rob Pike <robpike at gmail.com> once said:
> > It did? I think a version of streams showed up at some point, and were
> > replaced; of that you are correct. But it certainly didn't begin with
> > anything like streams. It began with a file system mux.
>
> I realize you would probably know better, but ...
>
> I didn't mean that streams was the first thing in Plan 9, just that the
> I/O system for pipes, network devices, etc. was descended from streams.
> That was the case at least as far back as 1990.
>
> Look at the early Plan 9 code for the pipe¹ and ethernet² devices, the
> code for Streams, Queues, and Blocks in port/stream.c³ and power/dat.h⁴,
> and tell me that doesn't descend from v8 streams. :)
>
> Also, thanks for Plan 9. It's lovely.
>
>   Anthony
>
> 1. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devpipe.c
> 2. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devlance.c#L256
> 3. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/stream.c
> 4. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/power/dat.h#L338

From doug at cs.dartmouth.edu  Tue Apr 14 12:13:17 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 13 Apr 2020 22:13:17 -0400
Subject: [TUHS] First book on Unix for general readership
Message-ID: <202004140213.03E2DHF1002571@tahoe.cs.Dartmouth.EDU>

> Indeed the Unix manuals were available as printed books.  Volume One was
the manual pages and Volume Two the articles from /usr/doc.  I remember
seeing soft-cover bound copies of the 7th Edition manuals, ...
> I think the next time this happened in the exact same way was with the
"Unix Research System Tenth Edition" books published by Saunders College
Publishing in 1990.

Those were the only two that were published as trade books. I still use
the 10th Ed regularly. The 7th Ed was a debacle. The publisher didn't
bother to send us galleys because they had printed straight from troff.
It turned out they did not have the full troff character set, and put
an @ sign in place of each missing character. The whole print run was
done before we saw a copy. Not knowing whether they ever fixed it, I'd
be interested to hear whether or not the botch made it to bookstores.

Doug

From grog at lemis.com  Tue Apr 14 15:30:24 2020
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 14 Apr 2020 15:30:24 +1000
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <202004140213.03E2DHF1002571@tahoe.cs.Dartmouth.EDU>
References: <202004140213.03E2DHF1002571@tahoe.cs.Dartmouth.EDU>
Message-ID: <20200414053024.GA67339@eureka.lemis.com>

On Monday, 13 April 2020 at 22:13:17 -0400, Doug McIlroy wrote:
>
> Those were the only two that were published as trade books. I still use
> the 10th Ed regularly. The 7th Ed was a debacle. The publisher didn't
> bother to send us galleys because they had printed straight from troff.
> It turned out they did not have the full troff character set, and put
> an @ sign in place of each missing character. The whole print run was
> done before we saw a copy. Not knowing whether they ever fixed it, I'd
> be interested to hear whether or not the botch made it to bookstores.

OK, I've dug out my copies.  Two volumes, published by CBS College
publishing, aka Holt, Rinehart and Winston in 1982, both titled "UNIX
Programmer's Manual".  Volume 1 (ISBN 0-03-061742-1) was the man
pages, and volume 2 (ISBN 0-03-061743-X) was the supplementary docs,
starting with â7th Edition UNIX â Summaryâ, dated September 6, 1978.
They have perforated, 3-hole punched pages, clearly intended to be
torn out and put into a three-ring binder.

I've skimmed through both of them, and I can't find any obvious
typesetting errors.  "Typesetting Mathematics" shows some quite
complicated equations.  And in the quick reference in volume 1, all
the troff special characters seem right, even up to less common
characters such as \(bs.  Is there anything specific that I should
look for?  Scans available if they would help.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200414/3d8fc5e3/attachment.sig>

From imp at bsdimp.com  Tue Apr 14 15:38:00 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 13 Apr 2020 23:38:00 -0600
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <20200414053024.GA67339@eureka.lemis.com>
References: <202004140213.03E2DHF1002571@tahoe.cs.Dartmouth.EDU>
 <20200414053024.GA67339@eureka.lemis.com>
Message-ID: <CANCZdfqZMDyxSf+VJ+ZqtA=t27PqYzF6KkXWXrEU0cmQX0zE4A@mail.gmail.com>

On Mon, Apr 13, 2020, 11:31 PM Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Monday, 13 April 2020 at 22:13:17 -0400, Doug McIlroy wrote:
> >
> > Those were the only two that were published as trade books. I still use
> > the 10th Ed regularly. The 7th Ed was a debacle. The publisher didn't
> > bother to send us galleys because they had printed straight from troff.
> > It turned out they did not have the full troff character set, and put
> > an @ sign in place of each missing character. The whole print run was
> > done before we saw a copy. Not knowing whether they ever fixed it, I'd
> > be interested to hear whether or not the botch made it to bookstores.
>
> OK, I've dug out my copies.  Two volumes, published by CBS College
> publishing, aka Holt, Rinehart and Winston in 1982, both titled "UNIX
> Programmer's Manual".  Volume 1 (ISBN 0-03-061742-1) was the man
> pages, and volume 2 (ISBN 0-03-061743-X) was the supplementary docs,
> starting with â€œ7th Edition UNIX â€” Summaryâ€ , dated September 6, 1978.
> They have perforated, 3-hole punched pages, clearly intended to be
> torn out and put into a three-ring binder.
>
> I've skimmed through both of them, and I can't find any obvious
> typesetting errors.  "Typesetting Mathematics" shows some quite
> complicated equations.  And in the quick reference in volume 1, all
> the troff special characters seem right, even up to less common
> characters such as \(bs.  Is there anything specific that I should
> look for?  Scans available if they would help.
>

Mine are like that too. Maybe it was just wrong for the first printing?

Warner

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200413/4ef20be3/attachment.html>

From dot at dotat.at  Wed Apr 15 00:54:23 2020
From: dot at dotat.at (Tony Finch)
Date: Tue, 14 Apr 2020 15:54:23 +0100
Subject: [TUHS] STREAMS performance
In-Reply-To: <37F9655C-D42C-4504-9926-129F6DF5C158@via.net>
References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl>
 <37F9655C-D42C-4504-9926-129F6DF5C158@via.net>
Message-ID: <alpine.DEB.2.20.2004141543200.26709@grey.csi.cam.ac.uk>

joe mcguckin <joe at via.net> wrote:
>
> I seem to remember that Sun was trying to sell boxes to the airline /
> reservation industry, and one of the ways they came up with to make
> Solaris handle thousands of ascii terminals was to push the character
> discipline code into streams in order to eliminate the multiple
> user/kernel crossings per character being handled…

I encountered this feature when deploying some new Solaris 2.5.1 / 2.6 web
servers in about 1997/8. We were chroot()ing the user login daemons
(telnet and ftp) to improve security, and they wouldn't work on a freshly
rebooted server. Eventually I worked out that telnetd loaded a kernel
module on demand, and this didn't work when it was chroot()ed, but telnetd
could skip it if the module had previously been loaded. (I could see from
truss and/or strings that telnetd was specifying an absolute path to the
module rather than expecting the kernel to know where to find it.) I was
kind of impressed by the performance engineering, and it stuck in my
memory because it took me so long to understand why it sometimes didn't
work...

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Variable 3 or 4 at first in southeast, otherwise cyclonic 5 to 7.
Moderate or rough, occasionally very rough at first in northwest. Rain or
thundery showers. Good, occasionally poor.

From doug at cs.dartmouth.edu  Wed Apr 15 01:10:50 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 14 Apr 2020 11:10:50 -0400
Subject: [TUHS] First book on Unix for general readership
Message-ID: <202004141510.03EFAo1R018763@tahoe.cs.Dartmouth.EDU>

> OK, I've dug out my copies. They have perforated, 3-hole punched pages
...
>  I can't find any obvious typesetting errors.

That sets my mind at rest after three decades. What I saw
back in the day was littered with @ signs, and was not punched
for a ring binder. Thanks for checking.

Doug

From steve.mynott at gmail.com  Wed Apr 15 01:27:37 2020
From: steve.mynott at gmail.com (Steve Mynott)
Date: Tue, 14 Apr 2020 16:27:37 +0100
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com>
Message-ID: <CANuZA8Rag1Q93uMnB9RMobxzsC=EHRqtY+7wKcNbOhOJYxQc+A@mail.gmail.com>

On Sat, 4 Apr 2020 at 16:58, Nemo Nusquam <cym224 at gmail.com> wrote:
>
> On 04/04/20 11:05, markus schnalke wrote (in part):
> > Thus I now wonder what the first book on Unix, intended for a general
> > readership was.
> Not to be overly pedantic but what would be a "general readership"?

I think the wikipedia article meant Bourne's "The Unix System"  was
the first general introduction to UNIX.

In the autumn of 1984 it was a recommended text book for an
introduction to computing course aimed at first year science
undergraduates at an English university.

They taught us awk programming and basic shell commands on a VAX
running BSD 4.1 using it. I still have a copy.

So by general readership they probably meant primer.

--
Steve Mynott <steve.mynott at gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

From imp at bsdimp.com  Wed Apr 15 06:32:05 2020
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 14 Apr 2020 14:32:05 -0600
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <CANuZA8Rag1Q93uMnB9RMobxzsC=EHRqtY+7wKcNbOhOJYxQc+A@mail.gmail.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com>
 <CANuZA8Rag1Q93uMnB9RMobxzsC=EHRqtY+7wKcNbOhOJYxQc+A@mail.gmail.com>
Message-ID: <CANCZdfo070YVQJjDvB7ghQYQAByFyGSioviCZoMrzOoXoup6=Q@mail.gmail.com>

On Tue, Apr 14, 2020 at 9:27 AM Steve Mynott <steve.mynott at gmail.com> wrote:

> On Sat, 4 Apr 2020 at 16:58, Nemo Nusquam <cym224 at gmail.com> wrote:
> >
> > On 04/04/20 11:05, markus schnalke wrote (in part):
> > > Thus I now wonder what the first book on Unix, intended for a general
> > > readership was.
> > Not to be overly pedantic but what would be a "general readership"?
>
> I think the wikipedia article meant Bourne's "The Unix System"  was
> the first general introduction to UNIX.
>
> In the autumn of 1984 it was a recommended text book for an
> introduction to computing course aimed at first year science
> undergraduates at an English university.
>
> They taught us awk programming and basic shell commands on a VAX
> running BSD 4.1 using it. I still have a copy.
>
> So by general readership they probably meant primer.
>

I think it's not the first primer, but it's one of the first. But I'll know
more once I process through the half dozen books from the early 80s on Unix
that just arrived from ebay... I'll post a brief review and a bibliography


Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200414/f070beb6/attachment.html>

From imp at bsdimp.com  Wed Apr 15 08:03:40 2020
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 14 Apr 2020 16:03:40 -0600
Subject: [TUHS] First book on Unix for general readership
In-Reply-To: <CANCZdfo070YVQJjDvB7ghQYQAByFyGSioviCZoMrzOoXoup6=Q@mail.gmail.com>
References: <1jKkMQ-2hN-00@marmaro.de>
 <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com>
 <CANuZA8Rag1Q93uMnB9RMobxzsC=EHRqtY+7wKcNbOhOJYxQc+A@mail.gmail.com>
 <CANCZdfo070YVQJjDvB7ghQYQAByFyGSioviCZoMrzOoXoup6=Q@mail.gmail.com>
Message-ID: <CANCZdfr33kiOgCRU_sKrmaGFpEv3ikFTycS9jND+TAO6zBEjow@mail.gmail.com>

I have the following 5 books:

The Unix Operating System Book by Mike Banahan and Andy Rutter (Copyright
1983)
A Unix Primer by Ann Nicols Lomuto & Nico Lomuto (Copyright 1983)
The Unix System by SR Borne (Copyright 1983)
Introducing the Unix System by Henry McGilton and Rachel Morgan (Copyright
1983)
A User Guide to the Unix System by Rebecca Thomas and Jean Yates (Copyright
1982)

The last one is quite interesting because it has a 13 page annotated
bibliography. Here's the earlier books:

Information and Publication Division. The UNIX System. An Easier Way to
Communicate with Computers." 1979. This has a similar title to an article
by SP Morgan in Bell Laboratories Record 56 (1978).  The rest are all
clearly articles in journals and magazines back to the original in 75.

And I have the following on the way that's been mentioned before:
Using the Unix System by Richard Gauthier Command Computer Programming 1981

So there's at least 2 books that pre-date Borne's book, maybe more. There's
a second Banahan book that I ordered, but didn't get that claims to be
1982. Trying to get to the bottom of that... All of the above are tutorials
to varying degrees, though I've only reviewed the Lomuto and Thomas/Yates
books in any detail. None appear to have useful additional historic
information.

The McGilton/Morgan book is the oldest one I've seen talk about Berkeley
Unix system. The chapter was written in the spring of 1982.

And there's this gem https://www.youtube.com/watch?v=XvDZLjaCJuw that I've
seen before here I think, which is dated 1982 and is a film with the same
title "he UNIX System. An Easier Way to Communicate with Computers" as one
of the items above, so I wonder if that's this film or a paper copy of it.
It's clearly Bell Labs related, though.

Warner

On Tue, Apr 14, 2020 at 2:32 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Tue, Apr 14, 2020 at 9:27 AM Steve Mynott <steve.mynott at gmail.com>
> wrote:
>
>> On Sat, 4 Apr 2020 at 16:58, Nemo Nusquam <cym224 at gmail.com> wrote:
>> >
>> > On 04/04/20 11:05, markus schnalke wrote (in part):
>> > > Thus I now wonder what the first book on Unix, intended for a general
>> > > readership was.
>> > Not to be overly pedantic but what would be a "general readership"?
>>
>> I think the wikipedia article meant Bourne's "The Unix System"  was
>> the first general introduction to UNIX.
>>
>> In the autumn of 1984 it was a recommended text book for an
>> introduction to computing course aimed at first year science
>> undergraduates at an English university.
>>
>> They taught us awk programming and basic shell commands on a VAX
>> running BSD 4.1 using it. I still have a copy.
>>
>> So by general readership they probably meant primer.
>>
>
> I think it's not the first primer, but it's one of the first. But I'll
> know more once I process through the half dozen books from the early 80s on
> Unix that just arrived from ebay... I'll post a brief review and a
> bibliography
>
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200414/d4434a44/attachment.html>

From pnr at planet.nl  Wed Apr 15 08:07:29 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 15 Apr 2020 00:07:29 +0200
Subject: [TUHS] 4.2BSD Steering committee
Message-ID: <19A0192D-3035-4CA5-B66D-4C1D46F0CF1D@planet.nl>

According to “20 years of BSD”, there was a steering committee to inform the development of what would eventually be 4.2BSD Unix. The committee had the following members:

Duane Adams and Bob Baker: DARPA

Bob Fabry, Bill Joy, Sam Leffler: CSRG

Dennis Ritchie:  Bell Labs

Alan Nemeth, Rob Gurwitz: BBN
Dan Lynch: ISI

Keith Lantz:   Stanford
Rick Rashid:   CMU
Bert Halstead: MIT
Jerry Popek:   UCLA


I’m intrigued by the composition and the rationale for each member. Some of it is obvious, some of it is not. According to “20 years of BSD” what DARPA wanted was:

"In particular, the new system was expected to include a faster file system that would raise throughput to the speed of available disk technology, support processes with multi-gigabyte address space requirements, provide flexible interprocess communication facilities that allow researchers to do work in distributed systems, and would integrate networking support so that machines running the new system could easily participate in the ARPAnet."

As I understand Duane Adams was the contract manager and Bob Baker a DARPA vice-president. The CSRG crowd are also clear, they were going to do the work.

Then it becomes less clear.

I can certainly see the logic of asking dmr to provide his guidance, also in view of Bell Labs expertise in working with large scale communication systems. I can also see the logic of having the BBN and ISI folk there, representing the Arpanet community and doing the work on the new TCP/IP protocol stack.

I’m not sure about the four others. They seem to be one each for 4 main computer science schools in the US at the time. Rashid and Popek had moreover recently completed distributed systems (Aleph and LOCUS). Halstead seems to have been working on messaging systems at the time. I’m not sure what Lantz’ spike was at the time.

All in all, a strong focus on distributed systems and messaging. No people with apparent links to virtual memory research or disk access research. Other than dmr, no research people from industry. For example, nobody from Xerox Parc. Nobody from IBM, HP, DEC, DG, etc.

Any and all recollections about the committee and its composition welcome.



From clemc at ccc.com  Wed Apr 15 08:12:48 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 14 Apr 2020 18:12:48 -0400
Subject: [TUHS] 4.2BSD Steering committee
In-Reply-To: <19A0192D-3035-4CA5-B66D-4C1D46F0CF1D@planet.nl>
References: <19A0192D-3035-4CA5-B66D-4C1D46F0CF1D@planet.nl>
Message-ID: <CAC20D2MqBbGDJ7SbqxTi=O6rTHmdHrPW-w-Qf=NrW_vb7C5PnQ@mail.gmail.com>

On Tue, Apr 14, 2020 at 6:08 PM Paul Ruizendaal <pnr at planet.nl> wrote:

>  I’m not sure what Lantz’ spike was at the time.
>
https://en.wikipedia.org/wiki/V_(operating_system)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200414/0abb2fea/attachment.html>

From pnr at planet.nl  Wed Apr 15 09:06:10 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 15 Apr 2020 01:06:10 +0200
Subject: [TUHS] Early Datakit - Summary of findings
Message-ID: <686B5993-6772-4A0B-BAF0-90F1C882438B@planet.nl>

I’ve posted a summary of my Datakit notes here:
https://drive.google.com/open?id=1p6HD5-NSAYKfiXL6GUxfYZgGoesqG6Sp
(available for a limited time)

Hopefully, these notes are helpful for anyone trying to figure out Datakit networking in Eighth Edition.

At the user level, access is organised through the ‘dkdial’ and ‘dkmgr’ routines:
http://man.cat-v.org/unix_8th/3/dkmgr
http://man.cat-v.org/unix_8th/3/tdkdial

The IP networking is handled in the same pattern:
http://man.cat-v.org/unix_8th/3/tcp
http://man.cat-v.org/unix_8th/3/udp

The ipc set of library routines that unify these lower level routines into a single API will only appear in 9th Edition (a year later).





From efton.collins at gmail.com  Wed Apr 15 16:46:21 2020
From: efton.collins at gmail.com (Efton Collins)
Date: Wed, 15 Apr 2020 01:46:21 -0500
Subject: [TUHS] Bell Labs recruiter
Message-ID: <CAGkfwVJ2Duycy+C0ZL4+3x50MtkvJrt_Xb0+0H08_stRR1FKhg@mail.gmail.com>

I was lucky enough to be in the room last year at VCF East when Ken
told the story of how the move from Berkeley to Bell Labs happened.
Ken's description of his interactions with the Bell recruiter was
entertaining and made clear that persistent effort was needed to get
him to come out to New Jersey and meet some of the people there.

Does anyone know who the recruiter was?

From don at DonHopkins.com  Wed Apr 15 17:03:12 2020
From: don at DonHopkins.com (Don Hopkins)
Date: Wed, 15 Apr 2020 09:03:12 +0200
Subject: [TUHS] =?utf-8?q?=227th_Edition_UNIX_TM=C2=80=C2=94_Summary=22_?=
 =?utf-8?b?PT4gIsOiwoDCnDd0aCBFZGl0aW9uIFVOSVggw6LCgMKUIFN1bW1hcnnDoiA9?=
 =?utf-8?b?PiDDouKCrMWTN3RoIEVkaXRpb24gVU5JWCDDouKCrOKAnSBTdW1tYXJ5w6I=?=
 =?utf-8?b?4oKs?=
In-Reply-To: <mailman.2.1586916002.4182.tuhs@minnie.tuhs.org>
References: <mailman.2.1586916002.4182.tuhs@minnie.tuhs.org>
Message-ID: <0A51EA96-82C0-4A6E-AF30-1DFA31BD476B@gmail.com>

I love how in a discussion of how difficult it was to publish a book on Unix with the correct punctuation characters 42 years ago, we still can’t even quote the title of the book in a discussion about Unix without the punctuation characters degrading and mutating each round trip. 

Worse truly is better! ;)

-Don


From dave at horsfall.org  Wed Apr 15 18:19:57 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 15 Apr 2020 18:19:57 +1000 (EST)
Subject: [TUHS] 
 =?utf-8?q?=227th_Edition_UNIX_TM=C2=80=C2=94_Summary=22_?=
 =?utf-8?b?PT4gIsOiwoDCnDd0aCBFZGl0aW9uIFVOSVggw6LCgMKUIFN1bW1hcnnDoiA9?=
 =?utf-8?b?PiDDouKCrMWTN3RoIEVkaXRpb24gVU5JWCDDouKCrOKAnSBTdW1tYXJ5w6I=?=
 =?utf-8?b?4oKs?=
In-Reply-To: <0A51EA96-82C0-4A6E-AF30-1DFA31BD476B@gmail.com>
References: <mailman.2.1586916002.4182.tuhs@minnie.tuhs.org>
 <0A51EA96-82C0-4A6E-AF30-1DFA31BD476B@gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2004151818100.1535@aneurin.horsfall.org>

On Wed, 15 Apr 2020, Don Hopkins wrote:

> I love how in a discussion of how difficult it was to publish a book on 
> Unix with the correct punctuation characters 42 years ago, we still 
> can’t even quote the title of the book in a discussion about Unix 
> without the punctuation characters degrading and mutating each round 
> trip.

Well, I'm not the one here using Windoze...

-- Dave

From pdagog at gmail.com  Sun Apr 19 02:57:30 2020
From: pdagog at gmail.com (Pierre DAVID)
Date: Sat, 18 Apr 2020 18:57:30 +0200
Subject: [TUHS] Plan 9 from outer space ?
Message-ID: <20200418165730.GA20272@vagabond>

There is a widespred anecdote that "Plan 9" name comes from the 
movie "Plan 9 From Outer Space".

Since I didn't find anything more than a reference to this 
anecdote (see https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs 
for example), I forced myself to watch the movie until the end 
(what a pain!).

Guess what? I couldn't find the link between the film and the 
beloved OS.

I'm sure there are people here who know more. Thanks in advance 
for sharing your knowledge with us.

Pierre

From pdagog at gmail.com  Sun Apr 19 03:23:37 2020
From: pdagog at gmail.com (Pierre DAVID)
Date: Sat, 18 Apr 2020 19:23:37 +0200
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk>
References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk>
Message-ID: <20200418172337.GA22829@vagabond>

On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote:
>> There is a widespred anecdote that "Plan 9" name comes from the
>> movie "Plan 9 From Outer Space".
>
>Given that the full name is "Plan 9 from Bell Labs" I don't think
>there's much doubt about it.
>

Yes, but is there anything besides the name?

Pierre

From imp at bsdimp.com  Sun Apr 19 03:44:46 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 18 Apr 2020 11:44:46 -0600
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <20200418172337.GA22829@vagabond>
References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk>
 <20200418172337.GA22829@vagabond>
Message-ID: <CANCZdfrBkXkyQWHuF8fXKdH5w=cwAB36aMxy=t6fdARb-36tJQ@mail.gmail.com>

On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID <pdagog at gmail.com> wrote:

> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote:
> >> There is a widespred anecdote that "Plan 9" name comes from the
> >> movie "Plan 9 From Outer Space".
> >
> >Given that the full name is "Plan 9 from Bell Labs" I don't think
> >there's much doubt about it.
> >
>
> Yes, but is there anything besides the name?
>

Plan 9 is the worst movie ever. And was for many years listed as the worst
movie ever, including the formative years of plan 9.

A professor(?) at CU once told me, though I don't know if I buy it, that
plan 9 was Unix Plan B at first. There was a description that it was the
worst system ever (except for all the others) in a knod to Churchill
(supposedly based on his comment about Democracy). And from there it was a
quick jump to Plan 9 from Bell Labs as all these themes flowed together in
a mish-mash of creative naming...  With a different name, it could break
with Unix in interesting ways...

I have no clue if this is true, and I'm no longer in contact with the
professor that told me this since it was mid to late 90s, and I'm honestly
having trouble recalling his name. It wasn't a 'big name' like Evi, but I
think it was someone at CU I had a beer with (which means it could have
been a grad student to post-doc as well, it was 25 years ago and beer was
involved). It makes a great story, but I don't know if it's anything more
than that. I put it out there because I know Rob or Ken is likely to
correct something that's this detailed and specific if it's really wrong :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200418/813fbb3d/attachment.html>

From royce at techsolvency.com  Sun Apr 19 03:49:04 2020
From: royce at techsolvency.com (Royce Williams)
Date: Sat, 18 Apr 2020 09:49:04 -0800
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CANCZdfrBkXkyQWHuF8fXKdH5w=cwAB36aMxy=t6fdARb-36tJQ@mail.gmail.com>
References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk>
 <20200418172337.GA22829@vagabond>
 <CANCZdfrBkXkyQWHuF8fXKdH5w=cwAB36aMxy=t6fdARb-36tJQ@mail.gmail.com>
Message-ID: <CA+E3k91pR8S5BBJPENFPXPk7OFu47zo=fhLYHeZD5ZYaKCB-vQ@mail.gmail.com>

On Sat, Apr 18, 2020 at 9:45 AM Warner Losh <imp at bsdimp.com> wrote:

>
> On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID <pdagog at gmail.com> wrote:
>
>> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote:
>> >> There is a widespred anecdote that "Plan 9" name comes from the
>> >> movie "Plan 9 From Outer Space".
>> >
>> >Given that the full name is "Plan 9 from Bell Labs" I don't think
>> >there's much doubt about it.
>> >
>>
>> Yes, but is there anything besides the name?
>>
>
> Plan 9 is the worst movie ever. And was for many years listed as the worst
> movie ever, including the formative years of plan 9.
>
> A professor(?) at CU once told me, though I don't know if I buy it, that
> plan 9 was Unix Plan B at first. There was a description that it was the
> worst system ever (except for all the others) in a knod to Churchill
> (supposedly based on his comment about Democracy). And from there it was a
> quick jump to Plan 9 from Bell Labs as all these themes flowed together in
> a mish-mash of creative naming...  With a different name, it could break
> with Unix in interesting ways...
>
> I have no clue if this is true, and I'm no longer in contact with the
> professor that told me this since it was mid to late 90s, and I'm honestly
> having trouble recalling his name. It wasn't a 'big name' like Evi, but I
> think it was someone at CU I had a beer with (which means it could have
> been a grad student to post-doc as well, it was 25 years ago and beer was
> involved). It makes a great story, but I don't know if it's anything more
> than that. I put it out there because I know Rob or Ken is likely to
> correct something that's this detailed and specific if it's really wrong :)
>

See also:

http://9p.io/wiki/plan9/lfaq/index.html#GENERAL_INFORMATION

Royce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200418/50c9f2ba/attachment.html>

From richard at inf.ed.ac.uk  Sun Apr 19 03:20:18 2020
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Sat, 18 Apr 2020 18:20:18 +0100 (BST)
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: Pierre DAVID's message of Sat, 18 Apr 2020 18:57:30 +0200
Message-ID: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk>

> There is a widespred anecdote that "Plan 9" name comes from the 
> movie "Plan 9 From Outer Space".

Given that the full name is "Plan 9 from Bell Labs" I don't think
there's much doubt about it.

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From a.phillip.garcia at gmail.com  Sun Apr 19 04:40:05 2020
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sat, 18 Apr 2020 14:40:05 -0400
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <20200418165730.GA20272@vagabond>
References: <20200418165730.GA20272@vagabond>
Message-ID: <CAFCBnZvimRBVAA=e5mNkffF9OLLM2B4r0ht+br7zc8aHtqXtiA@mail.gmail.com>

On Sat, Apr 18, 2020, 12:58 PM Pierre DAVID <pdagog at gmail.com> wrote:

> There is a widespred anecdote that "Plan 9" name comes from the
> movie "Plan 9 From Outer Space".
>
> Since I didn't find anything more than a reference to this
> anecdote (see https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
> for example), I forced myself to watch the movie until the end
> (what a pain!).
>
> Guess what? I couldn't find the link between the film and the
> beloved OS.
>
> I'm sure there are people here who know more. Thanks in advance
> for sharing your knowledge with us.
>
> Pierre
>

Someone posted some pictures of the office area at Murray Hill to this
list. I seem to recall A plan 9 from outer space poster hanging.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200418/d4cd039b/attachment.html>

From dave at horsfall.org  Sun Apr 19 07:38:58 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 19 Apr 2020 07:38:58 +1000 (EST)
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <20200418165730.GA20272@vagabond>
References: <20200418165730.GA20272@vagabond>
Message-ID: <alpine.BSF.2.21.9999.2004190729540.1535@aneurin.horsfall.org>

On Sat, 18 Apr 2020, Pierre DAVID wrote:

> Since I didn't find anything more than a reference to this anecdote (see 
> https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs for example), I 
> forced myself to watch the movie until the end (what a pain!).

Trust me, there are even worse movies...  The colourised ones, for 
example, out of Hollywood (aarrgghh!).

(Follow-ups to COFF, of course)

-- Dave, who thinks that the best films were early B&W ones

From robpike at gmail.com  Sun Apr 19 08:26:16 2020
From: robpike at gmail.com (Rob Pike)
Date: Sun, 19 Apr 2020 08:26:16 +1000
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CA+E3k91pR8S5BBJPENFPXPk7OFu47zo=fhLYHeZD5ZYaKCB-vQ@mail.gmail.com>
References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk>
 <20200418172337.GA22829@vagabond>
 <CANCZdfrBkXkyQWHuF8fXKdH5w=cwAB36aMxy=t6fdARb-36tJQ@mail.gmail.com>
 <CA+E3k91pR8S5BBJPENFPXPk7OFu47zo=fhLYHeZD5ZYaKCB-vQ@mail.gmail.com>
Message-ID: <CAKzdPgyjNt-_YO92tKO4LDOEE+k1ejYzvAzVTx4pRB9vEq+yaQ@mail.gmail.com>

As it says there,



*The hermeneutics of naming yields few insights. Things are named usually
because the name is nice (sam), or there is some private reference hard to
decode (8½), or in honour (perhaps backhanded) of another system (mothra),
or an indication of expectation (Plan 9, acme), or just because (acid).
None of the names tell you anything helpful.Despite the lack of
information, those who guess at reasons for naming generate volumes of
apocrypha. The real reason is usually, ``because''.*

-rob



On Sun, Apr 19, 2020 at 3:50 AM Royce Williams <royce at techsolvency.com>
wrote:

> On Sat, Apr 18, 2020 at 9:45 AM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>> On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID <pdagog at gmail.com> wrote:
>>
>>> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote:
>>> >> There is a widespred anecdote that "Plan 9" name comes from the
>>> >> movie "Plan 9 From Outer Space".
>>> >
>>> >Given that the full name is "Plan 9 from Bell Labs" I don't think
>>> >there's much doubt about it.
>>> >
>>>
>>> Yes, but is there anything besides the name?
>>>
>>
>> Plan 9 is the worst movie ever. And was for many years listed as the
>> worst movie ever, including the formative years of plan 9.
>>
>> A professor(?) at CU once told me, though I don't know if I buy it, that
>> plan 9 was Unix Plan B at first. There was a description that it was the
>> worst system ever (except for all the others) in a knod to Churchill
>> (supposedly based on his comment about Democracy). And from there it was a
>> quick jump to Plan 9 from Bell Labs as all these themes flowed together in
>> a mish-mash of creative naming...  With a different name, it could break
>> with Unix in interesting ways...
>>
>> I have no clue if this is true, and I'm no longer in contact with the
>> professor that told me this since it was mid to late 90s, and I'm honestly
>> having trouble recalling his name. It wasn't a 'big name' like Evi, but I
>> think it was someone at CU I had a beer with (which means it could have
>> been a grad student to post-doc as well, it was 25 years ago and beer was
>> involved). It makes a great story, but I don't know if it's anything more
>> than that. I put it out there because I know Rob or Ken is likely to
>> correct something that's this detailed and specific if it's really wrong :)
>>
>
> See also:
>
> http://9p.io/wiki/plan9/lfaq/index.html#GENERAL_INFORMATION
>
> Royce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200419/69f05670/attachment.html>

From robpike at gmail.com  Sun Apr 19 11:28:29 2020
From: robpike at gmail.com (Rob Pike)
Date: Sun, 19 Apr 2020 11:28:29 +1000
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAG=a+rgFs6ZB9X7H=hZnP4thm4r0xP_2c-apfeOEbM936zXkaA@mail.gmail.com>
References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk>
 <20200418172337.GA22829@vagabond>
 <CANCZdfrBkXkyQWHuF8fXKdH5w=cwAB36aMxy=t6fdARb-36tJQ@mail.gmail.com>
 <CA+E3k91pR8S5BBJPENFPXPk7OFu47zo=fhLYHeZD5ZYaKCB-vQ@mail.gmail.com>
 <CAKzdPgyjNt-_YO92tKO4LDOEE+k1ejYzvAzVTx4pRB9vEq+yaQ@mail.gmail.com>
 <CAG=a+rgFs6ZB9X7H=hZnP4thm4r0xP_2c-apfeOEbM936zXkaA@mail.gmail.com>
Message-ID: <CAKzdPgxbyrKmHN3-=P_fnkN0GYkOcdOjGKX9-VxmmTOwfJxVtg@mail.gmail.com>

It wasn't my intention.

-rob

On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson <ken at google.com> wrote:
>
> rob,
> you shouldn't have shut down this discussion.
>
>
> On Sat, Apr 18, 2020 at 3:27 PM Rob Pike <robpike at gmail.com> wrote:
>>
>> As it says there,
>>
>> The hermeneutics of naming yields few insights. Things are named usually because the name is nice (sam), or there is some private reference hard to decode (8½), or in honour (perhaps backhanded) of another system (mothra), or an indication of expectation (Plan 9, acme), or just because (acid). None of the names tell you anything helpful.
>>
>> Despite the lack of information, those who guess at reasons for naming generate volumes of apocrypha. The real reason is usually, ``because''.
>>
>> -rob
>>
>>
>>
>> On Sun, Apr 19, 2020 at 3:50 AM Royce Williams <royce at techsolvency.com> wrote:
>>>
>>> On Sat, Apr 18, 2020 at 9:45 AM Warner Losh <imp at bsdimp.com> wrote:
>>>>
>>>>
>>>> On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID <pdagog at gmail.com> wrote:
>>>>>
>>>>> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote:
>>>>> >> There is a widespred anecdote that "Plan 9" name comes from the
>>>>> >> movie "Plan 9 From Outer Space".
>>>>> >
>>>>> >Given that the full name is "Plan 9 from Bell Labs" I don't think
>>>>> >there's much doubt about it.
>>>>> >
>>>>>
>>>>> Yes, but is there anything besides the name?
>>>>
>>>>
>>>> Plan 9 is the worst movie ever. And was for many years listed as the worst movie ever, including the formative years of plan 9.
>>>>
>>>> A professor(?) at CU once told me, though I don't know if I buy it, that plan 9 was Unix Plan B at first. There was a description that it was the worst system ever (except for all the others) in a knod to Churchill (supposedly based on his comment about Democracy). And from there it was a quick jump to Plan 9 from Bell Labs as all these themes flowed together in a mish-mash of creative naming...  With a different name, it could break with Unix in interesting ways...
>>>>
>>>> I have no clue if this is true, and I'm no longer in contact with the professor that told me this since it was mid to late 90s, and I'm honestly having trouble recalling his name. It wasn't a 'big name' like Evi, but I think it was someone at CU I had a beer with (which means it could have been a grad student to post-doc as well, it was 25 years ago and beer was involved). It makes a great story, but I don't know if it's anything more than that. I put it out there because I know Rob or Ken is likely to correct something that's this detailed and specific if it's really wrong :)
>>>
>>>
>>> See also:
>>>
>>> http://9p.io/wiki/plan9/lfaq/index.html#GENERAL_INFORMATION
>>>
>>> Royce

From athornton at gmail.com  Sun Apr 19 12:51:22 2020
From: athornton at gmail.com (Adam Thornton)
Date: Sat, 18 Apr 2020 19:51:22 -0700
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAKzdPgxbyrKmHN3-=P_fnkN0GYkOcdOjGKX9-VxmmTOwfJxVtg@mail.gmail.com>
References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk>
 <20200418172337.GA22829@vagabond>
 <CANCZdfrBkXkyQWHuF8fXKdH5w=cwAB36aMxy=t6fdARb-36tJQ@mail.gmail.com>
 <CA+E3k91pR8S5BBJPENFPXPk7OFu47zo=fhLYHeZD5ZYaKCB-vQ@mail.gmail.com>
 <CAKzdPgyjNt-_YO92tKO4LDOEE+k1ejYzvAzVTx4pRB9vEq+yaQ@mail.gmail.com>
 <CAG=a+rgFs6ZB9X7H=hZnP4thm4r0xP_2c-apfeOEbM936zXkaA@mail.gmail.com>
 <CAKzdPgxbyrKmHN3-=P_fnkN0GYkOcdOjGKX9-VxmmTOwfJxVtg@mail.gmail.com>
Message-ID: <2F517789-DDA2-4475-90DD-E0D8B946ED57@gmail.com>

So it could be the lack of televised sports getting to me in these shelter-in-place days, but, I mean, sure, I guess I’ll throw in some bucks for a pay-per-view of a Pike/Thompson cage match.  FIGHT!

Followups set.

> On Apr 18, 2020, at 6:28 PM, Rob Pike <robpike at gmail.com> wrote:
> It wasn't my intention.
> On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson <ken at google.com> wrote:
>> 
>> you shouldn't have shut down this discussion.
>> On Sat, Apr 18, 2020 at 3:27 PM Rob Pike <robpike at gmail.com> wrote:
>>>  ``because''.


From doug at cs.dartmouth.edu  Sun Apr 19 13:09:46 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 18 Apr 2020 23:09:46 -0400
Subject: [TUHS] Plan 9 from outer space ?
Message-ID: <202004190309.03J39knr075360@tahoe.cs.Dartmouth.EDU>

I'll keep it going. rc was a startup script from very early
times in Unix, shortened, as Ken was wont to do, from runcom,
the nearest thing CTSS had to a shell--it could run up to
six prespecified commands in background. The name runcom
came to be applied to the scripts as well as to their
interpreter.

Doug

-------------------------------------


It wasn't my intention.

-rob

On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson <ken at google.com> wrote:
>
> rob,
> you shouldn't have shut down this discussion.

From norman at oclsc.org  Mon Apr 20 00:35:34 2020
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 19 Apr 2020 10:35:34 -0400 (EDT)
Subject: [TUHS] Plan 9 from outer space ?
Message-ID: <20200419143534.D96C94422F@lignose.oclsc.org>

I asked a friend who was around at the time (I think he and
Rob worked together at times).  Here's what he recalls:

  I'll keep it going.  rc was a description that it was the worst movie
  ever.  And was for many years listed as the worst system ever (except
  for all the others) in a mish-mash of creative naming...  I have no clue
  if this is true, and I'm honestly having trouble recalling his name.
  It wasn't my intention.

  There was a description that it was a startup script from very early
  times in Unix, shortened, as Ken was wont to do, from runcom, the nearest
  thing CTSS had to a shell--it could run up to six prespecified commands
  in background.  It wasn't a 'big name' like Evi, but I don't know if I buy
  it, that plan 9 from outer space poster hanging.  Plan 9 from Bell Labs
  as all these themes flowed together in a mish-mash of creative naming...
  With a different name, it could be the lack of information, those who
  guess at reasons for naming generate volumes of apocrypha.

  The real reason is usually, ``because''.* Trust me, there are even
  worse movies...  Someone posted some pictures of the names tell you
  anything helpful. Despite the lack of televised sports getting to me
  in these shelter-in-place days, but, I mean, sure, I guess I'll throw
  in some bucks for a pay-per-view of a Pike/Thompson cage match.  FIGHT!
  Followups set.

  Things are named usually because the name is "Plan 9 from outer space
  poster hanging.  None of the office area at Murray Hill to this list.
  Plan 9 is the worst system ever (except for all the others) in a
  knod to Churchill (supposedly based on his comment about Democracy).
  And from there it was 25 years ago and beer was involved).  It makes
  a great story, but I don't think there's much doubt about it.  And was
  for many years listed as the worst movie ever, including the formative
  years of plan 9.  Yes, but is there anything besides the name?  There is
  a widespred anecdote that "Plan 9" name comes from the movie until the
  end (what a pain!).

  _-_-_-_-Mark

Norman Wilson
Toronto ON

From bigato at bus142.net  Mon Apr 20 01:59:22 2020
From: bigato at bus142.net (Daniel Camoles)
Date: Sun, 19 Apr 2020 12:59:22 -0300
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <20200419143534.D96C94422F@lignose.oclsc.org>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
Message-ID: <C84B0821-70E7-45DF-9951-F60A7A6E1C9C@bus142.net>

I’m surprised no one mentioned the Brazil movie so far, and rio named from that. I seem to remember that before being called Plan 9 it was called Brazil because of the movie. Did I dream that?

> Em 19 de abr de 2020, à(s) 11:37, Norman Wilson <norman at oclsc.org> escreveu:
> 
> ﻿I asked a friend who was around at the time (I think he and
> Rob worked together at times).  Here's what he recalls:
> 
>  I'll keep it going.  rc was a description that it was the worst movie
>  ever.  And was for many years listed as the worst system ever (except
>  for all the others) in a mish-mash of creative naming...  I have no clue
>  if this is true, and I'm honestly having trouble recalling his name.
>  It wasn't my intention.
> 
>  There was a description that it was a startup script from very early
>  times in Unix, shortened, as Ken was wont to do, from runcom, the nearest
>  thing CTSS had to a shell--it could run up to six prespecified commands
>  in background.  It wasn't a 'big name' like Evi, but I don't know if I buy
>  it, that plan 9 from outer space poster hanging.  Plan 9 from Bell Labs
>  as all these themes flowed together in a mish-mash of creative naming...
>  With a different name, it could be the lack of information, those who
>  guess at reasons for naming generate volumes of apocrypha.
> 
>  The real reason is usually, ``because''.* Trust me, there are even
>  worse movies...  Someone posted some pictures of the names tell you
>  anything helpful. Despite the lack of televised sports getting to me
>  in these shelter-in-place days, but, I mean, sure, I guess I'll throw
>  in some bucks for a pay-per-view of a Pike/Thompson cage match.  FIGHT!
>  Followups set.
> 
>  Things are named usually because the name is "Plan 9 from outer space
>  poster hanging.  None of the office area at Murray Hill to this list.
>  Plan 9 is the worst system ever (except for all the others) in a
>  knod to Churchill (supposedly based on his comment about Democracy).
>  And from there it was 25 years ago and beer was involved).  It makes
>  a great story, but I don't think there's much doubt about it.  And was
>  for many years listed as the worst movie ever, including the formative
>  years of plan 9.  Yes, but is there anything besides the name?  There is
>  a widespred anecdote that "Plan 9" name comes from the movie until the
>  end (what a pain!).
> 
>  _-_-_-_-Mark
> 
> Norman Wilson
> Toronto ON


From robpike at gmail.com  Mon Apr 20 08:19:33 2020
From: robpike at gmail.com (Rob Pike)
Date: Mon, 20 Apr 2020 08:19:33 +1000
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <C84B0821-70E7-45DF-9951-F60A7A6E1C9C@bus142.net>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <C84B0821-70E7-45DF-9951-F60A7A6E1C9C@bus142.net>
Message-ID: <CAKzdPgyuNHKZsGbieR+H6xgRQnAkr+_xHjTT_MB2gde17NB1Ww@mail.gmail.com>

Rio is a reference to a different movie, not to Brazil. Brazil is a
reference to Brazil. Hope that helps.

-rob

On Mon, Apr 20, 2020 at 2:07 AM Daniel Camoles <bigato at bus142.net> wrote:
>
> I’m surprised no one mentioned the Brazil movie so far, and rio named from that. I seem to remember that before being called Plan 9 it was called Brazil because of the movie. Did I dream that?
>
> > Em 19 de abr de 2020, à(s) 11:37, Norman Wilson <norman at oclsc.org> escreveu:
> >
> > ﻿I asked a friend who was around at the time (I think he and
> > Rob worked together at times).  Here's what he recalls:
> >
> >  I'll keep it going.  rc was a description that it was the worst movie
> >  ever.  And was for many years listed as the worst system ever (except
> >  for all the others) in a mish-mash of creative naming...  I have no clue
> >  if this is true, and I'm honestly having trouble recalling his name.
> >  It wasn't my intention.
> >
> >  There was a description that it was a startup script from very early
> >  times in Unix, shortened, as Ken was wont to do, from runcom, the nearest
> >  thing CTSS had to a shell--it could run up to six prespecified commands
> >  in background.  It wasn't a 'big name' like Evi, but I don't know if I buy
> >  it, that plan 9 from outer space poster hanging.  Plan 9 from Bell Labs
> >  as all these themes flowed together in a mish-mash of creative naming...
> >  With a different name, it could be the lack of information, those who
> >  guess at reasons for naming generate volumes of apocrypha.
> >
> >  The real reason is usually, ``because''.* Trust me, there are even
> >  worse movies...  Someone posted some pictures of the names tell you
> >  anything helpful. Despite the lack of televised sports getting to me
> >  in these shelter-in-place days, but, I mean, sure, I guess I'll throw
> >  in some bucks for a pay-per-view of a Pike/Thompson cage match.  FIGHT!
> >  Followups set.
> >
> >  Things are named usually because the name is "Plan 9 from outer space
> >  poster hanging.  None of the office area at Murray Hill to this list.
> >  Plan 9 is the worst system ever (except for all the others) in a
> >  knod to Churchill (supposedly based on his comment about Democracy).
> >  And from there it was 25 years ago and beer was involved).  It makes
> >  a great story, but I don't think there's much doubt about it.  And was
> >  for many years listed as the worst movie ever, including the formative
> >  years of plan 9.  Yes, but is there anything besides the name?  There is
> >  a widespred anecdote that "Plan 9" name comes from the movie until the
> >  end (what a pain!).
> >
> >  _-_-_-_-Mark
> >
> > Norman Wilson
> > Toronto ON
>

From a.phillip.garcia at gmail.com  Mon Apr 20 09:42:19 2020
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sun, 19 Apr 2020 19:42:19 -0400
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <20200419143534.D96C94422F@lignose.oclsc.org>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
Message-ID: <CAFCBnZv7NFmiFDVr1MbK9ZZSCXv-UU56aABiEfUGsW+kRqfo=w@mail.gmail.com>

On Sun, Apr 19, 2020, 10:37 AM Norman Wilson <norman at oclsc.org> wrote:

> I asked a friend who was around at the time (I think he and
> Rob worked together at times).  Here's what he recalls:
>
>   I'll keep it going.  rc was a description that it was the worst movie
>   ever.  And was for many years listed as the worst system ever (except
>   for all the others) in a mish-mash of creative naming...
>
<snip>

>   _-_-_-_-Mark


Mark V Chaney!

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200419/de8b0abc/attachment.html>

From musher at ucsc.edu  Mon Apr 20 12:27:12 2020
From: musher at ucsc.edu (Michael Usher)
Date: Sun, 19 Apr 2020 19:27:12 -0700
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAFCBnZv7NFmiFDVr1MbK9ZZSCXv-UU56aABiEfUGsW+kRqfo=w@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <CAFCBnZv7NFmiFDVr1MbK9ZZSCXv-UU56aABiEfUGsW+kRqfo=w@mail.gmail.com>
Message-ID: <CACg3+DHsksX4DJhrCKEQ17+f_+ZGj84=uefwvraRNSAAVKSfCA@mail.gmail.com>

I think this reflects a very static view of hermeneutics.  Just because a
term "meant" something at the time of its first use, doesn't mean that one
should ignore all of the modification of that meaning subsequently.
Language is truly a virus of a type that evolves over time as it is
adjusted by its tree of hosts.

I think you can separate the initial intent of a label from its current
usage.

I wonder what mvs would have said to that.  Didn't he read sci.philosophy
at one point?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200419/5382235b/attachment.html>

From robpike at gmail.com  Mon Apr 20 12:50:05 2020
From: robpike at gmail.com (Rob Pike)
Date: Mon, 20 Apr 2020 12:50:05 +1000
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CACg3+DHsksX4DJhrCKEQ17+f_+ZGj84=uefwvraRNSAAVKSfCA@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <CAFCBnZv7NFmiFDVr1MbK9ZZSCXv-UU56aABiEfUGsW+kRqfo=w@mail.gmail.com>
 <CACg3+DHsksX4DJhrCKEQ17+f_+ZGj84=uefwvraRNSAAVKSfCA@mail.gmail.com>
Message-ID: <CAKzdPgx-XsNTs-UVahCq5oH6rJDD9sGyCedyT+eZDR41_DiNzQ@mail.gmail.com>

A name that refers to something does not imply some form of metempsychosis.
Sometimes a cigar is just a cigar.

-rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200420/2920e6da/attachment.html>

From ggm at algebras.org  Mon Apr 20 13:08:06 2020
From: ggm at algebras.org (George Michaelson)
Date: Mon, 20 Apr 2020 13:08:06 +1000
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAKzdPgx-XsNTs-UVahCq5oH6rJDD9sGyCedyT+eZDR41_DiNzQ@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <CAFCBnZv7NFmiFDVr1MbK9ZZSCXv-UU56aABiEfUGsW+kRqfo=w@mail.gmail.com>
 <CACg3+DHsksX4DJhrCKEQ17+f_+ZGj84=uefwvraRNSAAVKSfCA@mail.gmail.com>
 <CAKzdPgx-XsNTs-UVahCq5oH6rJDD9sGyCedyT+eZDR41_DiNzQ@mail.gmail.com>
Message-ID: <CAKr6gn1pv_crfQdT+CcFPqn+xJ6ow06eC12wyeWZw7114m-Y+w@mail.gmail.com>

Sometimes a cigar is just a cigar, but "ceci, n'est pas un pipe" is
also true: just because you called it a cigar, doesn't mean it can't
be a fish.

The version I heard once, was "hitch the wagon to the engine and see
what entrains" where every one of hitch, wagon, engine, entrain does
not refer in any way to railways, or even "wagons" if its shakespeare.

It is not very useful to try and have a conversation about anything
EXCEPT the mutability of words, if you don't actually agree what the
words mean in context. I think this may be why Haskell draws a
distinction between things of type Integer and the specific intent
behind "int" and I could be drawn to say the whole 8/16/32/64/128
problem inherent in (unsigned (long) ) int is kind-of more of a
problem than not.  If we'd selected IPv6 as 64 bit quantities then
because at the time the 32/64 division of intent was mostly ok, we'd
be good. We went to 128: GCC (sorry) doesn't handle unsigned 128 bit
quantities well. A problem ensues.

On Mon, Apr 20, 2020 at 12:50 PM Rob Pike <robpike at gmail.com> wrote:
>
> A name that refers to something does not imply some form of metempsychosis. Sometimes a cigar is just a cigar.
>
> -rob
>

From imp at bsdimp.com  Mon Apr 20 14:39:52 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 19 Apr 2020 22:39:52 -0600
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAKzdPgx-XsNTs-UVahCq5oH6rJDD9sGyCedyT+eZDR41_DiNzQ@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <CAFCBnZv7NFmiFDVr1MbK9ZZSCXv-UU56aABiEfUGsW+kRqfo=w@mail.gmail.com>
 <CACg3+DHsksX4DJhrCKEQ17+f_+ZGj84=uefwvraRNSAAVKSfCA@mail.gmail.com>
 <CAKzdPgx-XsNTs-UVahCq5oH6rJDD9sGyCedyT+eZDR41_DiNzQ@mail.gmail.com>
Message-ID: <CANCZdfpOvpjUcKi-ng3bW4u8oByc7dArH1F-3J9nqJ9KmhLRzQ@mail.gmail.com>

On Sun, Apr 19, 2020, 8:50 PM Rob Pike <robpike at gmail.com> wrote:

> A name that refers to something does not imply some form of
> metempsychosis. Sometimes a cigar is just a cigar.
>


"We named stuff for a combination of movies we were into, inside jokes and
occasionally after repurposed historical names for new animals." Don't
overthink it.

Warner

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200419/fd7365b6/attachment.html>

From arnold at skeeve.com  Mon Apr 20 17:42:07 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 20 Apr 2020 01:42:07 -0600
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAKzdPgyuNHKZsGbieR+H6xgRQnAkr+_xHjTT_MB2gde17NB1Ww@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <C84B0821-70E7-45DF-9951-F60A7A6E1C9C@bus142.net>
 <CAKzdPgyuNHKZsGbieR+H6xgRQnAkr+_xHjTT_MB2gde17NB1Ww@mail.gmail.com>
Message-ID: <202004200742.03K7g7b9018092@freefriends.org>

Rob Pike <robpike at gmail.com> wrote:

> Rio is a reference to a different movie, not to Brazil. Brazil is a
> reference to Brazil. Hope that helps.
>
> -rob

What movie is Rio a reference to?

Thanks,

Arnold

From pnr at planet.nl  Mon Apr 20 23:59:58 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 20 Apr 2020 15:59:58 +0200
Subject: [TUHS] 8th Edition and /dev/stdio
Message-ID: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>

Whilst spelunking in the V8 source code I came across this dozen lines:
http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187

It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful.

As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages.

Who added this neat little innovation?



From arnold at skeeve.com  Tue Apr 21 00:28:53 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 20 Apr 2020 08:28:53 -0600
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
Message-ID: <202004201428.03KESrgI032002@freefriends.org>

See if there are man pages for /dev/fd/XXX.  IIRC /dev/stdin was
a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2,
and, as a really nice generalization, /dev/tty to /dev/fd/4.  For the
latter, init(1) simply dup'ed the opened tty file descriptor one more
time before exec-ing login.

HTH,

Arnold

Paul Ruizendaal <pnr at planet.nl> wrote:

> Whilst spelunking in the V8 source code I came across this dozen lines:
> http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187
>
> It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful.
>
> As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages.
>
> Who added this neat little innovation?
>
>

From pnr at planet.nl  Tue Apr 21 01:01:57 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 20 Apr 2020 17:01:57 +0200
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <202004201428.03KESrgI032002@freefriends.org>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
Message-ID: <D0EB9CF4-333A-43D1-9DA1-06DFF87CCD5D@planet.nl>

Thanks for that!

Indeed they are on the /dev/fd man page of 8th Edition.

I’m thrilled that https://unix50.org is back up and could quickly check. They are not symlinks, but character special files (with the same major/minor, of course). In the /dev/fd directory all 128 possible device entries were added.

It certainly suggests that a virtual /dev directory (like /proc) would have been useful.

>> Who added this neat little innovation?

Googling for /dev/fd also answered my other question: http://poincare.matf.bg.ac.rs/~ivana/courses/ps/sistemi_knjige/pomocno/apue/APUE/0201433079/ch03lev1sec16.html

"The /dev/fd feature was developed by Tom Duff and appeared in the 8th Edition of the Research UNIX System.”



> On 20 Apr 2020, at 16:28, arnold at skeeve.com wrote:
> 
> See if there are man pages for /dev/fd/XXX.  IIRC /dev/stdin was
> a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2,
> and, as a really nice generalization, /dev/tty to /dev/fd/4.  For the
> latter, init(1) simply dup'ed the opened tty file descriptor one more
> time before exec-ing login.
> 
> HTH,
> 
> Arnold
> 
> Paul Ruizendaal <pnr at planet.nl> wrote:
> 
>> Whilst spelunking in the V8 source code I came across this dozen lines:
>> http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187
>> 
>> It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful.
>> 
>> As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages.
>> 
>> Who added this neat little innovation?
>> 
>> 


From arnold at skeeve.com  Tue Apr 21 01:16:43 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 20 Apr 2020 09:16:43 -0600
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <D0EB9CF4-333A-43D1-9DA1-06DFF87CCD5D@planet.nl>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
 <D0EB9CF4-333A-43D1-9DA1-06DFF87CCD5D@planet.nl>
Message-ID: <202004201516.03KFGhPd001645@freefriends.org>

Glad to have helped. Maybe later systems did the symlink.  I'm pretty sure SVR4 and later Linux did
it with symlinks.

SVR4 went overboard - /dev/fd was a separate file system type!

Arnold

Paul Ruizendaal <pnr at planet.nl> wrote:

> Thanks for that!
>
> Indeed they are on the /dev/fd man page of 8th Edition.
>
> I’m thrilled that https://unix50.org is back up and could quickly check. They are not symlinks, but character special files (with the same major/minor, of course). In the /dev/fd directory all 128 possible device entries were added.
>
> It certainly suggests that a virtual /dev directory (like /proc) would have been useful.
>
> >> Who added this neat little innovation?
>
> Googling for /dev/fd also answered my other question: http://poincare.matf.bg.ac.rs/~ivana/courses/ps/sistemi_knjige/pomocno/apue/APUE/0201433079/ch03lev1sec16.html
>
> "The /dev/fd feature was developed by Tom Duff and appeared in the 8th Edition of the Research UNIX System.”
>
>
>
> > On 20 Apr 2020, at 16:28, arnold at skeeve.com wrote:
> > 
> > See if there are man pages for /dev/fd/XXX.  IIRC /dev/stdin was
> > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2,
> > and, as a really nice generalization, /dev/tty to /dev/fd/4.  For the
> > latter, init(1) simply dup'ed the opened tty file descriptor one more
> > time before exec-ing login.
> > 
> > HTH,
> > 
> > Arnold
> > 
> > Paul Ruizendaal <pnr at planet.nl> wrote:
> > 
> >> Whilst spelunking in the V8 source code I came across this dozen lines:
> >> http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187
> >> 
> >> It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful.
> >> 
> >> As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages.
> >> 
> >> Who added this neat little innovation?
> >> 
> >> 
>

From cbbrowne at gmail.com  Tue Apr 21 03:35:58 2020
From: cbbrowne at gmail.com (Christopher Browne)
Date: Mon, 20 Apr 2020 13:35:58 -0400
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <202004200742.03K7g7b9018092@freefriends.org>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <C84B0821-70E7-45DF-9951-F60A7A6E1C9C@bus142.net>
 <CAKzdPgyuNHKZsGbieR+H6xgRQnAkr+_xHjTT_MB2gde17NB1Ww@mail.gmail.com>
 <202004200742.03K7g7b9018092@freefriends.org>
Message-ID: <CAFNqd5X-PcWVD6N4h=u3uqaukSd1xVYSCTfrhqaD=sf=J4uMfQ@mail.gmail.com>

On Mon, 20 Apr 2020 at 03:43, <arnold at skeeve.com> wrote:

> Rob Pike <robpike at gmail.com> wrote:
>
> > Rio is a reference to a different movie, not to Brazil. Brazil is a
> > reference to Brazil. Hope that helps.
> >
> > -rob
>
> What movie is Rio a reference to?
>

I imagine there's some bad romantic comedy movie starring Michael Caine to
Blame It On...

Timing seems about right.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200420/1e7e7cac/attachment.html>

From pnr at planet.nl  Tue Apr 21 03:58:59 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 20 Apr 2020 19:58:59 +0200
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <202004201516.03KFGhPd001645@freefriends.org>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
 <D0EB9CF4-333A-43D1-9DA1-06DFF87CCD5D@planet.nl>
 <202004201516.03KFGhPd001645@freefriends.org>
Message-ID: <86CC0B00-8BDA-4896-B288-D987E2D0AB59@planet.nl>

I looked through the later Editions. 9th is the same as 8th.

In the 10th edition the hack is replaced by an equally small, slightly naughty, but otherwise normal device driver:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/sys/io/fd.c <https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/sys/io/fd.c>

This approach, too, would have worked as early as 4th edition.

> On Apr 20, 2020, at 5:16 PM, arnold at skeeve.com wrote:
> 
> Glad to have helped. Maybe later systems did the symlink.  I'm pretty sure SVR4 and later Linux did
> it with symlinks.
> 
> SVR4 went overboard - /dev/fd was a separate file system type!
> 
> Arnold
> 
> Paul Ruizendaal <pnr at planet.nl> wrote:
> 
>> Thanks for that!
>> 
>> Indeed they are on the /dev/fd man page of 8th Edition.
>> 
>> I’m thrilled that https://unix50.org is back up and could quickly check. They are not symlinks, but character special files (with the same major/minor, of course). In the /dev/fd directory all 128 possible device entries were added.
>> 
>> It certainly suggests that a virtual /dev directory (like /proc) would have been useful.
>> 
>>>> Who added this neat little innovation?
>> 
>> Googling for /dev/fd also answered my other question: http://poincare.matf.bg.ac.rs/~ivana/courses/ps/sistemi_knjige/pomocno/apue/APUE/0201433079/ch03lev1sec16.html
>> 
>> "The /dev/fd feature was developed by Tom Duff and appeared in the 8th Edition of the Research UNIX System.”
>> 
>> 
>> 
>>> On 20 Apr 2020, at 16:28, arnold at skeeve.com wrote:
>>> 
>>> See if there are man pages for /dev/fd/XXX.  IIRC /dev/stdin was
>>> a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2,
>>> and, as a really nice generalization, /dev/tty to /dev/fd/4.  For the
>>> latter, init(1) simply dup'ed the opened tty file descriptor one more
>>> time before exec-ing login.
>>> 
>>> HTH,
>>> 
>>> Arnold
>>> 
>>> Paul Ruizendaal <pnr at planet.nl> wrote:
>>> 
>>>> Whilst spelunking in the V8 source code I came across this dozen lines:
>>>> http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187
>>>> 
>>>> It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful.
>>>> 
>>>> As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages.
>>>> 
>>>> Who added this neat little innovation?
>>>> 
>>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200420/9499fd83/attachment.html>

From dfawcus+lists-tuhs at employees.org  Tue Apr 21 04:17:13 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Mon, 20 Apr 2020 19:17:13 +0100
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <202004201428.03KESrgI032002@freefriends.org>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
Message-ID: <20200420181713.GB51234@clarinet.employees.org>

On Mon, Apr 20, 2020 at 08:28:53AM -0600, arnold at skeeve.com wrote:
> See if there are man pages for /dev/fd/XXX.  IIRC /dev/stdin was
> a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2,
> and, as a really nice generalization, /dev/tty to /dev/fd/4.  For the
> latter, init(1) simply dup'ed the opened tty file descriptor one more
> time before exec-ing login.

So what happened to /dev/fd/3 ?

DF

From arnold at skeeve.com  Tue Apr 21 04:32:32 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 20 Apr 2020 12:32:32 -0600
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <20200420181713.GB51234@clarinet.employees.org>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
 <20200420181713.GB51234@clarinet.employees.org>
Message-ID: <202004201832.03KIWWeJ008975@freefriends.org>

Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:

> On Mon, Apr 20, 2020 at 08:28:53AM -0600, arnold at skeeve.com wrote:
> > See if there are man pages for /dev/fd/XXX.  IIRC /dev/stdin was
> > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2,
> > and, as a really nice generalization, /dev/tty to /dev/fd/4.  For the
> > latter, init(1) simply dup'ed the opened tty file descriptor one more
> > time before exec-ing login.
>
> So what happened to /dev/fd/3 ?
>
> DF

My bad. I meant /dev/fd/3.  What was cute was that /dev/tty was
no longer a special device of it's own, but just another inherited
open file descriptor.  

Sadly, that generalization never made it out into other *nix systems.

Arnold

From robpike at gmail.com  Tue Apr 21 06:49:04 2020
From: robpike at gmail.com (Rob Pike)
Date: Tue, 21 Apr 2020 06:49:04 +1000
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAFNqd5X-PcWVD6N4h=u3uqaukSd1xVYSCTfrhqaD=sf=J4uMfQ@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <C84B0821-70E7-45DF-9951-F60A7A6E1C9C@bus142.net>
 <CAKzdPgyuNHKZsGbieR+H6xgRQnAkr+_xHjTT_MB2gde17NB1Ww@mail.gmail.com>
 <202004200742.03K7g7b9018092@freefriends.org>
 <CAFNqd5X-PcWVD6N4h=u3uqaukSd1xVYSCTfrhqaD=sf=J4uMfQ@mail.gmail.com>
Message-ID: <CAKzdPgygwxN2eAsjBBTdS_BgH__dk-AzDEH60oY7Fuv6=79b+g@mail.gmail.com>

No, that's not it. You have the wrong actor. The right one appears in the
rio source.

-rob


On Tue, Apr 21, 2020 at 3:37 AM Christopher Browne <cbbrowne at gmail.com>
wrote:

>
>
> On Mon, 20 Apr 2020 at 03:43, <arnold at skeeve.com> wrote:
>
>> Rob Pike <robpike at gmail.com> wrote:
>>
>> > Rio is a reference to a different movie, not to Brazil. Brazil is a
>> > reference to Brazil. Hope that helps.
>> >
>> > -rob
>>
>> What movie is Rio a reference to?
>>
>
> I imagine there's some bad romantic comedy movie starring Michael Caine to
> Blame It On...
>
> Timing seems about right.
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200421/07c552a1/attachment.html>

From imp at bsdimp.com  Wed Apr 22 10:50:31 2020
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 21 Apr 2020 18:50:31 -0600
Subject: [TUHS] Usenix tapes
Message-ID: <CANCZdfq9HhCQKG+FnEv56T4CK6d8HhN0EryyCt5NBgH7r3pa3w@mail.gmail.com>

So in the archives we have tapes from 1977, 1980-83 and 1987-89.

So I thought I'd ask if there's other tapes that aren't in the archive...
google can't even find the tapes we have in our archive, let alone others...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200421/09607976/attachment.html>

From imp at bsdimp.com  Wed Apr 22 11:48:11 2020
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 21 Apr 2020 19:48:11 -0600
Subject: [TUHS] Usenix tapes
In-Reply-To: <alpine.NEB.2.21.2004212002080.4815@t1.m.reedmedia.net>
References: <CANCZdfq9HhCQKG+FnEv56T4CK6d8HhN0EryyCt5NBgH7r3pa3w@mail.gmail.com>
 <alpine.NEB.2.21.2004212002080.4815@t1.m.reedmedia.net>
Message-ID: <CANCZdfrXGNzbsAwpcu5ACYrG3UnDpeqNr0iAC+uRacxGU3=npA@mail.gmail.com>

On Tue, Apr 21, 2020, 7:37 PM Jeremy C. Reed <reed at reedmedia.net> wrote:

> On Tue, 21 Apr 2020, Warner Losh wrote:
>
> > So in the archives we have tapes from 1977, 1980-83 and 1987-89.
> > So I thought I'd ask if there's other tapes that aren't in the
> archive...?
> > google can't even find the tapes we have in our archive, let alone
> others...
>
> Hi Warner,
>
> I will list my tar files since may have different years than you list
> above.   I think all this is at the TUHs archives.
>
> 2710098  ug091377.tar.gz  Sep 1977:
> Aviation Research Laboratory, Harvard/Unix,  circle (Chicago?),
> Explor (Bell?), Queen Mary College, Nymegen Univ (nijmegen), UCSD,
> Brooklyn College of CUNY, cooper,  ...
>

This is in the archives. I just got done browsing it.

Did developers at Bell submit directly to share on these tapes? Or was
> it via third-party? (Lots of Bell code on there.)
>
> 1273420  uk1.tar.gz  Jan 1978:
> Queen Mary College, University of Kent at Canterbury, and University of
> Glasgow
>
> 2739630  tor79.tar.gz 1979
> University of New South Wales; U.S. Air FOrce Data Services Centre;
> Berkeley/VAX; Case Western Reserve; Department of Defence, Ft George. D.
> Mumaugh; Duke University; Graphic Management Systems; Johns Hopkins
> Univ.; Johns Hopkins Applied Physics Lab.; University of Minnesota;
> Engineering Computer Network, Univ of Oklahoma; Plastic Optics Inc.;
> Rochester Institue of Technology; Vrije University. Pascal.
>
> 1823101  purdue.tar.gz  1979
> School of Electrical Engineering, Purdue University
>

These might be. Maybe not.

10443465 del.tar.gz  1980 plus Boulder 1980 and Toronto June 1979 (but
> many differences)
>
> 8945578  usenix_80_delaware.tar.gz
>
> 1848640  usenix_81.tar.gz
>
> 829661   usenix83.tar.gz
>
> 28719717 usenix878889.tar.gz


These are.

Warner

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200421/515f417f/attachment.html>

From reed at reedmedia.net  Wed Apr 22 11:37:30 2020
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Tue, 21 Apr 2020 20:37:30 -0500 (CDT)
Subject: [TUHS] Usenix tapes
In-Reply-To: <CANCZdfq9HhCQKG+FnEv56T4CK6d8HhN0EryyCt5NBgH7r3pa3w@mail.gmail.com>
References: <CANCZdfq9HhCQKG+FnEv56T4CK6d8HhN0EryyCt5NBgH7r3pa3w@mail.gmail.com>
Message-ID: <alpine.NEB.2.21.2004212002080.4815@t1.m.reedmedia.net>

On Tue, 21 Apr 2020, Warner Losh wrote:

> So in the archives we have tapes from 1977, 1980-83 and 1987-89.
> So I thought I'd ask if there's other tapes that aren't in the archive...?
> google can't even find the tapes we have in our archive, let alone others...

Hi Warner,

I will list my tar files since may have different years than you list 
above.   I think all this is at the TUHs archives.

2710098  ug091377.tar.gz  Sep 1977:
Aviation Research Laboratory, Harvard/Unix,  circle (Chicago?),
Explor (Bell?), Queen Mary College, Nymegen Univ (nijmegen), UCSD, 
Brooklyn College of CUNY, cooper,  ...

Did developers at Bell submit directly to share on these tapes? Or was 
it via third-party? (Lots of Bell code on there.)

1273420  uk1.tar.gz  Jan 1978:
Queen Mary College, University of Kent at Canterbury, and University of 
Glasgow

2739630  tor79.tar.gz 1979
University of New South Wales; U.S. Air FOrce Data Services Centre; 
Berkeley/VAX; Case Western Reserve; Department of Defence, Ft George. D. 
Mumaugh; Duke University; Graphic Management Systems; Johns Hopkins 
Univ.; Johns Hopkins Applied Physics Lab.; University of Minnesota; 
Engineering Computer Network, Univ of Oklahoma; Plastic Optics Inc.; 
Rochester Institue of Technology; Vrije University. Pascal.

1823101  purdue.tar.gz  1979
School of Electrical Engineering, Purdue University

10443465 del.tar.gz  1980 plus Boulder 1980 and Toronto June 1979 (but 
many differences)

8945578  usenix_80_delaware.tar.gz 

1848640  usenix_81.tar.gz

829661   usenix83.tar.gz

28719717 usenix878889.tar.gz


From robpike at gmail.com  Wed Apr 22 19:21:09 2020
From: robpike at gmail.com (Rob Pike)
Date: Wed, 22 Apr 2020 19:21:09 +1000
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <202004201832.03KIWWeJ008975@freefriends.org>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
 <20200420181713.GB51234@clarinet.employees.org>
 <202004201832.03KIWWeJ008975@freefriends.org>
Message-ID: <CAKzdPgxVDVmCPiULT9osTFJQjMqSBWvP9HLZAw+_0DxBAfaddQ@mail.gmail.com>

I think dmr put them in, at my suggestion. I was bothered by the
inconsistent use of '-' as a name for standard input. Giving stdin a real
name meant we had a consistent mechanism.

8th edition sounds right.

-rob


On Tue, Apr 21, 2020 at 4:33 AM <arnold at skeeve.com> wrote:

> Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
>
> > On Mon, Apr 20, 2020 at 08:28:53AM -0600, arnold at skeeve.com wrote:
> > > See if there are man pages for /dev/fd/XXX.  IIRC /dev/stdin was
> > > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to
> /dev/fd/2,
> > > and, as a really nice generalization, /dev/tty to /dev/fd/4.  For the
> > > latter, init(1) simply dup'ed the opened tty file descriptor one more
> > > time before exec-ing login.
> >
> > So what happened to /dev/fd/3 ?
> >
> > DF
>
> My bad. I meant /dev/fd/3.  What was cute was that /dev/tty was
> no longer a special device of it's own, but just another inherited
> open file descriptor.
>
> Sadly, that generalization never made it out into other *nix systems.
>
> Arnold
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200422/3387557a/attachment.html>

From arnold at skeeve.com  Wed Apr 22 19:33:32 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 22 Apr 2020 03:33:32 -0600
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <CAKzdPgxVDVmCPiULT9osTFJQjMqSBWvP9HLZAw+_0DxBAfaddQ@mail.gmail.com>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
 <20200420181713.GB51234@clarinet.employees.org>
 <202004201832.03KIWWeJ008975@freefriends.org>
 <CAKzdPgxVDVmCPiULT9osTFJQjMqSBWvP9HLZAw+_0DxBAfaddQ@mail.gmail.com>
Message-ID: <202004220933.03M9XWk2002533@freefriends.org>

Other mail in the thread credits Tom Duff with /dev/fd ... In any case, 
/dev/stdin et al was a great idea.

Kudos.

Arnold

Rob Pike <robpike at gmail.com> wrote:

> I think dmr put them in, at my suggestion. I was bothered by the
> inconsistent use of '-' as a name for standard input. Giving stdin a real
> name meant we had a consistent mechanism.
>
> 8th edition sounds right.
>
> -rob
>
>
> On Tue, Apr 21, 2020 at 4:33 AM <arnold at skeeve.com> wrote:
>
> > Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
> >
> > > On Mon, Apr 20, 2020 at 08:28:53AM -0600, arnold at skeeve.com wrote:
> > > > See if there are man pages for /dev/fd/XXX.  IIRC /dev/stdin was
> > > > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to
> > /dev/fd/2,
> > > > and, as a really nice generalization, /dev/tty to /dev/fd/4.  For the
> > > > latter, init(1) simply dup'ed the opened tty file descriptor one more
> > > > time before exec-ing login.
> > >
> > > So what happened to /dev/fd/3 ?
> > >
> > > DF
> >
> > My bad. I meant /dev/fd/3.  What was cute was that /dev/tty was
> > no longer a special device of it's own, but just another inherited
> > open file descriptor.
> >
> > Sadly, that generalization never made it out into other *nix systems.
> >
> > Arnold
> >

From usotsuki at buric.co  Wed Apr 22 19:35:42 2020
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 22 Apr 2020 05:35:42 -0400 (EDT)
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <202004220933.03M9XWk2002533@freefriends.org>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
 <20200420181713.GB51234@clarinet.employees.org>
 <202004201832.03KIWWeJ008975@freefriends.org>
 <CAKzdPgxVDVmCPiULT9osTFJQjMqSBWvP9HLZAw+_0DxBAfaddQ@mail.gmail.com>
 <202004220933.03M9XWk2002533@freefriends.org>
Message-ID: <alpine.BSF.2.02.2004220534560.35252@frieza.hoshinet.org>

On Wed, 22 Apr 2020, arnold at skeeve.com wrote:

> Other mail in the thread credits Tom Duff with /dev/fd ... In any case,
> /dev/stdin et al was a great idea.

I make *heavy* use of /dev/stdin and /dev/stdout on Linux. Very useful 
concept.

-uso.

From robpike at gmail.com  Wed Apr 22 19:41:36 2020
From: robpike at gmail.com (Rob Pike)
Date: Wed, 22 Apr 2020 19:41:36 +1000
Subject: [TUHS] 8th Edition and /dev/stdio
In-Reply-To: <alpine.BSF.2.02.2004220534560.35252@frieza.hoshinet.org>
References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl>
 <202004201428.03KESrgI032002@freefriends.org>
 <20200420181713.GB51234@clarinet.employees.org>
 <202004201832.03KIWWeJ008975@freefriends.org>
 <CAKzdPgxVDVmCPiULT9osTFJQjMqSBWvP9HLZAw+_0DxBAfaddQ@mail.gmail.com>
 <202004220933.03M9XWk2002533@freefriends.org>
 <alpine.BSF.2.02.2004220534560.35252@frieza.hoshinet.org>
Message-ID: <CAKzdPgzCkdi=+WZa=AL+Uuke-9www9Bu57bYe7FWV717Q-QxCw@mail.gmail.com>

Not certain, but it's possible /dev/stdin went in first, and /dev/fd/*
generalized it.

-rob


On Wed, Apr 22, 2020 at 7:35 PM Steve Nickolas <usotsuki at buric.co> wrote:

> On Wed, 22 Apr 2020, arnold at skeeve.com wrote:
>
> > Other mail in the thread credits Tom Duff with /dev/fd ... In any case,
> > /dev/stdin et al was a great idea.
>
> I make *heavy* use of /dev/stdin and /dev/stdout on Linux. Very useful
> concept.
>
> -uso.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200422/3cf2a46f/attachment.html>

From imp at bsdimp.com  Thu Apr 23 07:53:45 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 22 Apr 2020 15:53:45 -0600
Subject: [TUHS] Off Topic: Unix Kermit 4x software archeology
Message-ID: <CANCZdfq2vFjoMhnrzwWoZq+ORRTEzBecbyMdWoO_cR_sJOMW4g@mail.gmail.com>

Greetings,

So this happened: https://bsdimp.blogspot.com/2020/04/finding-kermit-4x.html

tl;dr: while obsessing over 4C(052) kermit that's in Rainbow Venix, I found
a lot of cool "lost" source code versions of Kermit... All except the one I
was looking for.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200422/b5ba1228/attachment.html>

From pnr at planet.nl  Thu Apr 23 23:48:55 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 23 Apr 2020 15:48:55 +0200
Subject: [TUHS] V3 pipes
Message-ID: <57D2AE85-21DB-4D8F-8211-8ED7C1E60421@planet.nl>

Was looking into pipes.

For the 3rd Edition TUHS does not have source, but is does have a man page. In V3, pipe returns a single file descriptor that echoes whatever is written back upon reading. The pipe buffer capacity is 504 bytes.

The surviving ‘nsys’ source for V4 does not yet include the source for pipes, but the man page for 4th edition pipes has - more or less - the well known semantics, including the 4096 byte buffer capacity.

Does anyone remember:

- why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. Maybe the reason was that it becomes harder to detect broken pipes?

- whether the V3 implementation was based on an in-memory approach and not the later 'anonymous backing file’? The 504 byte buffer capacity suggests a single buffer page minus some header info.

From elbingmiss at gmail.com  Fri Apr 24 01:33:24 2020
From: elbingmiss at gmail.com (=?UTF-8?Q?=C3=81lvaro_Jurado?=)
Date: Thu, 23 Apr 2020 17:33:24 +0200
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAKzdPgygwxN2eAsjBBTdS_BgH__dk-AzDEH60oY7Fuv6=79b+g@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <C84B0821-70E7-45DF-9951-F60A7A6E1C9C@bus142.net>
 <CAKzdPgyuNHKZsGbieR+H6xgRQnAkr+_xHjTT_MB2gde17NB1Ww@mail.gmail.com>
 <202004200742.03K7g7b9018092@freefriends.org>
 <CAFNqd5X-PcWVD6N4h=u3uqaukSd1xVYSCTfrhqaD=sf=J4uMfQ@mail.gmail.com>
 <CAKzdPgygwxN2eAsjBBTdS_BgH__dk-AzDEH60oY7Fuv6=79b+g@mail.gmail.com>
Message-ID: <CAHJeKDX3H9oKmzQ2g2wNPv8EKYBH7FOx2MycDGAr=dHuvxG+1Q@mail.gmail.com>

:-D

/*
 *  WASHINGTON (AP) - The Food and Drug Administration warned
 * consumers Wednesday not to use ``Rio'' hair relaxer products
 * because they may cause severe hair loss or turn hair green....
 *    The FDA urged consumers who have experienced problems with Rio
 * to notify their local FDA office, local health department or the
 * company at 1‑800‑543‑3002.
 */

sys/src/cmd/rio/rio.c

https://en.m.wikipedia.org/wiki/Rio_Hair_Naturalizer_System


On Mon, 20 Apr 2020 at 22:50, Rob Pike <robpike at gmail.com> wrote:

> No, that's not it. You have the wrong actor. The right one appears in the
> rio source.
>
> -rob
>
>
> On Tue, Apr 21, 2020 at 3:37 AM Christopher Browne <cbbrowne at gmail.com>
> wrote:
>
>>
>>
>> On Mon, 20 Apr 2020 at 03:43, <arnold at skeeve.com> wrote:
>>
>>> Rob Pike <robpike at gmail.com> wrote:
>>>
>>> > Rio is a reference to a different movie, not to Brazil. Brazil is a
>>> > reference to Brazil. Hope that helps.
>>> >
>>> > -rob
>>>
>>> What movie is Rio a reference to?
>>>
>>
>> I imagine there's some bad romantic comedy movie starring Michael Caine
>> to Blame It On...
>>
>> Timing seems about right.
>> --
>> When confronted by a difficult problem, solve it by reducing it to the
>> question, "How would the Lone Ranger handle this?"
>>
> --
Álvaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200423/623861ea/attachment.html>

From rich.salz at gmail.com  Fri Apr 24 03:10:57 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Thu, 23 Apr 2020 13:10:57 -0400
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAHJeKDX3H9oKmzQ2g2wNPv8EKYBH7FOx2MycDGAr=dHuvxG+1Q@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <C84B0821-70E7-45DF-9951-F60A7A6E1C9C@bus142.net>
 <CAKzdPgyuNHKZsGbieR+H6xgRQnAkr+_xHjTT_MB2gde17NB1Ww@mail.gmail.com>
 <202004200742.03K7g7b9018092@freefriends.org>
 <CAFNqd5X-PcWVD6N4h=u3uqaukSd1xVYSCTfrhqaD=sf=J4uMfQ@mail.gmail.com>
 <CAKzdPgygwxN2eAsjBBTdS_BgH__dk-AzDEH60oY7Fuv6=79b+g@mail.gmail.com>
 <CAHJeKDX3H9oKmzQ2g2wNPv8EKYBH7FOx2MycDGAr=dHuvxG+1Q@mail.gmail.com>
Message-ID: <CAFH29tqX5H2r0ec=ibvATSWp5iq0rUX9Gbg6JJoP2UUjtHgu7w@mail.gmail.com>

Rio the movie: https://en.wikipedia.org/wiki/Rio_(2011_film)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200423/9a26d8c8/attachment.html>

From doug at cs.dartmouth.edu  Fri Apr 24 22:54:39 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 24 Apr 2020 08:54:39 -0400
Subject: [TUHS] v3 pipes
Message-ID: <202004241254.03OCsd9m066621@tahoe.cs.Dartmouth.EDU>

>  why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication.

My understanding is that the single file descriptor broke the open-file
model, which had a single read/write pointer. Two-way communication via


Doug

From dave at horsfall.org  Sat Apr 25 06:55:24 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 25 Apr 2020 06:55:24 +1000 (EST)
Subject: [TUHS] Plan 9 from outer space ?
In-Reply-To: <CAFCBnZv7NFmiFDVr1MbK9ZZSCXv-UU56aABiEfUGsW+kRqfo=w@mail.gmail.com>
References: <20200419143534.D96C94422F@lignose.oclsc.org>
 <CAFCBnZv7NFmiFDVr1MbK9ZZSCXv-UU56aABiEfUGsW+kRqfo=w@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2004250653540.40007@aneurin.horsfall.org>

[ Catching up on old email ]

On Sun, 19 Apr 2020, A. P. Garcia wrote:

> Mark V Chaney!

Shaney.  I know the culprit(s) behind it...

-- Dave

From athornton at gmail.com  Sat Apr 25 11:59:00 2020
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 24 Apr 2020 18:59:00 -0700
Subject: [TUHS] v7 K&R C
Message-ID: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>

The C in v7 is, canonically, the language described in K&R, right?

I must be doing something dumb.

I am getting Webb Miller’s “s” editor built there, and I am down to one function.

/* chop_arg - chop a function's argument to a maximum length */
static chop_arg(fcn, arg, maxlen)
int (*fcn)();
int maxlen;
char *arg;
{
    char save;

    save = arg[maxlen];
    arg[maxlen] = '\0';
    fcn(arg);
    arg[maxlen] = save;
}

This doesn’t like the function pointer.

$ cc -c choparg.c
choparg.c:11: Call of non-function

So, uh, what is the obvious thing I am missing?  How am I supposed to be passing function pointers in the C compiler that comes with v7?

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200424/44e48be9/attachment.html>

From charles.unix.pro at gmail.com  Sat Apr 25 12:37:57 2020
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Fri, 24 Apr 2020 19:37:57 -0700
Subject: [TUHS] v7 K&R C
In-Reply-To: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
Message-ID: <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>

On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton at gmail.com> wrote:

> This doesn’t like the function pointer.
>

> $ cc -c choparg.c
> choparg.c:11: Call of non-function
>
> Perhaps:

    (*fcn)(arg);

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200424/3166dc7b/attachment.html>

From athornton at gmail.com  Sat Apr 25 12:47:50 2020
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 24 Apr 2020 19:47:50 -0700
Subject: [TUHS] v7 K&R C
In-Reply-To: <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
Message-ID: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>



> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro at gmail.com> wrote:
> 
> 
> 
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton at gmail.com <mailto:athornton at gmail.com>> wrote:
> This doesn’t like the function pointer.
> 
> $ cc -c choparg.c
> choparg.c:11: Call of non-function
> 
> Perhaps:
> 
>     (*fcn)(arg);
> 

We have a winner!

Also, Kartik, dunno where it is on the net, but if you install a v7 system, /usr/src/cmd/c

Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200424/edf6f78e/attachment.html>

From athornton at gmail.com  Sat Apr 25 12:50:24 2020
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 24 Apr 2020 19:50:24 -0700
Subject: [TUHS] v7 K&R C
In-Reply-To: <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
Message-ID: <8329FD62-3822-4572-B66E-137FE4F7CFD9@gmail.com>

Getting closer!

$ cc -c s *.o
$ ./s Makefile
./s: cannot execute
$ ls -l s
-rw-rw-r-- 1 dmr     61644 Apr 23 11:06 s
$ chmod +x s
$ ./s
usage: s file
$ ./s Makefile
Memory fault - core dumped
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200424/c0369a8a/attachment.html>

From robpike at gmail.com  Sat Apr 25 12:51:31 2020
From: robpike at gmail.com (Rob Pike)
Date: Sat, 25 Apr 2020 12:51:31 +1000
Subject: [TUHS] v7 K&R C
In-Reply-To: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
Message-ID: <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>

The ability to call a function pointer fp with the syntax fp() rather than
(*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
sure it was not in v7 C, as you observe.

Convenient though the shorthand may be, it always bothered me as
inconsistent and misleading. (I am pretty sure I used it sometimes
regardless.)

-rob


On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton at gmail.com> wrote:

>
>
> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro at gmail.com>
> wrote:
>
>
>
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton at gmail.com> wrote:
>
>> This doesn’t like the function pointer.
>>
>
>> $ cc -c choparg.c
>> choparg.c:11: Call of non-function
>>
>> Perhaps:
>
>     (*fcn)(arg);
>
>
> We have a winner!
>
> Also, Kartik, dunno where it is on the net, but if you install a v7
> system, /usr/src/cmd/c
>
> Adam
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/e39f48b2/attachment.html>

From robpike at gmail.com  Sat Apr 25 12:54:27 2020
From: robpike at gmail.com (Rob Pike)
Date: Sat, 25 Apr 2020 12:54:27 +1000
Subject: [TUHS] v7 K&R C
In-Reply-To: <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
Message-ID: <CAKzdPgz6wYnKkv1UCLanhWbWv+bVx6Hoy39P3VhP06HMhdL+iA@mail.gmail.com>

Another debate at the time was caused by a disagreement between pcc and cc
regarding enums: are they a type or just a way to declare constant? I
remember getting annoyed by pcc not letting me declare a constant with an
enum and use it as an int. I protested to scj and dmr and after some to-ing
and fro-ing Steve changed pcc to treat them as constants.

Not sure it was the right decision, but C desperately wanted a non-macro
way to define a constant. I'd probably argue the same way today. The real
lesson is how propinquity affects progress.

-rbo


On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike at gmail.com> wrote:

> The ability to call a function pointer fp with the syntax fp() rather than
> (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> sure it was not in v7 C, as you observe.
>
> Convenient though the shorthand may be, it always bothered me as
> inconsistent and misleading. (I am pretty sure I used it sometimes
> regardless.)
>
> -rob
>
>
> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton at gmail.com>
> wrote:
>
>>
>>
>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro at gmail.com>
>> wrote:
>>
>>
>>
>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton at gmail.com>
>> wrote:
>>
>>> This doesn’t like the function pointer.
>>>
>>
>>> $ cc -c choparg.c
>>> choparg.c:11: Call of non-function
>>>
>>> Perhaps:
>>
>>     (*fcn)(arg);
>>
>>
>> We have a winner!
>>
>> Also, Kartik, dunno where it is on the net, but if you install a v7
>> system, /usr/src/cmd/c
>>
>> Adam
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/e8a5c821/attachment.html>

From lm at mcvoy.com  Sat Apr 25 13:04:36 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 24 Apr 2020 20:04:36 -0700
Subject: [TUHS] v7 K&R C
In-Reply-To: <CAKzdPgz6wYnKkv1UCLanhWbWv+bVx6Hoy39P3VhP06HMhdL+iA@mail.gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
 <CAKzdPgz6wYnKkv1UCLanhWbWv+bVx6Hoy39P3VhP06HMhdL+iA@mail.gmail.com>
Message-ID: <20200425030436.GF30547@mcvoy.com>

I hate enums.  I thought they would be type checked and they are just ints.
I love C but enums suck.

On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote:
> Another debate at the time was caused by a disagreement between pcc and cc
> regarding enums: are they a type or just a way to declare constant? I
> remember getting annoyed by pcc not letting me declare a constant with an
> enum and use it as an int. I protested to scj and dmr and after some to-ing
> and fro-ing Steve changed pcc to treat them as constants.
> 
> Not sure it was the right decision, but C desperately wanted a non-macro
> way to define a constant. I'd probably argue the same way today. The real
> lesson is how propinquity affects progress.
> 
> -rbo
> 
> 
> On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike at gmail.com> wrote:
> 
> > The ability to call a function pointer fp with the syntax fp() rather than
> > (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> > sure it was not in v7 C, as you observe.
> >
> > Convenient though the shorthand may be, it always bothered me as
> > inconsistent and misleading. (I am pretty sure I used it sometimes
> > regardless.)
> >
> > -rob
> >
> >
> > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton at gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro at gmail.com>
> >> wrote:
> >>
> >>
> >>
> >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton at gmail.com>
> >> wrote:
> >>
> >>> This doesn???t like the function pointer.
> >>>
> >>
> >>> $ cc -c choparg.c
> >>> choparg.c:11: Call of non-function
> >>>
> >>> Perhaps:
> >>
> >>     (*fcn)(arg);
> >>
> >>
> >> We have a winner!
> >>
> >> Also, Kartik, dunno where it is on the net, but if you install a v7
> >> system, /usr/src/cmd/c
> >>
> >> Adam
> >>
> >>

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From clemc at ccc.com  Sat Apr 25 13:30:26 2020
From: clemc at ccc.com (Clem Cole)
Date: Fri, 24 Apr 2020 23:30:26 -0400
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425030436.GF30547@mcvoy.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
 <CAKzdPgz6wYnKkv1UCLanhWbWv+bVx6Hoy39P3VhP06HMhdL+iA@mail.gmail.com>
 <20200425030436.GF30547@mcvoy.com>
Message-ID: <CAC20D2Nj204+EsOye_R-sVX-m6VT4QYNFR46fEqgBZJLSqVdPw@mail.gmail.com>

Amen bro.  I always felt that they got added because pascal had something
that C didn’t, and yet it really was not the same.  I always felt they were
a feature that was only partly implemented and if they were not going  to
be fully typed then just leave them out and use cpp like we had always done
before.

On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm at mcvoy.com> wrote:

> I hate enums.  I thought they would be type checked and they are just ints.
> I love C but enums suck.
>
> On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote:
> > Another debate at the time was caused by a disagreement between pcc and
> cc
> > regarding enums: are they a type or just a way to declare constant? I
> > remember getting annoyed by pcc not letting me declare a constant with an
> > enum and use it as an int. I protested to scj and dmr and after some
> to-ing
> > and fro-ing Steve changed pcc to treat them as constants.
> >
> > Not sure it was the right decision, but C desperately wanted a non-macro
> > way to define a constant. I'd probably argue the same way today. The real
> > lesson is how propinquity affects progress.
> >
> > -rbo
> >
> >
> > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike at gmail.com> wrote:
> >
> > > The ability to call a function pointer fp with the syntax fp() rather
> than
> > > (*fp)() came rather late, I think at Bjarne's suggestion or example.
> Pretty
> > > sure it was not in v7 C, as you observe.
> > >
> > > Convenient though the shorthand may be, it always bothered me as
> > > inconsistent and misleading. (I am pretty sure I used it sometimes
> > > regardless.)
> > >
> > > -rob
> > >
> > >
> > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton at gmail.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
> charles.unix.pro at gmail.com>
> > >> wrote:
> > >>
> > >>
> > >>
> > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton at gmail.com>
> > >> wrote:
> > >>
> > >>> This doesn???t like the function pointer.
> > >>>
> > >>
> > >>> $ cc -c choparg.c
> > >>> choparg.c:11: Call of non-function
> > >>>
> > >>> Perhaps:
> > >>
> > >>     (*fcn)(arg);
> > >>
> > >>
> > >> We have a winner!
> > >>
> > >> Also, Kartik, dunno where it is on the net, but if you install a v7
> > >> system, /usr/src/cmd/c
> > >>
> > >> Adam
> > >>
> > >>
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200424/e36d7939/attachment.html>

From dave at horsfall.org  Sat Apr 25 13:37:24 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 25 Apr 2020 13:37:24 +1000 (EST)
Subject: [TUHS] v7 K&R C
In-Reply-To: <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2004251324290.40007@aneurin.horsfall.org>

On Sat, 25 Apr 2020, Rob Pike wrote:

> The ability to call a function pointer fp with the syntax fp() rather 
> than (*fp)() came rather late, I think at Bjarne's suggestion or 
> example. Pretty sure it was not in v7 C, as you observe.

I have never seen that syntax used (and I've been tooling around with Unix 
for decades).  The variable "fp" in an argument list is a pointer to the 
function, not the function itself, so dereference it.

I wouldn't put it past Stroustrup to have it in C++ though, as it pretty 
much has everything else in it.

> Convenient though the shorthand may be, it always bothered me as 
> inconsistent and misleading. (I am pretty sure I used it sometimes 
> regardless.)

Indeed...  My principle is to write code as though the next person to 
maintain it is a psychopathic axe-murderer who knows where you live (or 
perhaps even yourself, a year later)...

-- Dave

From lm at mcvoy.com  Sat Apr 25 13:43:07 2020
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 24 Apr 2020 20:43:07 -0700
Subject: [TUHS] v7 K&R C
In-Reply-To: <CAC20D2Nj204+EsOye_R-sVX-m6VT4QYNFR46fEqgBZJLSqVdPw@mail.gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
 <CAKzdPgz6wYnKkv1UCLanhWbWv+bVx6Hoy39P3VhP06HMhdL+iA@mail.gmail.com>
 <20200425030436.GF30547@mcvoy.com>
 <CAC20D2Nj204+EsOye_R-sVX-m6VT4QYNFR46fEqgBZJLSqVdPw@mail.gmail.com>
Message-ID: <20200425034307.GG30547@mcvoy.com>

What Clem said, that is precisely how I feel.  I'd be fully for them if they
fully type checked but without that, yeah, cpp is fine, enums are just a
distraction.


On Fri, Apr 24, 2020 at 11:30:26PM -0400, Clem Cole wrote:
> Amen bro.  I always felt that they got added because pascal had something
> that C didn???t, and yet it really was not the same.  I always felt they were
> a feature that was only partly implemented and if they were not going  to
> be fully typed then just leave them out and use cpp like we had always done
> before.
> 
> On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I hate enums.  I thought they would be type checked and they are just ints.
> > I love C but enums suck.
> >
> > On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote:
> > > Another debate at the time was caused by a disagreement between pcc and
> > cc
> > > regarding enums: are they a type or just a way to declare constant? I
> > > remember getting annoyed by pcc not letting me declare a constant with an
> > > enum and use it as an int. I protested to scj and dmr and after some
> > to-ing
> > > and fro-ing Steve changed pcc to treat them as constants.
> > >
> > > Not sure it was the right decision, but C desperately wanted a non-macro
> > > way to define a constant. I'd probably argue the same way today. The real
> > > lesson is how propinquity affects progress.
> > >
> > > -rbo
> > >
> > >
> > > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike at gmail.com> wrote:
> > >
> > > > The ability to call a function pointer fp with the syntax fp() rather
> > than
> > > > (*fp)() came rather late, I think at Bjarne's suggestion or example.
> > Pretty
> > > > sure it was not in v7 C, as you observe.
> > > >
> > > > Convenient though the shorthand may be, it always bothered me as
> > > > inconsistent and misleading. (I am pretty sure I used it sometimes
> > > > regardless.)
> > > >
> > > > -rob
> > > >
> > > >
> > > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton at gmail.com>
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
> > charles.unix.pro at gmail.com>
> > > >> wrote:
> > > >>
> > > >>
> > > >>
> > > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton at gmail.com>
> > > >> wrote:
> > > >>
> > > >>> This doesn???t like the function pointer.
> > > >>>
> > > >>
> > > >>> $ cc -c choparg.c
> > > >>> choparg.c:11: Call of non-function
> > > >>>
> > > >>> Perhaps:
> > > >>
> > > >>     (*fcn)(arg);
> > > >>
> > > >>
> > > >> We have a winner!
> > > >>
> > > >> Also, Kartik, dunno where it is on the net, but if you install a v7
> > > >> system, /usr/src/cmd/c
> > > >>
> > > >> Adam
> > > >>
> > > >>
> >
> > --
> > ---
> > Larry McVoy                  lm at mcvoy.com
> > http://www.mcvoy.com/lm
> >
> -- 
> Sent from a handheld expect more typos than usual

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From jon at fourwinds.com  Sat Apr 25 13:54:14 2020
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 24 Apr 2020 20:54:14 -0700
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425034307.GG30547@mcvoy.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
 <CAKzdPgz6wYnKkv1UCLanhWbWv+bVx6Hoy39P3VhP06HMhdL+iA@mail.gmail.com>
 <20200425030436.GF30547@mcvoy.com>
 <CAC20D2Nj204+EsOye_R-sVX-m6VT4QYNFR46fEqgBZJLSqVdPw@mail.gmail.com>
 <20200425034307.GG30547@mcvoy.com>
Message-ID: <202004250354.03P3sFJe2522940@darkstar.fourwinds.com>

Larry McVoy writes:
> What Clem said, that is precisely how I feel.  I'd be fully for them if they
> fully type checked but without that, yeah, cpp is fine, enums are just a
> distraction.

Enums are implemented badly, but it's possible to do even worse.  This is from
linux /usr/include/sys/mount.h - can anyone explain the point of it to me?

enum
{
  MS_RDONLY = 1,		/* Mount read-only.  */
#define MS_RDONLY	MS_RDONLY
  MS_NOSUID = 2,		/* Ignore suid and sgid bits.  */
#define MS_NOSUID	MS_NOSUID
  MS_NODEV = 4,			/* Disallow access to device special files.  */
#define MS_NODEV	MS_NODEV
  MS_NOEXEC = 8,		/* Disallow program execution.  */
#define MS_NOEXEC	MS_NOEXEC
  MS_SYNCHRONOUS = 16,		/* Writes are synced at once.  */
#define MS_SYNCHRONOUS	MS_SYNCHRONOUS
  MS_REMOUNT = 32,		/* Alter flags of a mounted FS.  */
#define MS_REMOUNT	MS_REMOUNT
  MS_MANDLOCK = 64,		/* Allow mandatory locks on an FS.  */
#define MS_MANDLOCK	MS_MANDLOCK
  MS_DIRSYNC = 128,		/* Directory modifications are synchronous.  */
#define MS_DIRSYNC	MS_DIRSYNC
  MS_NOATIME = 1024,		/* Do not update access times.  */
#define MS_NOATIME	MS_NOATIME
  MS_NODIRATIME = 2048,		/* Do not update directory access times.  */
#define MS_NODIRATIME	MS_NODIRATIME
  MS_BIND = 4096,		/* Bind directory at different place.  */
#define MS_BIND		MS_BIND
  MS_MOVE = 8192,
#define MS_MOVE		MS_MOVE
  MS_REC = 16384,
#define MS_REC		MS_REC
  MS_SILENT = 32768,
#define MS_SILENT	MS_SILENT
  MS_POSIXACL = 1 << 16,	/* VFS does not apply the umask.  */
#define MS_POSIXACL	MS_POSIXACL
  MS_UNBINDABLE = 1 << 17,	/* Change to unbindable.  */
#define MS_UNBINDABLE	MS_UNBINDABLE
  MS_PRIVATE = 1 << 18,		/* Change to private.  */
#define MS_PRIVATE	MS_PRIVATE
  MS_SLAVE = 1 << 19,		/* Change to slave.  */
#define MS_SLAVE	MS_SLAVE
  MS_SHARED = 1 << 20,		/* Change to shared.  */
#define MS_SHARED	MS_SHARED
  MS_RELATIME = 1 << 21,	/* Update atime relative to mtime/ctime.  */
#define MS_RELATIME	MS_RELATIME
  MS_KERNMOUNT = 1 << 22,	/* This is a kern_mount call.  */
#define MS_KERNMOUNT	MS_KERNMOUNT
  MS_I_VERSION =  1 << 23,	/* Update inode I_version field.  */
#define MS_I_VERSION	MS_I_VERSION
  MS_STRICTATIME = 1 << 24,	/* Always perform atime updates.  */
#define MS_STRICTATIME	MS_STRICTATIME
  MS_LAZYTIME = 1 << 25,	/* Update the on-disk [acm]times lazily.  */
#define MS_LAZYTIME	MS_LAZYTIME
  MS_ACTIVE = 1 << 30,
#define MS_ACTIVE	MS_ACTIVE
  MS_NOUSER = 1 << 31
#define MS_NOUSER	MS_NOUSER
};

From lars at nocrew.org  Sat Apr 25 15:59:19 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sat, 25 Apr 2020 05:59:19 +0000
Subject: [TUHS] v7 K&R C
In-Reply-To: <8329FD62-3822-4572-B66E-137FE4F7CFD9@gmail.com> (Adam Thornton's
 message of "Fri, 24 Apr 2020 19:50:24 -0700")
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <8329FD62-3822-4572-B66E-137FE4F7CFD9@gmail.com>
Message-ID: <7wtv18p0lk.fsf@junk.nocrew.org>

Adam Thornton wrote:
> Getting closer!
>
> $ cc -c s *.o
> $ ./s Makefile
> ./s: cannot execute

-c says to make an object file, right?  Try -o instead.

From pnr at planet.nl  Sat Apr 25 21:14:15 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 25 Apr 2020 13:14:15 +0200
Subject: [TUHS] v3 pipes
Message-ID: <430B2F35-D250-499E-83F9-58D4C1764CE0@planet.nl>

>> why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication.
> My understanding is that the single file descriptor broke the open-file
> model, which had a single read/write pointer. Two-way communication via

I’m not sure I understand.

In the implementation, the read pointer is file location offset (“fp->f_offset”) and the write pointer is the file size (“ip->i_size”). The location offset on the writing end of the pipe is always zero, and on the reading end it moves between zero and PIPSIZ (but that is unobservable).

I just tried making both pipe ends readable+writeable in my “V6.5” kernel and that appears to work. It allows for bi-directional communication in a half-duplex sense (i.e communicating walky-talky style). The other benefit is using just one file descriptor, at a time when a process had just 15 to work with.

Maybe the issue was that two sides writing to a full pipe at the same time will cause deadlock?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/0953f3dd/attachment.html>

From michael at kjorling.se  Sat Apr 25 21:44:23 2020
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 25 Apr 2020 11:44:23 +0000
Subject: [TUHS] v7 K&R C
In-Reply-To: <202004250354.03P3sFJe2522940@darkstar.fourwinds.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
 <CAKzdPgz6wYnKkv1UCLanhWbWv+bVx6Hoy39P3VhP06HMhdL+iA@mail.gmail.com>
 <20200425030436.GF30547@mcvoy.com>
 <CAC20D2Nj204+EsOye_R-sVX-m6VT4QYNFR46fEqgBZJLSqVdPw@mail.gmail.com>
 <20200425034307.GG30547@mcvoy.com>
 <202004250354.03P3sFJe2522940@darkstar.fourwinds.com>
Message-ID: <cdd66586-339f-464e-851e-0ce5ded3c69f@localhost>

On 24 Apr 2020 20:54 -0700, from jon at fourwinds.com (Jon Steinhart):
> Enums are implemented badly, but it's possible to do even worse.  This is from
> linux /usr/include/sys/mount.h - can anyone explain the point of it to me?
> 
> enum
> {
>   MS_RDONLY = 1,		/* Mount read-only.  */
> #define MS_RDONLY	MS_RDONLY
>   MS_NOSUID = 2,		/* Ignore suid and sgid bits.  */
> #define MS_NOSUID	MS_NOSUID

If you mean the #defining to itself, check out the discussion starting
at <https://minnie.tuhs.org/pipermail/tuhs/2019-November/019429.html>.

If you have the archive locally, that's Message-ID
<201911131802.xADI2fxE752068 at darkstar.fourwinds.com> from 13 Nov 2019
10:02 -0800 / 18:02 UTC.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


From jnc at mercury.lcs.mit.edu  Sat Apr 25 23:11:12 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 25 Apr 2020 09:11:12 -0400 (EDT)
Subject: [TUHS] v7 K&R C
Message-ID: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>

    > From: Rob Pike

    > Convenient though the shorthand may be, it always bothered me as
    > inconsistent and misleading.

As someone who made very extensive use of procedure pointers (most notably in
upcalls, which never caught on, alas), I couldn't agree more.

Two very different things are happenging, but with the shorthand notation,
they share an identical representation. And for what? To save three characters?

     Noel


From robpike at gmail.com  Sat Apr 25 23:18:02 2020
From: robpike at gmail.com (Rob Pike)
Date: Sat, 25 Apr 2020 23:18:02 +1000
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
Message-ID: <CAKzdPgz9=PBaHndt+PDQSL783KVqi6GBX7GA8Fb5UA15gmSfbg@mail.gmail.com>

To make chaining of calls simpler. Write

f()->g()->h()->i()

the other way and you'll see why Bjarne asked for the shorthand.

-rob


On Sat, Apr 25, 2020 at 11:12 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Rob Pike
>
>     > Convenient though the shorthand may be, it always bothered me as
>     > inconsistent and misleading.
>
> As someone who made very extensive use of procedure pointers (most notably
> in
> upcalls, which never caught on, alas), I couldn't agree more.
>
> Two very different things are happenging, but with the shorthand notation,
> they share an identical representation. And for what? To save three
> characters?
>
>      Noel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/7455cc93/attachment.html>

From crossd at gmail.com  Sat Apr 25 23:17:55 2020
From: crossd at gmail.com (Dan Cross)
Date: Sat, 25 Apr 2020 09:17:55 -0400
Subject: [TUHS] v7 K&R C
In-Reply-To: <CAC20D2Nj204+EsOye_R-sVX-m6VT4QYNFR46fEqgBZJLSqVdPw@mail.gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
 <CAKzdPgz6wYnKkv1UCLanhWbWv+bVx6Hoy39P3VhP06HMhdL+iA@mail.gmail.com>
 <20200425030436.GF30547@mcvoy.com>
 <CAC20D2Nj204+EsOye_R-sVX-m6VT4QYNFR46fEqgBZJLSqVdPw@mail.gmail.com>
Message-ID: <CAEoi9W5s7no_t=LJ5Crc+4juEMzNir=-RLEGFjZkELbt=tkhWA@mail.gmail.com>

On Fri, Apr 24, 2020 at 11:31 PM Clem Cole <clemc at ccc.com> wrote:

> Amen bro.  I always felt that they got added because pascal had something
> that C didn’t, and yet it really was not the same.  I always felt they were
> a feature that was only partly implemented and if they were not going  to
> be fully typed then just leave them out and use cpp like we had always done
> before.
>

Aww shucks; I actually kinda like enums. When creating sequentially
numbered constants, they're convenient.

That said, the typing issues I have a lot of sympathy for. For true
constants, it's a shame that `const` didn't make it in earlier, though we
have it now. Abusing enum to define constants certainly feels like, well,
abuse.

        - Dan C.


On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm at mcvoy.com> wrote:
>
>> I hate enums.  I thought they would be type checked and they are just
>> ints.
>> I love C but enums suck.
>>
>> On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote:
>> > Another debate at the time was caused by a disagreement between pcc and
>> cc
>> > regarding enums: are they a type or just a way to declare constant? I
>> > remember getting annoyed by pcc not letting me declare a constant with
>> an
>> > enum and use it as an int. I protested to scj and dmr and after some
>> to-ing
>> > and fro-ing Steve changed pcc to treat them as constants.
>> >
>> > Not sure it was the right decision, but C desperately wanted a non-macro
>> > way to define a constant. I'd probably argue the same way today. The
>> real
>> > lesson is how propinquity affects progress.
>> >
>> > -rbo
>> >
>> >
>> > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike at gmail.com> wrote:
>> >
>> > > The ability to call a function pointer fp with the syntax fp() rather
>> than
>> > > (*fp)() came rather late, I think at Bjarne's suggestion or example.
>> Pretty
>> > > sure it was not in v7 C, as you observe.
>> > >
>> > > Convenient though the shorthand may be, it always bothered me as
>> > > inconsistent and misleading. (I am pretty sure I used it sometimes
>> > > regardless.)
>> > >
>> > > -rob
>> > >
>> > >
>> > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton at gmail.com>
>> > > wrote:
>> > >
>> > >>
>> > >>
>> > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
>> charles.unix.pro at gmail.com>
>> > >> wrote:
>> > >>
>> > >>
>> > >>
>> > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton at gmail.com>
>> > >> wrote:
>> > >>
>> > >>> This doesn???t like the function pointer.
>> > >>>
>> > >>
>> > >>> $ cc -c choparg.c
>> > >>> choparg.c:11: Call of non-function
>> > >>>
>> > >>> Perhaps:
>> > >>
>> > >>     (*fcn)(arg);
>> > >>
>> > >>
>> > >> We have a winner!
>> > >>
>> > >> Also, Kartik, dunno where it is on the net, but if you install a v7
>> > >> system, /usr/src/cmd/c
>> > >>
>> > >> Adam
>> > >>
>> > >>
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
> --
> Sent from a handheld expect more typos than usual
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/f775f54d/attachment.html>

From hellwig.geisse at mni.thm.de  Sat Apr 25 23:35:12 2020
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Sat, 25 Apr 2020 15:35:12 +0200
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
Message-ID: <1587821712.2206.338.camel@mni.thm.de>

On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote:
>     > From: Rob Pike
> 
>     > Convenient though the shorthand may be, it always bothered me as
>     > inconsistent and misleading.
> 
> As someone who made very extensive use of procedure pointers (most notably in
> upcalls, which never caught on, alas), I couldn't agree more.
> 
> Two very different things are happenging, but with the shorthand notation,
> they share an identical representation. And for what? To save three characters?

The subject can be looked at from another angle. Consider
the call f(42). This might be read as first naming f (and
thus constructing a pointer to f) and then calling the
function which the pointer is pointing to. So at least
it should be possible to write the call as (*f)(42), which
indeed is equivalent to f(42). So it can be argued that
this notational shorthand should be allowed with all
function pointers.

Hellwig

From rich.salz at gmail.com  Sat Apr 25 23:59:59 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Sat, 25 Apr 2020 09:59:59 -0400
Subject: [TUHS] v7 K&R C
In-Reply-To: <1587821712.2206.338.camel@mni.thm.de>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
 <1587821712.2206.338.camel@mni.thm.de>
Message-ID: <CAFH29topDhajtzs9UkH1sUWpH+Cq7=84YJf7X2ESb4W2HfGrSA@mail.gmail.com>

The compilers have caught up, -Wswitch-enum is worthwhile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/b95403e0/attachment-0001.html>

From imp at bsdimp.com  Sun Apr 26 00:57:50 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 25 Apr 2020 08:57:50 -0600
Subject: [TUHS] v7 K&R C
In-Reply-To: <CAKzdPgz9=PBaHndt+PDQSL783KVqi6GBX7GA8Fb5UA15gmSfbg@mail.gmail.com>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
 <CAKzdPgz9=PBaHndt+PDQSL783KVqi6GBX7GA8Fb5UA15gmSfbg@mail.gmail.com>
Message-ID: <CANCZdfq=6hG3Xo9KRCp1QQwDSS8+wvk-PW77mOCUfQBcgZ1NZA@mail.gmail.com>

On Sat, Apr 25, 2020, 7:18 AM Rob Pike <robpike at gmail.com> wrote:

> To make chaining of calls simpler. Write
>
> f()->g()->h()->i()
>
> the other way and you'll see why Bjarne asked for the shorthand.
>

Yea. The other way looks way too lispy...

Warner

-rob
>
>
> On Sat, Apr 25, 2020 at 11:12 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
>
>>     > From: Rob Pike
>>
>>     > Convenient though the shorthand may be, it always bothered me as
>>     > inconsistent and misleading.
>>
>> As someone who made very extensive use of procedure pointers (most
>> notably in
>> upcalls, which never caught on, alas), I couldn't agree more.
>>
>> Two very different things are happenging, but with the shorthand notation,
>> they share an identical representation. And for what? To save three
>> characters?
>>
>>      Noel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/136e3521/attachment.html>

From ron at ronnatalie.com  Sun Apr 26 02:13:03 2020
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Sat, 25 Apr 2020 12:13:03 -0400
Subject: [TUHS] C and C++ Regrets
In-Reply-To: <CANCZdfq=6hG3Xo9KRCp1QQwDSS8+wvk-PW77mOCUfQBcgZ1NZA@mail.gmail.com>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
 <CAKzdPgz9=PBaHndt+PDQSL783KVqi6GBX7GA8Fb5UA15gmSfbg@mail.gmail.com>
 <CANCZdfq=6hG3Xo9KRCp1QQwDSS8+wvk-PW77mOCUfQBcgZ1NZA@mail.gmail.com>
Message-ID: <869178f23343aa4169c4c907bdade7bf.squirrel@squirrelmail.tuffmail.net>

The two things I'd wish had happened in C or C++

1.   That when they fixed structs/unions to have proper assignment and
function argument and return behavior (i.e., making them full-fledged
types), that they would have done the same for arrays.   This inane "treat
it like a pointer" has always been problematic.

2.   That the default behavior in C++ is to *ALWAYS* initialize an object,
even if it is POD, no matter how it is allocated.




From paul.winalski at gmail.com  Sun Apr 26 03:54:42 2020
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sat, 25 Apr 2020 13:54:42 -0400
Subject: [TUHS] v3 pipes
In-Reply-To: <430B2F35-D250-499E-83F9-58D4C1764CE0@planet.nl>
References: <430B2F35-D250-499E-83F9-58D4C1764CE0@planet.nl>
Message-ID: <CABH=_VRf5whh3QoM3x+h-cZSy1Dj6n-KWtLHGuZ7aJwJ2Y=A_w@mail.gmail.com>

On 4/25/20, Paul Ruizendaal <pnr at planet.nl> wrote:
>
> I just tried making both pipe ends readable+writeable in my “V6.5” kernel
> and that appears to work. It allows for bi-directional communication in a
> half-duplex sense (i.e communicating walky-talky style). The other benefit
> is using just one file descriptor, at a time when a process had just 15 to
> work with.

If both pipe ends are readable+writeable, you have the Unix equivalent
of VMS mailboxes.  There's lots of opportunity for both deadlock and
livelock, and some "broken pipe" situations become difficult or
impossible to detect.

-Paul W.

From jnc at mercury.lcs.mit.edu  Sun Apr 26 04:03:57 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 25 Apr 2020 14:03:57 -0400 (EDT)
Subject: [TUHS] v7 K&R C
Message-ID: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>

    > From: Rob Pike

    > To make chaining of calls simpler. Write
    >   f()->g()->h()->i()
    > the other way

You mean:

  (*f)((*g)((*h)((*i)())))

I dunno, it doesn't seem that much worse to me.


What I like about the explicit notation (i.e. (*f) ()) is that it forces the
programmer to recognize what's going on.

On the other hand, I guess, the whole concept of compiled languages is to get
the programmer's nose out of the low-level details, so they can focus on the
high level. So I guess one could see allowing f() in place of (*f)() as an
instance of that.

Then again, down that road you find a lot of modern code, where a programmer
writes something that is e.g. horribly inefficient and slow, precisely because
they are so divorced from the low-level of what the code they wrote turns into...


Still, I'd be a little worried about a program doing (*f)((*g)((*h)((*i)()))),
no matter what the notation was; it would be awfully hard to recognize what
all the possible call chains are. But then again I guess a lot of e.g. AI code
does things like that...

       Noel

From blstuart at bellsouth.net  Sun Apr 26 05:01:10 2020
From: blstuart at bellsouth.net (Brian L. Stuart)
Date: Sat, 25 Apr 2020 19:01:10 +0000 (UTC)
Subject: [TUHS] v7 K&R C
In-Reply-To: <1587821712.2206.338.camel@mni.thm.de>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
 <1587821712.2206.338.camel@mni.thm.de>
Message-ID: <2050076633.160857.1587841270567@mail.yahoo.com>

 On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse <hellwig.geisse at mni.thm.de> wrote:
> On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote:
> > Two very different things are happenging, but with the shorthand notation,
> > they share an identical representation. And for what? To save three characters?
> 
> The subject can be looked at from another angle. Consider
> the call f(42). This might be read as first naming f (and
> thus constructing a pointer to f) and then calling the
> function which the pointer is pointing to.

This is the way that I've taken to looking at it for the
last 10 years or so. In fact, I see it as the same thing
as an array. Specifically, I've taken to thinking of []
as a postfix indexing operator and () as a postfix
calling operator, and the thing on the left is a pointer
in both cases.

BLS
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/6be9fb1a/attachment.html>

From jnc at mercury.lcs.mit.edu  Sun Apr 26 05:41:02 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 25 Apr 2020 15:41:02 -0400 (EDT)
Subject: [TUHS] v7 K&R C
Message-ID: <20200425194102.3A54318C0BE@mercury.lcs.mit.edu>

    > From: moanga

    >> To make chaining of calls simpler. Write
    >>   f()->g()->h()->i()

Ah; I was confused by his notation; I didn't realize he meant the C operator
'->'.

	Noel


From michael at kjorling.se  Sun Apr 26 06:11:31 2020
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 25 Apr 2020 20:11:31 +0000
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
References: <CAKzdPgz9=PBaHndt+PDQSL783KVqi6GBX7GA8Fb5UA15gmSfbg@mail.gmail.com>
 <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
Message-ID: <9b9e01a6-fc1a-48a3-879c-665eb5a74205@localhost>

On 25 Apr 2020 14:03 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
> Then again, down that road you find a lot of modern code, where a programmer
> writes something that is e.g. horribly inefficient and slow, precisely because
> they are so divorced from the low-level of what the code they wrote turns into...

...and then there's an exceptionally complicated CPU execution
pipeline in which code is rearranged to try to allow the CPU to
execute it as fast as possible while preserving "observable" behavior.

As we know, down that road lies... security vulnerabilities.

That said, I agree; I don't know how many times I've nearly headdesked
coming across code that looks like someone typed the first thing that
entered their mind, instead of actually thinking the problem through
first and _then_ coding a solution. I'm almost certainly not innocent
there myself, either, although I do try.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


From michael at kjorling.se  Sun Apr 26 06:07:03 2020
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 25 Apr 2020 20:07:03 +0000
Subject: [TUHS] v7 K&R C
In-Reply-To: <2050076633.160857.1587841270567@mail.yahoo.com>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
 <1587821712.2206.338.camel@mni.thm.de>
 <2050076633.160857.1587841270567@mail.yahoo.com>
Message-ID: <9900c104-6f80-4b35-ae53-08b95c9dfbdf@localhost>

On 25 Apr 2020 19:01 +0000, from blstuart at bellsouth.net (Brian L. Stuart):
>  On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse <hellwig.geisse at mni.thm.de> wrote:
>> The subject can be looked at from another angle. Consider
>> the call f(42). This might be read as first naming f (and
>> thus constructing a pointer to f) and then calling the
>> function which the pointer is pointing to.
> 
> This is the way that I've taken to looking at it for the
> last 10 years or so. In fact, I see it as the same thing
> as an array. Specifically, I've taken to thinking of []
> as a postfix indexing operator and () as a postfix
> calling operator, and the thing on the left is a pointer
> in both cases.

That's an interesting way of looking at it.

I was thinking: couldn't we apply the same kind of reasoning to
variables as well?

Bear with me for a second.

If we have

  int z = 123;

then "z" is a mnenomic way of referring to an int-sized memory
location, which after initialization holds the value 123. In C, we can
take the address of any variable stored in memory, and we can
dereference any address into memory. (How _meaningful_ especially the
latter is varies, particularly on memory-protected architectures, but
it's still possible.)

So, is there any material difference between

  printf("%d", z);

and

  printf("%d", *(&z));

If there is, then certainly GCC isn't indicating that it's there. Both
print 123, and both variants compile cleanly even with -Wall -pedantic.

OpenBSD clang 8.0.1 cc also gives identical output for both variants.

So if "z" and "*(&z)" (take the address of z, then dereference that
address, then use the value stored there) are equivalent, then in the
name of consistency, why _shouldn't_ f() and (*f)() (dereference the
address of f, then call) also be equivalent? After all, what is "f"
here, other than a mnenomic name for a memory location?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


From steffen at sdaoden.eu  Sun Apr 26 06:27:06 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 25 Apr 2020 22:27:06 +0200
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425194102.3A54318C0BE@mercury.lcs.mit.edu>
References: <20200425194102.3A54318C0BE@mercury.lcs.mit.edu>
Message-ID: <20200425202706.AA2BQ%steffen@sdaoden.eu>

Noel Chiappa wrote in
<20200425194102.3A54318C0BE at mercury.lcs.mit.edu>:
 |> From: moanga
 |
 |>> To make chaining of calls simpler. Write
 |>>   f()->g()->h()->i()
 |
 |Ah; I was confused by his notation; I didn't realize he meant the C \
 |operator
 |'->'.

Oh, i love this method-on-object as opposed to object-on-function
methodology.

  while(_tr.read_line(*&_line) >= 0){
    ln = _line.trim().squeeze().data();
    len = _line.length();

which can easily exceed a 80x2[45] screen in C.  Especially with
"more modern" frameworks which try to avoid namespace pollution
and easily exceed 20 bytes for a single function name alone.
Of course error handling is often a problem unless you go for
exceptions (terrible, especially if they do not have language
builtin support for file and line number, at least without
-DNDEBUG, imho), general state machines or whatever.

While at C++, the checked automatic upcasts are also very helpful,
especially if you have a deeper object hierarchy.  (As in, struct
object{}, struct drawable{struct object super...}, struct
button{struct drawable super..}, then "drawable d;.. object*=&d
(or for heaven's sake &d.super) is much much better as
&d.super.super or even (object*)&d.)

Damn i have given up on perfection, and sometimes even on
"being explicit is better", but a shame it is.

Ciao, a nice Sunday and Good luck! from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From blstuart at bellsouth.net  Sun Apr 26 07:27:11 2020
From: blstuart at bellsouth.net (Brian L. Stuart)
Date: Sat, 25 Apr 2020 21:27:11 +0000 (UTC)
Subject: [TUHS] v7 K&R C
In-Reply-To: <9b9e01a6-fc1a-48a3-879c-665eb5a74205@localhost>
References: <CAKzdPgz9=PBaHndt+PDQSL783KVqi6GBX7GA8Fb5UA15gmSfbg@mail.gmail.com>
 <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
 <9b9e01a6-fc1a-48a3-879c-665eb5a74205@localhost>
Message-ID: <1734443289.192430.1587850031879@mail.yahoo.com>

 On Saturday, April 25, 2020, 04:11:58 PM EDT, Michael Kjörling <michael at kjorling.se> wrote:
> That said, I agree; I don't know how many times I've nearly headdesked
> coming across code that looks like someone typed the first thing that
> entered their mind, instead of actually thinking the problem through
> first and _then_ coding a solution. I'm almost certainly not innocent
> there myself, either, although I do try.

I know that feeling all too well. I try to think of it in
the same terms as "Let him who is without sin cast
the first stone." But students coming to me with code
that is clearly created using the random walk method
of programming lead to me not always being as patient
with my counsel as I should be.

BLS
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/1f85c6ee/attachment.html>

From blstuart at bellsouth.net  Sun Apr 26 07:34:44 2020
From: blstuart at bellsouth.net (Brian L. Stuart)
Date: Sat, 25 Apr 2020 21:34:44 +0000 (UTC)
Subject: [TUHS] v7 K&R C
In-Reply-To: <9900c104-6f80-4b35-ae53-08b95c9dfbdf@localhost>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
 <1587821712.2206.338.camel@mni.thm.de>
 <2050076633.160857.1587841270567@mail.yahoo.com>
 <9900c104-6f80-4b35-ae53-08b95c9dfbdf@localhost>
Message-ID: <1862444098.192050.1587850484006@mail.yahoo.com>

 On Saturday, April 25, 2020, 04:17:14 PM EDT, Michael Kjörling <michael at kjorling.se> wrote:
> I was thinking: couldn't we apply the same kind of reasoning to
> variables as well?
> ...

In short, yes. In the language Bliss, all identifiers
stood for the address of that thing. A prefix dot (.)
dereferences that thing. So copying x to y would be
something like

y = .x;

In C, rvalues have an implicit dereference happening.

I've actually created a toy language that I subject
my students to that revives the Bliss view to drive
home in their minds the difference between the
address of a memory location and the contents
of a memory location. I want them to have some
concept of how the program connects to the machine
before they find themselves so mired in abstraction
that everything is treated as magic.

One of my TAs in that class last fall was taking a
class in the winter where she was using C seriously
for the first time and having trouble understanding
pointers. When I explained how C pointers worked
in terms of the variables and dots of this other
language it became much more clear for her.

BLS
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/a3a64e09/attachment.html>

From emu at e-bbes.com  Sun Apr 26 10:07:33 2020
From: emu at e-bbes.com (emanuel stiebler)
Date: Sat, 25 Apr 2020 20:07:33 -0400
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
Message-ID: <0db3027a-0928-99a8-240c-4b8b3edf4401@e-bbes.com>

On 2020-04-25 14:03, Noel Chiappa wrote:

> You mean:
>   (*f)((*g)((*h)((*i)())))

Are we still discussing LISP or C?
Sorry, couldn't resist ;-)

From robpike at gmail.com  Sun Apr 26 10:54:07 2020
From: robpike at gmail.com (Rob Pike)
Date: Sun, 26 Apr 2020 10:54:07 +1000
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
Message-ID: <CAKzdPgwU=5FOo3=00frvAgT1-aQ9nv2PkXmhAHh5HoMRcOwB_w@mail.gmail.com>

>
> You mean:
>
>   (*f)((*g)((*h)((*i)())))
>
>
No.

-rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200426/ddf45a1d/attachment.html>

From arnold at skeeve.com  Sun Apr 26 16:40:58 2020
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 26 Apr 2020 00:40:58 -0600
Subject: [TUHS] v7 K&R C
In-Reply-To: <2050076633.160857.1587841270567@mail.yahoo.com>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
 <1587821712.2206.338.camel@mni.thm.de>
 <2050076633.160857.1587841270567@mail.yahoo.com>
Message-ID: <202004260640.03Q6ewui006245@freefriends.org>

"Brian L. Stuart" <blstuart at bellsouth.net> wrote:

>  On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse <hellwig.geisse at mni.thm.de> wrote:
> > On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote:
> > > Two very different things are happenging, but with the shorthand notation,
> > > they share an identical representation. And for what? To save three characters?
> > 
> > The subject can be looked at from another angle. Consider
> > the call f(42). This might be read as first naming f (and
> > thus constructing a pointer to f) and then calling the
> > function which the pointer is pointing to.
>
> This is the way that I've taken to looking at it for the
> last 10 years or so. In fact, I see it as the same thing
> as an array. Specifically, I've taken to thinking of []
> as a postfix indexing operator and () as a postfix
> calling operator, and the thing on the left is a pointer
> in both cases.
>
> BLS
>   
Algol 68 had a concept "deproceduring" similar to "dereferencing". If you
think of 

	foo(arg)

where plain "foo" is a pointer to a function and adding the parentheses
does the call, then it's the same with a procedure name or with
a function pointer.

This is pretty much what BLS said.  Thinking of [] and () as operators
is explicit in C++ (for good and for ill).

Arnold

From dfawcus+lists-tuhs at employees.org  Mon Apr 27 05:37:04 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Sun, 26 Apr 2020 20:37:04 +0100
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
Message-ID: <20200426193704.GA87816@clarinet.employees.org>

On Sat, Apr 25, 2020 at 02:03:57PM -0400, Noel Chiappa wrote:
>     > From: Rob Pike
> 
>     > To make chaining of calls simpler. Write
>     >   f()->g()->h()->i()
>     > the other way
> 
> You mean:
> 
>   (*f)((*g)((*h)((*i)())))
> 
> I dunno, it doesn't seem that much worse to me.

No, I think he means something like:

   (*((*((*((*f)()->g))()->h))()->i))()

but I can't recall the relative priority of '*' and '->' in
the above, so I may have added unnecessary parens.

Or was he thinking of having to use '.' as well to access
the member pointers within the structs?

DF

From dfawcus+lists-tuhs at employees.org  Mon Apr 27 06:10:44 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Sun, 26 Apr 2020 21:10:44 +0100
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200426193704.GA87816@clarinet.employees.org>
References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
 <20200426193704.GA87816@clarinet.employees.org>
Message-ID: <20200426201044.GB87816@clarinet.employees.org>

On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote:
> No, I think he means something like:
> 
>    (*((*((*((*f)()->g))()->h))()->i))()
> 
> but I can't recall the relative priority of '*' and '->' in
> the above, so I may have added unnecessary parens.

Actually trying it, while the above does the right thing,
I can also get the following to compile with a modern compiler

    (*(*(*(*f)()->g)()->h)()->i)();

So maybe that was the answer?

I guess I'd have to question why someone would wish to write
such a construct, as error handling seems awkward.  Even in
the modern form.

DF

From rdm at cfcl.com  Mon Apr 27 07:59:43 2020
From: rdm at cfcl.com (Rich Morin)
Date: Sun, 26 Apr 2020 14:59:43 -0700
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200426201044.GB87816@clarinet.employees.org>
References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
 <20200426193704.GA87816@clarinet.employees.org>
 <20200426201044.GB87816@clarinet.employees.org>
Message-ID: <9EE9F12A-F44F-4BB8-B859-9D77AF46F4EF@cfcl.com>

> On Apr 26, 2020, at 13:10, Derek Fawcus wrote:
> 
> I guess I'd have to question why someone would wish to write such a construct,
> as error handling seems awkward.

FWIW, I do most of my programming these days in Elixir.  It's a functional
programming language with pervasive pattern matching, Rubyish syntax, and
Lispish macros.  It runs on the Erlang virtual machine, so it has a good
story for Actor-based concurrency, distribution, etc.  For details, see:

  https://en.wikipedia.org/wiki/Elixir_(programming_language)

Anyway, compilation is mostly handled by Lispish macros, so it can support
some fairly cool metaprogramming.  In particular, I can write things like:

out_map = inp_list     |>
Enum.filter(filter_fn) |>
Enum.map(map_fn)       |>
Enum.reduce(%{}, reduce_fn)

Piped values are handed in as the first argument to each function and most
functions expect this behavior.  For extra credit, there is a set of Stream
functions (really, macros) that process one element at a time and handle
errors in a reasonable manner.

-r




From noel.hunt at gmail.com  Mon Apr 27 08:38:39 2020
From: noel.hunt at gmail.com (Noel Hunt)
Date: Mon, 27 Apr 2020 08:38:39 +1000
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200426201044.GB87816@clarinet.employees.org>
References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
 <20200426193704.GA87816@clarinet.employees.org>
 <20200426201044.GB87816@clarinet.employees.org>
Message-ID: <CAGfO01xwwQarn9uvXobvLNLQc1dcV3=GqjbDk6N=qu77CPgzvA@mail.gmail.com>

Tom Cargill makes (made) frequent use of this construction in 'pi'
(process inspector, first in Eight Edition), e.g.,

asm.c:  _asm->core->process()->openmemory(addr);
frame.c: return core->process()->frame(level-1)->regloc((int)v->range.lo,
v->type.size_of());
phrase.c:  frame->symtab()->core()->process()->openmemory(expr->val.lng);


On Mon, Apr 27, 2020 at 6:11 AM Derek Fawcus <
dfawcus+lists-tuhs at employees.org> wrote:

> On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote:
> > No, I think he means something like:
> >
> >    (*((*((*((*f)()->g))()->h))()->i))()
> >
> > but I can't recall the relative priority of '*' and '->' in
> > the above, so I may have added unnecessary parens.
>
> Actually trying it, while the above does the right thing,
> I can also get the following to compile with a modern compiler
>
>     (*(*(*(*f)()->g)()->h)()->i)();
>
> So maybe that was the answer?
>
> I guess I'd have to question why someone would wish to write
> such a construct, as error handling seems awkward.  Even in
> the modern form.
>
> DF
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200427/99797b10/attachment.html>

From cym224 at gmail.com  Mon Apr 27 09:57:24 2020
From: cym224 at gmail.com (Nemo Nusquam)
Date: Sun, 26 Apr 2020 19:57:24 -0400
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200426201044.GB87816@clarinet.employees.org>
References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
 <20200426193704.GA87816@clarinet.employees.org>
 <20200426201044.GB87816@clarinet.employees.org>
Message-ID: <62bd7be3-a608-f9fd-3544-8620802d4ac7@gmail.com>

On 04/26/20 16:10, Derek Fawcus wrote:
> On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote:
>> No, I think he means something like:
>>
>>     (*((*((*((*f)()->g))()->h))()->i))()
>>
>> but I can't recall the relative priority of '*' and '->' in
>> the above, so I may have added unnecessary parens.
> Actually trying it, while the above does the right thing,
> I can also get the following to compile with a modern compiler
>
>      (*(*(*(*f)()->g)()->h)()->i)();
>
> So maybe that was the answer?

K&R 1, Sect. 6.2. (with no mention of Rob Pike's influence).

N.

>
> I guess I'd have to question why someone would wish to write
> such a construct, as error handling seems awkward.  Even in
> the modern form.
>
> DF


From robpike at gmail.com  Mon Apr 27 13:38:18 2020
From: robpike at gmail.com (Rob Pike)
Date: Mon, 27 Apr 2020 13:38:18 +1000
Subject: [TUHS] v7 K&R C
In-Reply-To: <62bd7be3-a608-f9fd-3544-8620802d4ac7@gmail.com>
References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
 <20200426193704.GA87816@clarinet.employees.org>
 <20200426201044.GB87816@clarinet.employees.org>
 <62bd7be3-a608-f9fd-3544-8620802d4ac7@gmail.com>
Message-ID: <CAKzdPgwo_rojCefR1LfVwe-nE-gwsUH=vkosN2-0V5G+M6iLkw@mail.gmail.com>

Yes, that's the issue, which arose in C++ programs. The question at the
time was whether C would allow the same syntax.

Nothing to do with me.

-rob


On Mon, Apr 27, 2020 at 9:58 AM Nemo Nusquam <cym224 at gmail.com> wrote:

> On 04/26/20 16:10, Derek Fawcus wrote:
> > On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote:
> >> No, I think he means something like:
> >>
> >>     (*((*((*((*f)()->g))()->h))()->i))()
> >>
> >> but I can't recall the relative priority of '*' and '->' in
> >> the above, so I may have added unnecessary parens.
> > Actually trying it, while the above does the right thing,
> > I can also get the following to compile with a modern compiler
> >
> >      (*(*(*(*f)()->g)()->h)()->i)();
> >
> > So maybe that was the answer?
>
> K&R 1, Sect. 6.2. (with no mention of Rob Pike's influence).
>
> N.
>
> >
> > I guess I'd have to question why someone would wish to write
> > such a construct, as error handling seems awkward.  Even in
> > the modern form.
> >
> > DF
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200427/8c8c2b23/attachment.html>

From dot at dotat.at  Mon Apr 27 23:19:23 2020
From: dot at dotat.at (Tony Finch)
Date: Mon, 27 Apr 2020 14:19:23 +0100
Subject: [TUHS] v7 K&R C
In-Reply-To: <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
References: <CF4F4BC8-F9ED-4A4A-BBFB-E11F2539CF99@gmail.com>
 <CANV78LSvRwb6bDsZBzsEgunu62vYksofOj3MO9rEGqHa9fi_vQ@mail.gmail.com>
 <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com>
 <CAKzdPgwyF3E=hSSfxw38R7Wcr6RXofpEg_6i_41AG33t2VwUuw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2004271402130.27310@grey.csi.cam.ac.uk>

Rob Pike <robpike at gmail.com> wrote:

> The ability to call a function pointer fp with the syntax fp() rather than
> (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> sure it was not in v7 C, as you observe.

I've seen some interesting discussion about Dave Horsfall's favourite
retro-C definition of abort():

	int abort 4;
	...
		abort();

https://minnie.tuhs.org/pipermail/tuhs/2020-March/020680.html

In particular a lot of people didn't know that function pointers could not
be called like abort() so they didn't realise that 4 was the machine code
contents of the function, not the address of the function. (Extra
confusing since branching to address 4 was also a plausible way to crash
the program...)

But that made me wonder what 7th-and-earlier C would do if you tried to
call a local variable. I guess that would lead to the compiler saying

		error("Call of non-function");

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes: Northeasterly 4 to 6, occasionally 7 at
first in north Fair Isle. Moderate or rough. Showers. Good, occasionally
moderate.

From jnc at mercury.lcs.mit.edu  Tue Apr 28 03:45:53 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 27 Apr 2020 13:45:53 -0400 (EDT)
Subject: [TUHS] v7 K&R C
Message-ID: <20200427174553.2801618C09B@mercury.lcs.mit.edu>

    > From: Derek Fawcus

    > I think he means something like:
    >    (*((*((*((*f)()->g))()->h))()->i))()

So I've been confused by this thread, and I'm hoping someone can deconfuse me
- but I think I may have figured it out.

What's confusing me is that in C, the -> operator is followed by "an
identifier [which] designates a member of a structure or union object" (I
checked the spec to make sure my memory hadn't dropped any bits) - but g, h
above are arguments; so I couldn't figure out what was going on.

I think what may have happened is that initially the discussion was about C
("Pretty sure it was not in v7 C"), but then it switched to C++ - with which
I'm not familiar, hence my confusion - without explicitly indicating that
change (although the reference to Bjarne Stroustrup should been a clue). (And
that's why I thought "f()->g()->h()->i()" was ad hoc notation for "calls f(),
then calls g()".)

Am I tracking now?

    Noel



From rich.salz at gmail.com  Tue Apr 28 03:56:37 2020
From: rich.salz at gmail.com (Richard Salz)
Date: Mon, 27 Apr 2020 13:56:37 -0400
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200427174553.2801618C09B@mercury.lcs.mit.edu>
References: <20200427174553.2801618C09B@mercury.lcs.mit.edu>
Message-ID: <CAFH29tryfdkd=bBNdmcv4TNznqtihfDXyU-gZt6CBAVmtCf90Q@mail.gmail.com>

/* struct declarations. */
struct fval;
struct gval;
struct hval;

/* function declarations */
struct fval *f();
struct gval *g();
struct hval *h();

struct fval { struct gval* (*g)(); int dummy; };
struct gval { struct hval* (*h)(); };
struct hval { void (*i)(); };

extern void test();
void test()
{
    f()->g()->h()->i();
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200427/b8e2f9d5/attachment.html>

From brantley at coraid.com  Tue Apr 28 04:02:29 2020
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 27 Apr 2020 18:02:29 +0000
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200427174553.2801618C09B@mercury.lcs.mit.edu>
References: <20200427174553.2801618C09B@mercury.lcs.mit.edu>
Message-ID: <BFCA106B-22CF-423C-AB6F-1AC62DE98582@coraid.com>

g, h and i are members of structures, the pointer of which is returned by the preceding function call. They have to be defined as pointers to functions returning a pointer to the following structure. 

A simple example is:

typedef	struct	Node	Node;

struct Node
{
	Node	*(*f)(void);
};

void
main(void)
{
	Node *p;
	
	p->f()->f()->f();
	call();
	(*((*((*p->f)()->f))())->f)(); 
}
// (*((*((*((*f)()->g))()->h))()->i))()


> On Apr 27, 2020, at 1:45 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Derek Fawcus
> 
>> I think he means something like:
>>   (*((*((*((*f)()->g))()->h))()->i))()
> 
> So I've been confused by this thread, and I'm hoping someone can deconfuse me
> - but I think I may have figured it out.
> 
> What's confusing me is that in C, the -> operator is followed by "an
> identifier [which] designates a member of a structure or union object" (I
> checked the spec to make sure my memory hadn't dropped any bits) - but g, h
> above are arguments; so I couldn't figure out what was going on.
> 
> I think what may have happened is that initially the discussion was about C
> ("Pretty sure it was not in v7 C"), but then it switched to C++ - with which
> I'm not familiar, hence my confusion - without explicitly indicating that
> change (although the reference to Bjarne Stroustrup should been a clue). (And
> that's why I thought "f()->g()->h()->i()" was ad hoc notation for "calls f(),
> then calls g()".)
> 
> Am I tracking now?
> 
>    Noel
> 
> 


From dfawcus+lists-tuhs at employees.org  Tue Apr 28 04:47:22 2020
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Mon, 27 Apr 2020 19:47:22 +0100
Subject: [TUHS] v7 K&R C
In-Reply-To: <20200427174553.2801618C09B@mercury.lcs.mit.edu>
References: <20200427174553.2801618C09B@mercury.lcs.mit.edu>
Message-ID: <20200427184722.GA64072@clarinet.employees.org>

On Mon, Apr 27, 2020 at 01:45:53PM -0400, Noel Chiappa wrote:
> So I've been confused by this thread, and I'm hoping someone can deconfuse me
> - but I think I may have figured it out.
> 
> What's confusing me is that in C, the -> operator is followed by "an
> identifier [which] designates a member of a structure or union object" (I
> checked the spec to make sure my memory hadn't dropped any bits) - but g, h
> above are arguments; so I couldn't figure out what was going on.

See below.

DF

#include <stdio.h>

struct h_ret { void (*i)(); };
struct g_ret { struct h_ret *(*h)(); };
struct f_ret { struct g_ret *(*g)(); };

void i_fn() { printf("I\n"); }

struct h_ret h_val = { i_fn };
struct h_ret *h_fn() { printf("H\n"); return &h_val; }

struct g_ret g_val = { h_fn };
struct g_ret *g_fn() { printf("G\n"); return &g_val; }

struct f_ret f_val = { g_fn };
struct f_ret *f_fn() { printf("F\n"); return &f_val; }

void fred(struct f_ret *(*f)())
{
#if 1
	(*(*(*(*f)()->g)()->h)()->i)();
#else
	f()->g()->h()->i();
#endif
}

int main() { fred(f_fn); return 0; }


From athornton at gmail.com  Tue Apr 28 04:47:29 2020
From: athornton at gmail.com (Adam Thornton)
Date: Mon, 27 Apr 2020 11:47:29 -0700
Subject: [TUHS] s-for-v7, was Re:  v7 K&R C
In-Reply-To: <202004260640.03Q6ewui006245@freefriends.org>
References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu>
 <1587821712.2206.338.camel@mni.thm.de>
 <2050076633.160857.1587841270567@mail.yahoo.com>
 <202004260640.03Q6ewui006245@freefriends.org>
Message-ID: <B3E564BE-0BE6-4FDE-B808-E9F9306F2C2B@gmail.com>

If anyone else could use it, “s” slightly modified from Miller’s sources (via Udo Munk’s repository) to build on out-of-the-box v7 + C compiler:

https://github.com/athornton/s/tree/v7 <https://github.com/athornton/s/tree/v7>

It’s a reimplementation of Paul Ruizendall’s work.  The changes are:
1) the indirect function call syntax needs to be (*fcn)(arg) rather than fcn(arg).
2) scr_delr and scr_delc needed to be shortened by a character because the linker puts an underscore in front of the name and truncates the symbol to 8 characters, and without that fix they are not distinguishable.
3) isprint() in v7 didn't recognize the space as a printable character

Screen repainting doesn’t seem to be entirely reliable, but…it still works a lot like vi, which I find more pleasant than ed.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200427/4d6afeaf/attachment.html>

From jacob.ritorto at gmail.com  Tue Apr 28 11:56:20 2020
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Mon, 27 Apr 2020 21:56:20 -0400
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
Message-ID: <CAHYQbfA6pKX46RqJipojKjWzEfS_bkWyW2bz5wpj5aTOw10ucA@mail.gmail.com>

Hiya!
  Got these two pdp11s, one an 11/23 (Ultrix-11 3.1) and the other an 11/84
(2.11BSD)

On the Ultrix machine, I can enter an assembly language program, assemble
it and run it fine.
amnesiac# cat hello.s
        mov     $1,r0
        sys     4
        a
        6
        sys     1
a:      <Hello\n>
amnesiac# od hello
0000000 000407 000022 000000 000000 000014 000000 000000 000000
0000020 012700 000001 104404 000014 000006 104401 062510 066154
0000040 005157 000000 000000 000000 000002 000000 000000 000000
0000060 000000 000000 000141 000000 000000 000000 000002 000014
0000100
amnesiac# ./hello
Hello
amnesiac#


But on the BSD machine, the exact same source program assembles differently
and crashes with Illegal instruction when I run it.
> cat hello.s
        mov     $1,r0
        sys     4
        a
        6
        sys     1
a:      <Hello\n>
> od a.out
0000000  000407 000022 000000 000000 000010 000000 000000 000000
0000020  012700 000001 104404 000014 000006 104401 062510 066154
0000040  005157 000000 000000 000000 000002 000000 000000 000000
0000060  000000 000000 000000 000004 000002 000014 000000 000006
0000100  000141
0000102
> ./a.out
Illegal instruction (core dumped)
>


Anyone know what I'm doing wrong?

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200427/47dab1c7/attachment.html>

From ron at ronnatalie.com  Tue Apr 28 23:03:16 2020
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 28 Apr 2020 09:03:16 -0400
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
In-Reply-To: <CAHYQbfA6pKX46RqJipojKjWzEfS_bkWyW2bz5wpj5aTOw10ucA@mail.gmail.com>
References: <CAHYQbfA6pKX46RqJipojKjWzEfS_bkWyW2bz5wpj5aTOw10ucA@mail.gmail.com>
Message-ID: <3642A182-45AA-43F8-A07B-8FAB69AD84A9@ronnatalie.com>

Yes, you aren’t programming 2.11 BSD correctly.

Your examples are the older UNIX syscalls (your programs work correctly in Version 6 by the way as well).

In 2.11 BSD, all the arguments for the syscalls are inline (i.e., none are passed in registers.   This appears to be the beginnings of making the kernel protable across architectures.
The systent table no longer has separate fields for args in registers and not in registers and the code in sys/pdp/trap.c doesn’t look at the registers anymore.


> On Apr 27, 2020, at 9:56 PM, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:
> 
>         mov     $1,r0
>         sys     4
>         a
>         6
>         sys     1

Proper code now should be:
          sys 4
         1
         a
         6
        sys 1
        0


Note your previous code used to just return 6 from the program (the return value of write).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200428/ace05c98/attachment.html>

From jacob.ritorto at gmail.com  Wed Apr 29 10:17:54 2020
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Tue, 28 Apr 2020 20:17:54 -0400
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
In-Reply-To: <3642A182-45AA-43F8-A07B-8FAB69AD84A9@ronnatalie.com>
References: <CAHYQbfA6pKX46RqJipojKjWzEfS_bkWyW2bz5wpj5aTOw10ucA@mail.gmail.com>
 <3642A182-45AA-43F8-A07B-8FAB69AD84A9@ronnatalie.com>
Message-ID: <CAHYQbfBPgLKLGeGL=wLBQLOhXqLd0AfpRZOpfJi_7hjo2aYc3w@mail.gmail.com>

On Tue, Apr 28, 2020 at 9:03 AM Ronald Natalie <ron at ronnatalie.com> wrote:

> Yes, you aren’t programming 2.11 BSD correctly.
>

Wow, I'd hoped it was that.  Thank you so much!  I spent way too much time
fiddling incorrectly.
Was an example I'd cobbled together from my college textbook I've been
going back through, _Assembly_Language_for_the_PDP-11_RT-RSX-UNIX_ (c)1981
Kapps and Stafford.  We didn't have UNIX for the class so never ran into
this.


> Your examples are the older UNIX syscalls (your programs work correctly in
> Version 6 by the way as well).
>
> In 2.11 BSD, all the arguments for the syscalls are inline (i.e., none are
> passed in registers.   This appears to be the beginnings of making the
> kernel protable across architectures.
> The systent table no longer has separate fields for args in registers and
> not in registers and the code in sys/pdp/trap.c doesn’t look at the
> registers anymore.
>

I wonder if the differences are written up somewhere.  I did try to look
for more documentation but came up short.  Must've been quite
well-ingrained in programmers' minds in the day.


> Proper code now should be:
>           sys 4
>          1
>          a
>          6
>         sys 1
>         0
> Note your previous code used to just return 6 from the program (the return
> value of write).
>

Ah, so passing exit code as an arg to sys 1.  Cool.  Thanks again!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200428/f10cd57e/attachment.html>

From ron at ronnatalie.com  Wed Apr 29 10:54:24 2020
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Tue, 28 Apr 2020 20:54:24 -0400
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
In-Reply-To: <CAHYQbfBPgLKLGeGL=wLBQLOhXqLd0AfpRZOpfJi_7hjo2aYc3w@mail.gmail.com>
References: <CAHYQbfA6pKX46RqJipojKjWzEfS_bkWyW2bz5wpj5aTOw10ucA@mail.gmail.com>
 <3642A182-45AA-43F8-A07B-8FAB69AD84A9@ronnatalie.com>
 <CAHYQbfBPgLKLGeGL=wLBQLOhXqLd0AfpRZOpfJi_7hjo2aYc3w@mail.gmail.com>
Message-ID: <f8918b56d0077b179ec08e893bdde5b1.squirrel@squirrelmail.tuffmail.net>

Yes, the calling sequence changes were in the back of my mind, but
fortunately the TUHS source archives allowed me to easily look at the
kernel source to see how the arguments were passed.     Somewhere between
2.8 and 2.11 they changed it.   Again, 2.11 was one fo the first attempts
to formalize a true "multi platform" kernel rather than just copying over
the kernel and reworking it for a new machine from a seperate source
"tree."

Yes, your code takes the return of the write system call and uses it as
the exit code.   Not that it makes too much difference.   My 2.11 version
of your code passes a zero explicitly.

Amusingly, speaking of college courses.    I had early on joined the UNIX
systems programming team at JHU and had also done some custom work for
various PDP-11 sites on campus (DOS/BATCH, RT-11, etc...).    PDP-11
assembler was something I knew well.    The head of the EE department told
me he'd be very disappointed if I actually signed up for his PDP-11
assembler programming course my senior year.    Oddly, this caused some
consternation with the faculty committee approving my graduation as I
hadn't taken it and it was required.

Our department UNIX machine as a PDP-11/45 running a high modified V6
kernel.   I also got one of the early 11/23's and we brought up the same
software on that.    A year after I graduated, I was attending a DEC
announcement on the T-11 (I think the first single chip PDP-11).    The
speaker says it had all the instructions with the exception of MARK.   Me
and one other guy are going, "What?   No MARK instruction?"    MARK was
the most useless instruction concocted and it wouldn't even work on an
executable that was set up split I/D.



From jnc at mercury.lcs.mit.edu  Wed Apr 29 12:26:54 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 28 Apr 2020 22:26:54 -0400 (EDT)
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
Message-ID: <20200429022654.D43FA18C08D@mercury.lcs.mit.edu>

    > From: Jacob Ritorto

    > I wonder if the differences are written up somewhere.  I did try to look
    > for more documentation but came up short.

Sounds like a perfect topic for a CHWiki page. :-) E.g. this one:

  http://gunkies.org/wiki/Unix_V6_internals

which I did as a bit of an addendum to Lions, to explain rsav, qsav and ssav, and
similar topics.


I noticed in the comparison of your two binary files that the instructions
looked the same, but the a.out headers had a difference, but I didn't remember
the fields in the a.out header enough to know what the differences meant.

I thought I remembered doing an a.out page there, but apparently not. I
thought about doing one now, but decided it wasn't worth it; I just needed to
spin up my V6 system and do 'man a.out'! :-)

   Noel


From jacob.ritorto at gmail.com  Wed Apr 29 14:08:35 2020
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 29 Apr 2020 00:08:35 -0400
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
In-Reply-To: <20200429022654.D43FA18C08D@mercury.lcs.mit.edu>
References: <20200429022654.D43FA18C08D@mercury.lcs.mit.edu>
Message-ID: <CAHYQbfDUD7Mup6ko7g4hMAio1Q2u1T_9hRmxCYwJtUMogENQzQ@mail.gmail.com>

Shoot, celebrated too soon.  I rearranged it per your tutelage, Ron, and
it's still giving an  Illegal Instruction error!
>From the adb output it looks like it's balking at the "14" instruction at
location 24, which, based on the BSD updates you mentioned, I thought
should've been taken as an arg, not an instruction, right?

I assume this worked for you on some BSD, right?
If so, is it a bug in the recent 2.11BSD patch release, perhaps?  Anyone
able to help me understand?

> vi hello.s
"hello.s" 8 lines, 52 characters
         sys 4
         1
         a
         6
        sys 1
        0
a:      <Hello\n>

"hello.s" 7 lines, 78 characters
> as !$
as hello.s
> ./a.out
Illegal instruction (core dumped)
> od a.out
0000000  000407 000022 000000 000000 000010 000000 000000 000000
0000020  104404 000001 000014 000006 104401 000000 062510 066154
0000040  005157 000000 000000 000002 000000 000000 000000 000000
0000060  000000 000000 000000 000004 000002 000014 000000 000006
0000100  000141
0000102
> adb
adb> :s
stopped at      0:              sys     write
adb> :s
a.out: running
stopped at      04:             <illegal op>    014
adb> :s
a.out: running
Illegal instruction
stopped at      06:             rtt
adb> :s
a.out: running
Illegal instruction - core dumped
process terminated
adb> >

On Tue, Apr 28, 2020 at 10:26 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jacob Ritorto
>
>     > I wonder if the differences are written up somewhere.  I did try to
> look
>     > for more documentation but came up short.
>
> Sounds like a perfect topic for a CHWiki page. :-) E.g. this one:
>
>   http://gunkies.org/wiki/Unix_V6_internals
>
> which I did as a bit of an addendum to Lions, to explain rsav, qsav and
> ssav, and
> similar topics.
>
>
> I noticed in the comparison of your two binary files that the instructions
> looked the same, but the a.out headers had a difference, but I didn't
> remember
> the fields in the a.out header enough to know what the differences meant.
>
> I thought I remembered doing an a.out page there, but apparently not. I
> thought about doing one now, but decided it wasn't worth it; I just needed
> to
> spin up my V6 system and do 'man a.out'! :-)
>
>    Noel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200429/d0950a2b/attachment.html>

From ron at ronnatalie.com  Wed Apr 29 22:20:25 2020
From: ron at ronnatalie.com (Ronald Natalie)
Date: Wed, 29 Apr 2020 08:20:25 -0400
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
In-Reply-To: <CAHYQbfDUD7Mup6ko7g4hMAio1Q2u1T_9hRmxCYwJtUMogENQzQ@mail.gmail.com>
References: <20200429022654.D43FA18C08D@mercury.lcs.mit.edu>
 <CAHYQbfDUD7Mup6ko7g4hMAio1Q2u1T_9hRmxCYwJtUMogENQzQ@mail.gmail.com>
Message-ID: <56F9E80D-8942-4E05-A22F-4A6A123D4F71@ronnatalie.com>

Sorry, I typed that in haste without testing.   I don’t have a 2.11 system to try it on.
However, reading the source code, I did that wrong.
The args go on the stack, not in line with the code.

       mov $6, -(sp)
       mov a, -(sp)
       mov $1,-(sp)
       sys 4


> On Apr 29, 2020, at 12:08 AM, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:
> 
> Shoot, celebrated too soon.  I rearranged it per your tutelage, Ron, and it's still giving an  Illegal Instruction error!
> From the adb output it looks like it's balking at the "14" instruction at location 24, which, based on the BSD updates you mentioned, I thought should've been taken as an arg, not an instruction, right?
> 
> I assume this worked for you on some BSD, right?  
> If so, is it a bug in the recent 2.11BSD patch release, perhaps?  Anyone able to help me understand?
> 
> > vi hello.s
> "hello.s" 8 lines, 52 characters 
>          sys 4
>          1
>          a
>          6
>         sys 1
>         0
> a:      <Hello\n>
> 
> "hello.s" 7 lines, 78 characters 
> > as !$
> as hello.s
> > ./a.out 
> Illegal instruction (core dumped)
> > od a.out
> 0000000  000407 000022 000000 000000 000010 000000 000000 000000
> 0000020  104404 000001 000014 000006 104401 000000 062510 066154
> 0000040  005157 000000 000000 000002 000000 000000 000000 000000
> 0000060  000000 000000 000000 000004 000002 000014 000000 000006
> 0000100  000141
> 0000102
> > adb
> adb> :s
> stopped at      0:              sys     write
> adb> :s
> a.out: running
> stopped at      04:             <illegal op>    014
> adb> :s
> a.out: running
> Illegal instruction
> stopped at      06:             rtt
> adb> :s
> a.out: running
> Illegal instruction - core dumped
> process terminated
> adb> > 
> 
> On Tue, Apr 28, 2020 at 10:26 PM Noel Chiappa <jnc at mercury.lcs.mit.edu <mailto:jnc at mercury.lcs.mit.edu>> wrote:
>     > From: Jacob Ritorto
> 
>     > I wonder if the differences are written up somewhere.  I did try to look
>     > for more documentation but came up short.
> 
> Sounds like a perfect topic for a CHWiki page. :-) E.g. this one:
> 
>   http://gunkies.org/wiki/Unix_V6_internals <http://gunkies.org/wiki/Unix_V6_internals>
> 
> which I did as a bit of an addendum to Lions, to explain rsav, qsav and ssav, and
> similar topics.
> 
> 
> I noticed in the comparison of your two binary files that the instructions
> looked the same, but the a.out headers had a difference, but I didn't remember
> the fields in the a.out header enough to know what the differences meant.
> 
> I thought I remembered doing an a.out page there, but apparently not. I
> thought about doing one now, but decided it wasn't worth it; I just needed to
> spin up my V6 system and do 'man a.out'! :-)
> 
>    Noel
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200429/e14b869b/attachment.html>

From pnr at planet.nl  Wed Apr 29 23:55:41 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 29 Apr 2020 15:55:41 +0200
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
Message-ID: <9A1BF33E-49C9-4712-BF25-4C0BBC504CD1@planet.nl>

> Sorry, I typed that in haste without testing. I don’t have a 2.11 system to try it on. However, reading the source code, I did that wrong. The args go on the stack, not in line with the code.
> mov $6, -(sp)
> mov a, -(sp)
> mov $1,-(sp)
> sys 4

Without suggesting that every helpful post should be tested, I find the superb https://unix50.org web emulator excellent for such things.

Many thanks to the folks hosting & maintaining this great resource!


From ron at ronnatalie.com  Thu Apr 30 00:18:57 2020
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Wed, 29 Apr 2020 10:18:57 -0400
Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD
In-Reply-To: <9A1BF33E-49C9-4712-BF25-4C0BBC504CD1@planet.nl>
References: <9A1BF33E-49C9-4712-BF25-4C0BBC504CD1@planet.nl>
Message-ID: <a5bcdfa7c2f7388ede9ccdfba62c9055.squirrel@squirrelmail.tuffmail.net>

Thanks for the link.   With that help, I fixed the bug in the program:

   mov $6., -(sp)
     mov $1f, -(sp)
     mov $1,-(sp)
     mov $0,-(sp)
     sys 4
     add $8., sp
     mov $0,-(sp)
     mov $0,-(sp)
     sys 1
1:   <hello>


>> Sorry, I typed that in haste without testing. I don’t have a 2.11 system
>> to try it on. However, reading the source code, I did that wrong. The
>> args go on the stack, not in line with the code.
>> mov $6, -(sp)
>> mov a, -(sp)
>> mov $1,-(sp)
>> sys 4
>
> Without suggesting that every helpful post should be tested, I find the
> superb https://unix50.org web emulator excellent for such things.
>
> Many thanks to the folks hosting & maintaining this great resource!
>
>



