From pnr at planet.nl  Thu Dec  1 18:30:14 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 1 Dec 2016 09:30:14 +0100
Subject: [TUHS] looking for 4.1a BSD full kernel source
Message-ID: <A886ECFA-0764-4F4D-830A-D2CC309DD203@planet.nl>


Hi,

I'm trying to find out exactly what was in the 4.1a BSD distribution, as far as the kernel is concerned. The image in the CSRG archive comes from a tape that had a hard read error and does not include any kernel sources. Some of the kernel files were already covered by SCCS around that time, but not everything. My main focus is to understand tcp/ip networking in 4.1a and whether the kernel could be built with either the Berkeley or the BBN network stack.

Does anybody know where I could find a full set of kernel sources for the 4.1a BSD kernel?

Many thanks in advance!

Paul



From pnr at planet.nl  Thu Dec  1 18:38:06 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 1 Dec 2016 09:38:06 +0100
Subject: [TUHS] looking for source code to University of Illinois "Network
	Unix"
Message-ID: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl>


Hi,

I'm looking for the source code to "Network Unix" as described here:
https://tools.ietf.org/html/rfc681
and/or its later development described here:
https://archive.org/details/networkunixsyste243kell

Actually, I'd be happy with finding the source code to any version of this Network Unix. This version of Unix had fairly wide use in the Arpanet community and was in use at several universities and organizations (e.g.: Rand, BBN, etc.)

Would anybody here know of a surviving copy?

Many thanks in advance,

Paul



From pnr at planet.nl  Thu Dec  1 20:40:37 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 1 Dec 2016 11:40:37 +0100
Subject: [TUHS] looking for 4.1a BSD full kernel source
In-Reply-To: <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr>
References: <A886ECFA-0764-4F4D-830A-D2CC309DD203@planet.nl>
 <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr>
Message-ID: <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl>

Hi Diomidis,

Thanks for that link. This is exactly what I'm trying to ascertain, and I'm finding conflicting evidence.
- The socket API was in a state of flux between October '81 and March '82 (when 4.1a was supposedly cut). By March '82 it was mostly there, but not until later in the year did it fully stabilize.
- The BBN stack did not use the sockets API as late as January '82
- What I currently fathom from the SCCS files is that the socket API implementation was hard coded to use the nascent Berkeley stack.
- But the BBN code was likely in the 4.x BSD source tree, outside of SCCS (Berkeley started out with the BBN code, but it morphed quite quickly and drastically)
- In 1985 the BBN code finally enters SCCS (marked 'deprecated'); this code was integrated with the sockets API, and much developed from its 1982 form

Either the below link is correct (and I think I may have contributed to its view in a private mail to Kirk), or there were two different distributions (4.1a BSD with Berkeley network code and 4BSD with BBN network code). The two may have merged into one in peoples' memories: 35 years is a long time. Finding the actual kernel source for the 4.1a distribution could provide clarity on this point.

Perhaps Bill Joy could shed some light on the issue, but I don't have contact details. Having actual source removes all doubt.

Paul


On 1 Dec 2016, at 10:51 , Diomidis Spinellis wrote:

> The best description I could find is the following:
> 
> http://minnie.tuhs.org/pipermail/tuhs/2016-September/007417.html
> 
> > The 4.1a distribution had the initial socket interface with a
> > prerelease of the BBN TCP/IP under it. There was wide distribution
> > of 4.1a. The 4.1b distribution had the fast filesystem added and
> > a more mature socket interface (notably the listen/accept model
> > added by Sam Leffler).
> 
> Diomidis
> 
> On 01/12/2016 10:30, Paul Ruizendaal wrote:
>> 
>> Hi,
>> 
>> I'm trying to find out exactly what was in the 4.1a BSD distribution, as far as the kernel is concerned. The image in the CSRG archive comes from a tape that had a hard read error and does not include any kernel sources. Some of the kernel files were already covered by SCCS around that time, but not everything. My main focus is to understand tcp/ip networking in 4.1a and whether the kernel could be built with either the Berkeley or the BBN network stack.
>> 
>> Does anybody know where I could find a full set of kernel sources for the 4.1a BSD kernel?
>> 
>> Many thanks in advance!
>> 
>> Paul
>> 
> 



From clemc at ccc.com  Fri Dec  2 00:11:16 2016
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Dec 2016 09:11:16 -0500
Subject: [TUHS] looking for source code to University of Illinois
	"Network Unix"
In-Reply-To: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl>
References: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl>
Message-ID: <CAC20D2P5dMFy3ZuTf-y+oC6XU0RO2yyaDxnwDAhCqmeT==sgYA@mail.gmail.com>

I've lost track of Holmgreen who would be your best best.   That said, when
I asked him about it a few years ago, Chesson told me that he had it in his
archives.  @ the time, I thought I had a copy in my CMU archives, but when
I managed to restore the tape I believed to contain it, the "arpanet"
directory was empty.  We must have had it on a separate RK05 image which I
failed to make a copy of when I left.  Dan Klein might have kept a copy and
don't know what Lisa did with Ted Kowalski's archives when he passed two
years ago (I'll try to ask her).

Thinking about it some more, it might be in one of the early USENIX tapes.
  But you'd have to do some digging.  Note if so, remember that the format
of those old tapes will be the original tp program as well as the original
ar, so pulling them apart will take a little work.

FYI:  Assuming I can still read it, I do have a 9-track tape of the MIT
Chaos distribution tape circa '82 from the Steve ward's RTS folks, which I
was under the impression was based on that the UofI kernel hacks for the
NCP; although Noel probably has more complete MIT archives than I.

On Thu, Dec 1, 2016 at 3:38 AM, Paul Ruizendaal <pnr at planet.nl> wrote:

>
> Hi,
>
> I'm looking for the source code to "Network Unix" as described here:
> https://tools.ietf.org/html/rfc681
> and/or its later development described here:
> https://archive.org/details/networkunixsyste243kell
>
> Actually, I'd be happy with finding the source code to any version of this
> Network Unix. This version of Unix had fairly wide use in the Arpanet
> community and was in use at several universities and organizations (e.g.:
> Rand, BBN, etc.)
>
> Would anybody here know of a surviving copy?
>
> Many thanks in advance,
>
> Paul
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161201/50cd0097/attachment.html>

From clemc at ccc.com  Fri Dec  2 00:27:05 2016
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Dec 2016 09:27:05 -0500
Subject: [TUHS] looking for 4.1a BSD full kernel source
In-Reply-To: <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl>
References: <A886ECFA-0764-4F4D-830A-D2CC309DD203@planet.nl>
 <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr>
 <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl>
Message-ID: <CAC20D2NJVnRr+cJ0Jvmrcs4gEEE1_8HZ8t=i3+S-oczQPHVYSw@mail.gmail.com>

Assuming I can read the tape, I know I do have a copy of 4.1a distribution
on 9-track.

Diomidis is correct, 4.1a use Joy/Cooper/Leffler reimplementation of of the
BBN stack, not the original BBN stack.

The BBN stack (Gurwitz et al) was for 4.1 (and other UNIX and non-Unix
systems).   I do not believe I have a copy of that tape.  Rob or maybe Eric
Cooper might.

How Sam added the code into the UCB SCCS, I never knew (you can ask him
directly, he is still findable these days).   Eric Cooper took the basic
BBN distribution and put it on the UCB 4.1 systems around campus >>before<<
Joy started the sockets work.   i.e. the installation was done by
installing 4.1, then taking the BBN tape and installing it as is. Cooper
helped me put it on the CAD machines in Cory Hall circa '81.   I then
helped Eric Allmen put it on the Ingres systems (again Cory Hall) shortly
thereafter [Please, remember, this was the "official" IP/TCP implementation
for UNIX.   Joy's work was an "underground" effort in response to CMU's
Accent].



BTW: about 3 years later, the BBN2 stack comes out from Rob and team and it
is actually even more interesting; because it now uses the sockets
interface (not the Chaosnet/UofI nami trick), and adds a number of both
performance enhancements (Van Jacobson's work, etc.) as well as a more
complete implementation of the IP stack.   I >>might<< have a copy of that
tape squirreled away; but I'll have to look.

On Thu, Dec 1, 2016 at 5:40 AM, Paul Ruizendaal <pnr at planet.nl> wrote:

> Hi Diomidis,
>
> Thanks for that link. This is exactly what I'm trying to ascertain, and
> I'm finding conflicting evidence.
> - The socket API was in a state of flux between October '81 and March '82
> (when 4.1a was supposedly cut). By March '82 it was mostly there, but not
> until later in the year did it fully stabilize.
> - The BBN stack did not use the sockets API as late as January '82
> - What I currently fathom from the SCCS files is that the socket API
> implementation was hard coded to use the nascent Berkeley stack.
> - But the BBN code was likely in the 4.x BSD source tree, outside of SCCS
> (Berkeley started out with the BBN code, but it morphed quite quickly and
> drastically)
> - In 1985 the BBN code finally enters SCCS (marked 'deprecated'); this
> code was integrated with the sockets API, and much developed from its 1982
> form
>
> Either the below link is correct (and I think I may have contributed to
> its view in a private mail to Kirk), or there were two different
> distributions (4.1a BSD with Berkeley network code and 4BSD with BBN
> network code). The two may have merged into one in peoples' memories: 35
> years is a long time. Finding the actual kernel source for the 4.1a
> distribution could provide clarity on this point.
>
> Perhaps Bill Joy could shed some light on the issue, but I don't have
> contact details. Having actual source removes all doubt.
>
> Paul
>
>
> On 1 Dec 2016, at 10:51 , Diomidis Spinellis wrote:
>
> > The best description I could find is the following:
> >
> > http://minnie.tuhs.org/pipermail/tuhs/2016-September/007417.html
> >
> > > The 4.1a distribution had the initial socket interface with a
> > > prerelease of the BBN TCP/IP under it. There was wide distribution
> > > of 4.1a. The 4.1b distribution had the fast filesystem added and
> > > a more mature socket interface (notably the listen/accept model
> > > added by Sam Leffler).
> >
> > Diomidis
> >
> > On 01/12/2016 10:30, Paul Ruizendaal wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to find out exactly what was in the 4.1a BSD distribution,
> as far as the kernel is concerned. The image in the CSRG archive comes from
> a tape that had a hard read error and does not include any kernel sources.
> Some of the kernel files were already covered by SCCS around that time, but
> not everything. My main focus is to understand tcp/ip networking in 4.1a
> and whether the kernel could be built with either the Berkeley or the BBN
> network stack.
> >>
> >> Does anybody know where I could find a full set of kernel sources for
> the 4.1a BSD kernel?
> >>
> >> Many thanks in advance!
> >>
> >> Paul
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161201/fd80a380/attachment.html>

From lm at mcvoy.com  Fri Dec  2 01:30:59 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 1 Dec 2016 07:30:59 -0800
Subject: [TUHS] Masscomp sources? was looking for 4.1a BSD full kernel source
In-Reply-To: <CAC20D2NJVnRr+cJ0Jvmrcs4gEEE1_8HZ8t=i3+S-oczQPHVYSw@mail.gmail.com>
References: <A886ECFA-0764-4F4D-830A-D2CC309DD203@planet.nl>
 <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr>
 <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl>
 <CAC20D2NJVnRr+cJ0Jvmrcs4gEEE1_8HZ8t=i3+S-oczQPHVYSw@mail.gmail.com>
Message-ID: <20161201153059.GL2620@mcvoy.com>

By the way, the "getting started with sockets" document that came with 
the 4.1a BSD based Masscomp version of the OS is by far the nicest 
introduction to sockets that I've ever seen.  I used to have a copy
but lost it.  Any chance of finding that?  Are the Masscomp sources
around?

--lm


From clemc at ccc.com  Fri Dec  2 02:06:05 2016
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Dec 2016 11:06:05 -0500
Subject: [TUHS] Masscomp sources? was looking for 4.1a BSD full kernel
	source
In-Reply-To: <20161201153059.GL2620@mcvoy.com>
References: <A886ECFA-0764-4F4D-830A-D2CC309DD203@planet.nl>
 <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr>
 <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl>
 <CAC20D2NJVnRr+cJ0Jvmrcs4gEEE1_8HZ8t=i3+S-oczQPHVYSw@mail.gmail.com>
 <20161201153059.GL2620@mcvoy.com>
Message-ID: <CAC20D2NOtbC88SHsNUzr9wjkW-AFRGZb-jNzXSd0VLmRXwuohQ@mail.gmail.com>

below...

On Thu, Dec 1, 2016 at 10:30 AM, Larry McVoy <lm at mcvoy.com> wrote:

> By the way, the "getting started with sockets" document that came with
> the 4.1a BSD based Masscomp version of the OS is by far the nicest
> introduction to sockets that I've ever seen.

​Thank you. You made my day.  I lead the coms group when that was done and
while I did not write the document, the doc writer that did, worked under
my direction..​





> I used to have a copy
> but lost it.  Any chance of finding that?

​Maybe - I'll ask her if she kept it.  I don't think I ever had the master.
  FYI: its troff of course ;-)​



>   Are the Masscomp sources
> ​ ​
> around?

​Maybe, I my knowledge they were never put on-line and Concurrent owns the
IP (little know fact - Masscomp is actually the legal entity that still
stands year later - I'll fill you in offline).  As for the sources need to
do some hunting.

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

From pnr at planet.nl  Fri Dec  2 06:13:49 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 1 Dec 2016 21:13:49 +0100
Subject: [TUHS] looking for 4.1a BSD full kernel source
In-Reply-To: <CAC20D2NJVnRr+cJ0Jvmrcs4gEEE1_8HZ8t=i3+S-oczQPHVYSw@mail.gmail.com>
References: <A886ECFA-0764-4F4D-830A-D2CC309DD203@planet.nl>
 <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr>
 <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl>
 <CAC20D2NJVnRr+cJ0Jvmrcs4gEEE1_8HZ8t=i3+S-oczQPHVYSw@mail.gmail.com>
Message-ID: <B69F6919-FAD4-4F60-AD51-6F32D59E5916@planet.nl>

Clem,

Many thanks for your informative post!

> Assuming I can read the tape, I know I do have a copy of 4.1a distribution on 9-track.
That is great news. Let me know once you had a chance to look at it. I am in no hurry, so whenever you have time, even if that is months from now.

> Diomidis is correct, 4.1a use Joy/Cooper/Leffler reimplementation of of the BBN stack, not the original BBN stack.
I suspected as much, but I am happy to hear it confirmed. I've been told on several occasions that 4.1a contained the original BBN stack.

> The BBN stack (Gurwitz et al) was for 4.1 (and other UNIX and non-Unix systems).   I do not believe I have a copy of that tape.  Rob or maybe Eric Cooper might.
> 
> How Sam added the code into the UCB SCCS, I never knew (you can ask him directly, he is still findable these days).   Eric Cooper took the basic BBN distribution and put it on the UCB 4.1 systems around campus >>before<< Joy started the sockets work i.e. the installation was done by installing 4.1, then taking the BBN tape and installing it as is. 

I can confirm all this. I do have several copies of the BBN tapes from '81 and '82, they survived in Kirk McKusick's archive. They indeed contain material that is 'copied over' a clean 4 or 4.1 build tree. The first complete BBN beta is from May 1981 and Joy started on his network code in October 1981.

> BTW: about 3 years later, the BBN2 stack comes out from Rob and team and it is actually even more interesting; because it now uses the sockets interface (not the Chaosnet/UofI nami trick), and adds a number of both performance enhancements (Van Jacobson's work, etc.) as well as a more complete implementation of the IP stack.   I >>might<< have a copy of that tape squirreled away; but I'll have to look.

I think this might be the material that appears in the BSD source tree in 1985, right? Van Jacobson's work is ~1988, I think, but I could well be mistaken. I think the main performance improvement between the 1982 and the 1985 version was a switch from a kernel thread model to a software interrupt model, but as yet I haven't grasped why this is better and my assumption may be incorrect.

Paul



From pnr at planet.nl  Fri Dec  2 06:57:55 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 1 Dec 2016 21:57:55 +0100
Subject: [TUHS] looking for source code to University of Illinois
	"Network Unix"
In-Reply-To: <CAC20D2P5dMFy3ZuTf-y+oC6XU0RO2yyaDxnwDAhCqmeT==sgYA@mail.gmail.com>
References: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl>
 <CAC20D2P5dMFy3ZuTf-y+oC6XU0RO2yyaDxnwDAhCqmeT==sgYA@mail.gmail.com>
Message-ID: <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl>


Clem,

Once again many thanks for an informative post!

> I've lost track of Holmgreen who would be your best best.
I'm in touch with all the principal authors (Holmgren/Bunch/Grossman) and they do not have source code.

> That said, when I asked him about it a few years ago, Chesson told me that he had it in his archives.
If I'm not mistaken Chesson has passed away a few years ago; I assume I should consider these archives lost?

> Thinking about it some more, it might be in one of the early USENIX tapes. But you'd have to do some digging.  Note if so, remember that the format of those old tapes will be the original tp program as well as the original ar, so pulling them apart will take a little work.

That is an interesting lead. Any suggestion where I might start to look? (I know of http://www.tuhs.org/Archive/Applications/, the Shoppa and Spencer tapes, but Network Unix does not seem to be on these tapes).

Paul




From lm at mcvoy.com  Fri Dec  2 07:01:21 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 1 Dec 2016 13:01:21 -0800
Subject: [TUHS] looking for source code to University of Illinois
 "Network Unix"
In-Reply-To: <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl>
References: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl>
 <CAC20D2P5dMFy3ZuTf-y+oC6XU0RO2yyaDxnwDAhCqmeT==sgYA@mail.gmail.com>
 <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl>
Message-ID: <20161201210121.GU2620@mcvoy.com>

On Thu, Dec 01, 2016 at 09:57:55PM +0100, Paul Ruizendaal wrote:
> If I'm not mistaken Chesson has passed away a few years ago; I assume
> I should consider these archives lost?

I know his ex-wife who handled the estate, I can ask her.

I haven't paid close attention, it's 4.1a BSD you want or something else?


From clemc at ccc.com  Fri Dec  2 07:28:32 2016
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Dec 2016 16:28:32 -0500
Subject: [TUHS] looking for 4.1a BSD full kernel source
In-Reply-To: <B69F6919-FAD4-4F60-AD51-6F32D59E5916@planet.nl>
References: <A886ECFA-0764-4F4D-830A-D2CC309DD203@planet.nl>
 <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr>
 <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl>
 <CAC20D2NJVnRr+cJ0Jvmrcs4gEEE1_8HZ8t=i3+S-oczQPHVYSw@mail.gmail.com>
 <B69F6919-FAD4-4F60-AD51-6F32D59E5916@planet.nl>
Message-ID: <CAC20D2NgmFNusYQVR4AN0nZRUQgvvFO8be0GpfYOYrysnFYvfg@mail.gmail.com>

below...

On Thu, Dec 1, 2016 at 3:13 PM, Paul Ruizendaal <pnr at planet.nl> wrote:

> Clem,
>
> Many thanks for your informative post!

​Most welcome.​


>
>
> > Assuming I can read the tape, I know I do have a copy of 4.1a
> distribution on 9-track.
> That is great news. Let me know once you had a chance to look at it. I am
> in no hurry, so whenever you have time, even if that is months from now.

​My queue keeps getting bigger.  I need to retire so I have time for my
home projects ;-)​



>
>
> > Diomidis is correct, 4.1a use Joy/Cooper/Leffler reimplementation of of
> the BBN stack, not the original BBN stack.
> I suspected as much, but I am happy to hear it confirmed. I've been told
> on several occasions that 4.1a contained the original BBN stack.

​Truth is the basic stuff will be pretty similar.   The big thing they
share is mbuf code and how basic IP/TCP state machines.   The primary
changes will be that it's not using open/nami and started to get rid of the
ioctl hacks IIRC.​  It's been a long time since I looked at those stacks.

The original BBN release was >>tuned<< for 4.1BSD but was based on their
"portable" IP/TCP release.  So it's what was used for the HP3000 and few
other systems that DARPA wanted IP stacks.    Again this is more obvious
when you look at the mbuf stuff.  Rob needed a specific OS kernel
independent way of handling memory, so he wrote his own handler and then
spliced the few things it needed into the local kernel.

Joy kept that code for a long time, although in later and later versions of
the BSD stack (i.e. by NET2) the mbuf code has been rehashed by many and
deviated from Rob's stuff in many ways.




>
>
> > The BBN stack (Gurwitz et al) was for 4.1 (and other UNIX and non-Unix
> systems).   I do not believe I have a copy of that tape.  Rob or maybe Eric
> Cooper might.
> >
> > How Sam added the code into the UCB SCCS, I never knew (you can ask him
> directly, he is still findable these days).   Eric Cooper took the basic
> BBN distribution and put it on the UCB 4.1 systems around campus >>before<<
> Joy started the sockets work i.e. the installation was done by installing
> 4.1, then taking the BBN tape and installing it as is.
>
> I can confirm all this. I do have several copies of the BBN tapes from '81
> and '82, they survived in Kirk McKusick's archive.

​You mean on his CD's - if so can you send me a path.  I'll try to peak at
them.  I have the CD's at home, although not online.​




> They indeed contain material that is 'copied over' a clean 4 or 4.1 build
> tree. The first complete BBN beta is from May 1981 and Joy started on his
> network code in October 1981.

​FYI:  I don't remember it as a beta, but you might be right.  I thought it
was the official distribution.   BTW it supported the BBN 1822 interface
and the Xerox 3Mbit boards with the Xerox taps on the Vax.  I wrote a 3Com
driver for it and Sam and I hacked up an InterLan and DEC drivers when we
finally got 10M cable.     We had had a single (3Mbit) Xerox cable that
went through Cory and over to the 5th floor of Evan and then hit its limit.
  But at 3Mbit, it was a huge step of from the Berk-Net (9600 baud serial
over DZ-11 ports).​

3Com, DEC and InterLan all were working on Unibus ethernet board at
different stages of readiness.   3Com must have been shipping for about
18-24 mons by then, because I had used them on Tektronix (I was their first
customer) but UCB was using the Xerox gear when we started.   DEC had
donated some of their gear to the CAD team, so we had those board before
Joy/Sam did in Evans.   Since I had one "pure DEC" system of our 3 780s in
the CAD group (most of the Vaxen at UCB had non-DEC gear), I was often an
early "test system" for Sam.




>
>
> > BTW: about 3 years later, the BBN2 stack comes out from Rob and team and
> it is actually even more interesting; because it now uses the sockets
> interface (not the Chaosnet/UofI nami trick), and adds a number of both
> performance enhancements (Van Jacobson's work, etc.) as well as a more
> complete implementation of the IP stack.   I >>might<< have a copy of that
> tape squirreled away; but I'll have to look.
>
> I think this might be the material that appears in the BSD source tree in
> 1985, right?

​I don't remember/know if it ever got put directly into the BSD tree.   Rob
released it independent of the BSD kit and you needed and BBN license to
get it.   It was what we used at Stellar​, because it was easier to make
parallel and we were adding it into a more System V then BSD-ish kernel
(the Stellar box was a 4 "core" system in its CPU).

There was definitely some bad blood at the time.  BBN had the contract to
support IP/TCP not UCB.  So the stacks did diverge.   Most (commercial)
people used the BSD 4.2 ( and later NET2) implementation because they got
it from UCB and did not get the separate BBN license.  Arpanet contractors
got the BBN2 code automatically, but I don't think many of folks installed
it unless they needed some feature that BBN had that UCB did not.  The
National Labs are likely to have picked it up; but not all of the
Universities.




> Van Jacobson's work is ~1988, I think, but I could well be mistaken.

​Van was at LBL (up the hill as we used to say).    He started with the BSD
4.2 code, but he was talking with Rob pretty regularly.   I know by the
time we did Stellar,  IIRC:  both Van and Rob​ were part of the DARPA
advisors committee (predecessor to the IETF).  I do remember when we were
at Stellar, Van and Rob were talking because we were doing the
threading/parallel lock stuff and I'm pretty sure Rob traded some of our
work for something Van was doing at the time.



> I think the main performance improvement between the 1982 and the 1985
> version was a switch from a kernel thread model to a software interrupt
> model, but as yet I haven't grasped why this is better and my assumption
> may be incorrect.

​I should know, but frankly do not remember.   I suspect if I started to
stare at the code, some of those bits will refill the cache in my brain.
IIRC it was related to the amount of state that needed to be
saved/switched.  In the thread model, I believe you need the complete
context, but in the Interrupt model and are sharing whatever context the
kernel has at the time of the interrupt.​


​Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161201/b543e35d/attachment.html>

From pnr at planet.nl  Fri Dec  2 07:29:08 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 1 Dec 2016 22:29:08 +0100
Subject: [TUHS] looking for source code to University of Illinois
	"Network Unix"
In-Reply-To: <20161201210121.GU2620@mcvoy.com>
References: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl>
 <CAC20D2P5dMFy3ZuTf-y+oC6XU0RO2yyaDxnwDAhCqmeT==sgYA@mail.gmail.com>
 <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl>
 <20161201210121.GU2620@mcvoy.com>
Message-ID: <DE843AA0-CFB7-4F72-A33C-C9E0497CEB67@planet.nl>


> I know his ex-wife who handled the estate, I can ask her.
Many thanks!

> I haven't paid close attention, it's 4.1a BSD you want or something else?
4.1a BSD appears within reach, it is "Network Unix" that I am still looking for:

---
I'm looking for the source code to "Network Unix" as described here:
https://tools.ietf.org/html/rfc681
and/or its later development described here:
https://archive.org/details/networkunixsyste243kell

Actually, I'd be happy with finding the source code to any version of this Network Unix.
---

There is also a 1975 paper by Chesson about it (http://dl.acm.org/citation.cfm?id=806522), I can send you that if it helps.

Paul



From clemc at ccc.com  Fri Dec  2 07:38:08 2016
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Dec 2016 16:38:08 -0500
Subject: [TUHS] looking for source code to University of Illinois
	"Network Unix"
In-Reply-To: <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl>
References: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl>
 <CAC20D2P5dMFy3ZuTf-y+oC6XU0RO2yyaDxnwDAhCqmeT==sgYA@mail.gmail.com>
 <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl>
Message-ID: <CAC20D2ONpnZzms-ZibvNhhuWwE-w8K4UTwpX5wTrSR41iMhCsQ@mail.gmail.com>

below

On Thu, Dec 1, 2016 at 3:57 PM, Paul Ruizendaal <pnr at planet.nl> wrote:

>
> Clem,
>
> Once again many thanks for an informative post!
>
> > I've lost track of Holmgreen who would be your best best.
> I'm in touch with all the principal authors (Holmgren/Bunch/Grossman) and
> they do not have source code.
>
> > That said, when I asked him about it a few years ago, Chesson told me
> that he had it in his archives.
> If I'm not mistaken Chesson has passed away a few years ago;

​Yes.​



> I assume I should consider these archives lost?

​I hope not, but enough people like Larry might be able to talk to his
family.   ​



>
>
> > Thinking about it some more, it might be in one of the early USENIX
> tapes. But you'd have to do some digging.  Note if so, remember that the
> format of those old tapes will be the original tp program as well as the
> original ar, so pulling them apart will take a little work.
>
> That is an interesting lead. Any suggestion where I might start to look?
> (I know of http://www.tuhs.org/Archive/Applications/, the Shoppa and
> Spencer tapes, but Network Unix does not seem to be on these tapes).

I believe you.   The trick is to just keep asking.  It was around the
Arpanet.  Some of the Rand folks would be a good lead also.  ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161201/c5574d19/attachment.html>

From clemc at ccc.com  Fri Dec  2 07:38:57 2016
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Dec 2016 16:38:57 -0500
Subject: [TUHS] looking for source code to University of Illinois
	"Network Unix"
In-Reply-To: <20161201210121.GU2620@mcvoy.com>
References: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl>
 <CAC20D2P5dMFy3ZuTf-y+oC6XU0RO2yyaDxnwDAhCqmeT==sgYA@mail.gmail.com>
 <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl>
 <20161201210121.GU2620@mcvoy.com>
Message-ID: <CAC20D2PA-BbHKwFP7V+pET84_f-+Fn-5dqxqny7ezPzsVEqxXA@mail.gmail.com>

On Thu, Dec 1, 2016 at 4:01 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Dec 01, 2016 at 09:57:55PM +0100, Paul Ruizendaal wrote:
> > If I'm not mistaken Chesson has passed away a few years ago; I assume
> > I should consider these archives lost?
>
> I know his ex-wife who handled the estate, I can ask her.

​That was my guess / hope.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161201/33cee15a/attachment.html>

From jsteve at superglobalmegacorp.com  Sat Dec  3 14:16:19 2016
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Sat, 3 Dec 2016 12:16:19 +0800 
Subject: [TUHS] looking for 4.1a BSD full kernel source
Message-ID: <0F0B9BFC06289346B88512B91E55670D2FED@EXCHANGE>

I'm not sure if my other reply got though, so I'll try again...

I found the source to the BBN stack in the CSRG CD's it's on CD 4

/sys/deprecated/bbnnet


LINT.bbn	08-Aug-2016 06:37 	3.5K
NOTES	08-Aug-2016 06:37 	4.6K
RELAY.bbn	08-Aug-2016 06:37 	1.2K
SCCS/	08-Aug-2016 06:37 	- 
fsm.h	08-Aug-2016 06:37 	1.2K
fsmdef.h	08-Aug-2016 06:37 	9.6K
hmp.c	08-Aug-2016 06:37 	12K
hmp.h	08-Aug-2016 06:37 	3.2K
hmp_subr.c	08-Aug-2016 06:37 	6.5K
hmp_traps.c	08-Aug-2016 06:37 	3.5K
hmp_traps.h	08-Aug-2016 06:37 	2.7K
hmp_var.h	08-Aug-2016 06:37 	1.4K
ic_output.c	08-Aug-2016 06:37 	5.7K
icmp.c	08-Aug-2016 06:37 	17K
icmp.h	08-Aug-2016 06:37 	3.3K
in.c	08-Aug-2016 06:37 	12K
in.h	08-Aug-2016 06:37 	2.0K
in_pcb.c	08-Aug-2016 06:37 	11K
in_pcb.h	08-Aug-2016 06:37 	1.9K
in_proto.c	08-Aug-2016 06:37 	4.9K
in_var.h	08-Aug-2016 06:37 	2.2K
ip.h	08-Aug-2016 06:37 	3.3K
ip_input.c	08-Aug-2016 06:37 	29K
ip_output.c	08-Aug-2016 06:37 	14K
ip_usrreq.c	08-Aug-2016 06:37 	3.8K
macros.h	08-Aug-2016 06:37 	4.4K
net.h	08-Aug-2016 06:37 	2.4K
nopcb.h	08-Aug-2016 06:37 	318 
raw_input.c	08-Aug-2016 06:37 	9.4K
rdp.h	08-Aug-2016 06:37 	15K
rdp_cksum.s	08-Aug-2016 06:3
 7 	4.4K
rdp_fsm.c	08-Aug-2016 06:37 	4.5K
rdp_input.c	08-Aug-2016 06:37 	9.6K
rdp_macros.h	08-Aug-2016 06:37 	7.9K
rdp_prim.c	08-Aug-2016 06:37 	13K
rdp_states.c	08-Aug-2016 06:37 	34K
rdp_subr.c	08-Aug-2016 06:37 	8.4K
rdp_usrreq.c	08-Aug-2016 06:37 	21K
seq.h	08-Aug-2016 06:37 	415 
sws.h	08-Aug-2016 06:37 	326 
tcp.h	08-Aug-2016 06:37 	8.6K
tcp_input.c	08-Aug-2016 06:37 	12K
tcp_prim.c	08-Aug-2016 06:37 	9.8K
tcp_procs.c	08-Aug-2016 06:37 	28K
tcp_states.c	08-Aug-2016 06:37 	20K
tcp_usrreq.c	08-Aug-2016 06:37 	22K
udp.c	08-Aug-2016 06:37 	5.2K
udp.h	08-Aug-2016 06:37 	1.1K
udp_usrreq.c	08-Aug-2016 06:37 	7.0K


I've been meaning to try to try to manually mash stuff together but just
haven't gotten around to it. 

> ----------
> From: 	Paul Ruizendaal
> Sent: 	Thursday, December 1, 2016 4:30 PM
> To: 	tuhs at minnie.tuhs.org
> Subject: 	[TUHS] looking for 4.1a BSD full kernel source
> 
> 
> Hi,
> 
> I'm trying to find out exactly what was in the 4.1a BSD distribution, as
> far as the kernel is concerned. The image in the CSRG archive comes from a
> tape that had a hard read error and does not include any kernel sources.
> Some of the kernel files were already covered by SCCS around that time,
> but not everything. My main focus is to understand tcp/ip networking in
> 4.1a and whether the kernel could be built with either the Berkeley or the
> BBN network stack.
> 
> Does anybody know where I could find a full set of kernel sources for the
> 4.1a BSD kernel?
> 
> Many thanks in advance!
> 
> Paul
> 


From angus at fairhaven.za.net  Fri Dec  2 14:25:03 2016
From: angus at fairhaven.za.net (Angus Robinson)
Date: Fri, 02 Dec 2016 04:25:03 +0000
Subject: [TUHS] The History of Unix
Message-ID: <CAE49LGmJshSb8g5xzQKsq0PifYrHhtDDgr1og7mHgG0bQZ2QCA@mail.gmail.com>

Hi

I am sure there must have been an email about this if so, I do apologies.

The below link is from Diomidis Spinellis work, I remember seeinng an email
from him a few months ago requesting some information about the history of
BSD. Looking at it, he has done some amazing work. I look forward to
playing with 386BSD!

https://github.com/dspinellis/unix-history-repo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161202/eb5abf2d/attachment.html>

From dugo at xs4all.nl  Fri Dec  2 15:47:37 2016
From: dugo at xs4all.nl (Jacob Goense)
Date: Fri, 02 Dec 2016 00:47:37 -0500
Subject: [TUHS] The History of Unix
In-Reply-To: <CAE49LGmJshSb8g5xzQKsq0PifYrHhtDDgr1og7mHgG0bQZ2QCA@mail.gmail.com>
References: <CAE49LGmJshSb8g5xzQKsq0PifYrHhtDDgr1og7mHgG0bQZ2QCA@mail.gmail.com>
Message-ID: <3300aae5806545498d6321cf87c88793@xs4all.nl>

On 2016-12-01 23:25, Angus Robinson wrote:
> I look
> forward to playing with 386BSD!
> 
> https://github.com/dspinellis/unix-history-repo

If you are into 386BSD there is also
https://github.com/386bsd/386bsd

It has sources for the pre Net/2 release. This was
originally a floppy sized set of patches against BSD.

386BSD 1.0 sources. The full distribution was
released as CD-ROM together with a lot of
documentation. I dumped it at
https://github.com/dugoh/386bsdcd if you care
to boot it up.

386BSD 2.0 sources, I think this was released
as an update disk originally and put online
this summer by the Jolitzes.

Warning on 1.0 and 2.0, the copyright notice is
not compatible with BSD.

I had a lot of fun running 0.1 with patch kits.
http://gunkies.org/wiki/Installing_386BSD_on_BOCHS

An attempt to automate that guide with the help of
Travis stranded due to maximum build times, but
Moore will catch up one day.


From lm at mcvoy.com  Fri Dec  2 15:58:59 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 1 Dec 2016 21:58:59 -0800
Subject: [TUHS] The History of Unix
In-Reply-To: <3300aae5806545498d6321cf87c88793@xs4all.nl>
References: <CAE49LGmJshSb8g5xzQKsq0PifYrHhtDDgr1og7mHgG0bQZ2QCA@mail.gmail.com>
 <3300aae5806545498d6321cf87c88793@xs4all.nl>
Message-ID: <20161202055859.GY2620@mcvoy.com>

> I had a lot of fun running 0.1 with patch kits.
> http://gunkies.org/wiki/Installing_386BSD_on_BOCHS

I had a lot of fun running 386BSD on 80486 based laptops.  I remember 
going into Fry's and booting up off the floppy.

The hours I have spent messing with operating systems are a bunch,
don't regret any of it.


From dds at aueb.gr  Fri Dec  2 18:09:12 2016
From: dds at aueb.gr (Diomidis Spinellis)
Date: Fri, 2 Dec 2016 10:09:12 +0200
Subject: [TUHS] The History of Unix
In-Reply-To: <CAE49LGmJshSb8g5xzQKsq0PifYrHhtDDgr1og7mHgG0bQZ2QCA@mail.gmail.com>
References: <CAE49LGmJshSb8g5xzQKsq0PifYrHhtDDgr1og7mHgG0bQZ2QCA@mail.gmail.com>
Message-ID: <a3633aff-744f-d0f5-4f3f-96aff1f753b4@aueb.gr>

Thank you Angus for your kind words.

As a reminder, if your current GitHub account is not linked to your past 
Unix contributions, (you can search them through 
http://www.spinellis.gr/cgi-bin/namegrep.pl), associate your past email 
(e.g. clemc at ucbvax.Berkeley.EDU) with your current account through your 
GitHub account settings https://github.com/settings/emails. (Contact me 
for instructions on how to add email addresses to which you no longer 
have access.)

An extended description of the Unix history repository has now been 
published by the "Empirical Software Engineering" journal.  You can find 
my self-archived preprint at
http://www.spinellis.gr/pubs/jrnl/2016-EMPSE-unix-history/html/unix-history.html
and
http://www.spinellis.gr/pubs/jrnl/2016-EMPSE-unix-history/html/unix-history.pdf
(The official version is available through 
http://dx.doi.org/10.1007/s10664-016-9445-5.)

On 02/12/2016 06:25, Angus Robinson wrote:
> I am sure there must have been an email about this if so, I do apologies.
>
> The below link is from Diomidis Spinellis work, I remember seeinng an
> email from him a few months ago requesting some information about the
> history of BSD. Looking at it, he has done some amazing work. I look
> forward to playing with 386BSD!
>
> https://github.com/dspinellis/unix-history-repo



From pnr at planet.nl  Fri Dec  2 19:37:08 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 2 Dec 2016 10:37:08 +0100
Subject: [TUHS] looking for 4.1a BSD full kernel source
In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2FED@EXCHANGE>
References: <0F0B9BFC06289346B88512B91E55670D2FED@EXCHANGE>
Message-ID: <8D243518-490C-45E7-AA46-F38027677BD2@planet.nl>

Hi Jason,

Sorry to have missed your message earlier. Many thanks for having located this!

As far as I can tell BBN stack you have found is from 1985 and materially different from the BBN stack as it stood late '81, early '82; some folks refer to it as the "BBN2 stack". Two architectural changes were made between the two versions: the process model changed from using a kernel thread to using software interrupts and the API changed from one closely based on Network Unix to using Berkeley sockets. Packet handling code (e.g. the tcp_*.c files) is more or less the same between the two versions.

The distribution tape of the original BBN stack survived in the CSRG archives, but it is not on the Kirk's CD set. I hope that I will be able to add a little section on early packet networking in Unix on the TUHS Unix Tree page with four entries:
- UoI Network Unix
- BBN (Wingfield) TCP/IP for 6th Edition
- 4.1BSD with the BBN stack
- 4.1a BSD

I think those 4 will nice show the development of concepts, code architecture and API's in the 1975 - 1982 period. It will also provide some source code context to "losing a layer" in 1982: http://www.icsy.de/studium/seminar/ws1112/presentations/JohnDay_RINA.pdf

Paul

On 3 Dec 2016, at 5:16 , Jason Stevens wrote:

> I'm not sure if my other reply got though, so I'll try again...
> 
> I found the source to the BBN stack in the CSRG CD's it's on CD 4
> 
> /sys/deprecated/bbnnet
> 
> LINT.bbn	08-Aug-2016 06:37 	3.5KNOTES	08-Aug-2016 06:37 	4.6KRELAY.bbn	08-Aug-2016 06:37 	1.2KSCCS/	08-Aug-2016 06:37 	- fsm.h	08-Aug-2016 06:37 	1.2Kfsmdef.h	08-Aug-2016 06:37 	9.6Khmp.c	08-Aug-2016 06:37 	12Khmp.h	08-Aug-2016 06:37 	3.2Khmp_subr.c	08-Aug-2016 06:37 	6.5Khmp_traps.c	08-Aug-2016 06:37 	3.5Khmp_traps.h	08-Aug-2016 06:37 	2.7Khmp_var.h	08-Aug-2016 06:37 	1.4Kic_output.c	08-Aug-2016 06:37 	5.7Kicmp.c	08-Aug-2016 06:37 	17Kicmp.h	08-Aug-2016 06:37 	3.3Kin.c	08-Aug-2016 06:37 	12Kin.h	08-Aug-2016 06:37 	2.0Kin_pcb.c	08-Aug-2016 06:37 	11Kin_pcb.h	08-Aug-2016 06:37 	1.9Kin_proto.c	08-Aug-2016 06:37 	4.9Kin_var.h	08-Aug-2016 06:37 	2.2Kip.h	08-Aug-2016 06:37 	3.3Kip_input.c	08-Aug-2016 06:37 	29Kip_output.c	08-Aug-2016 06:37 	14Kip_usrreq.c	08-Aug-2016 06:37 	3.8Kmacros.h	08-Aug-2016 06:37 	4.4Knet.h	08-Aug-2016 06:37 	2.4Knopcb.h	08-Aug-2016 06:37 	318 raw_input.c	08-Aug-2016 06:37 	9.4Krdp.h	08-Aug-2016 06:37 	15Krdp_cksum.s	08-Aug-2016 06:3
> 7 	4.4Krdp_fsm.c	08-Aug-2016 06:37 	4.5Krdp_input.c	08-Aug-2016 06:37 	9.6Krdp_macros.h	08-Aug-2016 06:37 	7.9Krdp_prim.c	08-Aug-2016 06:37 	13Krdp_states.c	08-Aug-2016 06:37 	34Krdp_subr.c	08-Aug-2016 06:37 	8.4Krdp_usrreq.c	08-Aug-2016 06:37 	21Kseq.h	08-Aug-2016 06:37 	415 sws.h	08-Aug-2016 06:37 	326 tcp.h	08-Aug-2016 06:37 	8.6Ktcp_input.c	08-Aug-2016 06:37 	12Ktcp_prim.c	08-Aug-2016 06:37 	9.8Ktcp_procs.c	08-Aug-2016 06:37 	28Ktcp_states.c	08-Aug-2016 06:37 	20Ktcp_usrreq.c	08-Aug-2016 06:37 	22Kudp.c	08-Aug-2016 06:37 	5.2Kudp.h	08-Aug-2016 06:37 	1.1Kudp_usrreq.c	08-Aug-2016 06:37 	7.0K
> 
> 
> I've been meaning to try to try to manually mash stuff together but just
> haven't gotten around to it. 
> 
>> ----------
>> From: 	Paul Ruizendaal
>> Sent: 	Thursday, December 1, 2016 4:30 PM
>> To: 	tuhs at minnie.tuhs.org
>> Subject: 	[TUHS] looking for 4.1a BSD full kernel source
>> 
>> 
>> Hi,
>> 
>> I'm trying to find out exactly what was in the 4.1a BSD distribution, as
>> far as the kernel is concerned. The image in the CSRG archive comes from a
>> tape that had a hard read error and does not include any kernel sources.
>> Some of the kernel files were already covered by SCCS around that time,
>> but not everything. My main focus is to understand tcp/ip networking in
>> 4.1a and whether the kernel could be built with either the Berkeley or the
>> BBN network stack.
>> 
>> Does anybody know where I could find a full set of kernel sources for the
>> 4.1a BSD kernel?
>> 
>> Many thanks in advance!
>> 
>> Paul
>> 



From fair-tuhs at netbsd.org  Thu Dec  8 02:46:38 2016
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 07 Dec 2016 08:46:38 -0800
Subject: [TUHS] Unix & Memory Management Units (MMU)
Message-ID: <12385.1481129198@cesium.clock.org>

Which version of Unix first ran on a computer with virtual addressing (address translation) so that a process with non-position independent code (PIC) can be loaded anywhere in RAM that the kernel decided to put it, and memory protection such that no process could accidentally or deliberately access RAM not allocated to it by the kernel (or a SIGSEGV would be delivered to it)?

Put another way, when did Unix processes stop playing Core War with each other? (OK, so long as no more than one is resident at a time, they can't play Core War with each other, but there still needs to be a mechanism to protect the kernel from inadvertent (or advertent) pointer use).

Which is to say, when did Unix run on (and properly use) computers with memory management units (MMU)?

My guess from a quick look at the history of the DEC PDP-11 is that the target computer was likely a PDP-11/35 or PDP-11/40 with a KT11-D "memory management" module.

One imagines that many pointer mistakes (bugs) in assembly or C were discovered and squashed in that version, modulo the historical unhappiness resulting from address zero containing a zero if dereferenced ("NULL pointers") in process address space.

What year did that come about?

By the time I got to Unix (2.8BSD on the Cory Hall DEC PDP-11/70), those features (virtual addresses, memory protection from the kernel) had apparently been part of Unix for a long time - certainly earlier than Version 6.

This is distinct from demand-paged virtual memory which so far as I know was developed on the DEC VAX-11.

	curious,

	Erik <fair at netbsd.org>


From dds at aueb.gr  Thu Dec  8 03:31:22 2016
From: dds at aueb.gr (Diomidis Spinellis)
Date: Wed, 7 Dec 2016 19:31:22 +0200
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <12385.1481129198@cesium.clock.org>
References: <12385.1481129198@cesium.clock.org>
Message-ID: <32c3f08c-9c04-bdeb-82b2-2bfcf1757ddd@aueb.gr>

On 07/12/2016 18:46, Erik E. Fair wrote:
> One imagines that many pointer mistakes (bugs) in assembly or C were
> discovered and squashed in that version, modulo the historical
> unhappiness resulting from address zero containing a zero if
> dereferenced ("NULL pointers") in process address space.

I remember Jan-Simon Pendry telling me in the 1980s, that the NULL 
dereference check was first introduced in SunOS with much pain due to 
the resulting crashes. In BSD Unix, which preceded it, the VAX MMU was 
setup with a page in virtual address 0 that would contain the value 0 at 
that address.  (BSD Unix offered memory protection. I assume it had this 
setup for backward compatibility.)


From jnc at mercury.lcs.mit.edu  Thu Dec  8 03:10:48 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  7 Dec 2016 12:10:48 -0500 (EST)
Subject: [TUHS] Unix & Memory Management Units (MMU)
Message-ID: <20161207171048.638D118C07B@mercury.lcs.mit.edu>

    > From: "Erik E. Fair"

    > Which version of Unix first ran on a computer with virtual addressing

That would be the first version to run on the PDP-11/45; I'm not sure which one
that was, there's not enough left of Version 2 or Version 3 to see; Version 4
definitely ran on the 11/45:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/45.s

    > My guess from a quick look at the history of the DEC PDP-11 is that the
    > target computer was likely a PDP-11/35 or PDP-11/40 with a KT11-D
    > "memory management" module.

No, they came after the -11/45 (with the KT11-C MMU).

    > What year did that come about?

They got one of the first -11/45's, per a Unix history document I'm too busy
to dig up, so 1972.

   Noel


From jnc at mercury.lcs.mit.edu  Thu Dec  8 03:51:47 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  7 Dec 2016 12:51:47 -0500 (EST)
Subject: [TUHS] Unix & Memory Management Units (MMU)
Message-ID: <20161207175147.A6B5818C07B@mercury.lcs.mit.edu>

    > From: "Erik E. Fair" <f

    > One imagines that many pointer mistakes (bugs) in assembly or C were
    > discovered and squashed in that version, modulo the historical
    > unhappiness resulting from address zero containing a zero if
    > dereferenced ("NULL pointers") in process address space.

PS: PDP-11 Unix didn't, I think, do much (anything?) to solve the null pointer
problem. (This is for early C versions; I don't know about the later BSD
ones.)

Location 0 was a usable address for both read and write for everything except
'pure-text' (0410 magic word) processes; in those it was only legal for
read. Address 0 mostly did not contain a 0, either; for C programs using the
stock run-time, it contained a 'setd' instruction, except in split I+D
processes, in which case data space location 0 probably (I'm too busy to spin
up my V6 emulator to check) contained some of the program's initialized data
(unless special arrangements had been made).

	Noel



From clemc at ccc.com  Thu Dec  8 04:49:11 2016
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Dec 2016 13:49:11 -0500
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <12385.1481129198@cesium.clock.org>
References: <12385.1481129198@cesium.clock.org>
Message-ID: <CAC20D2O3rjxD8JktxoqLGG+ju4AEP2ZnpwD3v1rEEQuB6BbCcg@mail.gmail.com>

​below....​

On Wed, Dec 7, 2016 at 11:46 AM, Erik E. Fair <fair-tuhs at netbsd.org> wrote:

> Which is to say, when did Unix run on (and properly use) computers with
> memory management units (MMU)?
>
​Two answers ....   the 11/20 did not have an MMU officially.  ​

​DEC's Custom Special Systems (CSS) group (the same group that spliced an
11/15 disk on to the PDP-7 for Bell Labs) build a simple base/limi register
device, soon after the 11/20 was released.   Ken and Dennis had one of
theses.  So an early version of after the original 11/20 port from the
PDP-7 had this however.....

I would look at Warren's First Edition work to see if there were dregs of
this in that code base to start to try to date it.

As Noel points out the first "official" PDP-11​with an MMU as standard with
it, was indeed the 11/45 (the 11/40 class which included the 35, 60, 34
etc.. came later).  Ken & Dennis got one of the first 11/45s.   It is also
noted that the 45 class system (45/55/70/44) had "17th" address bit - i.e.
split I/D space.  I believe that this is when  "magic numbers" were really
introduced so that could be supported.    I think this is around 3th or 4th
edition.

>
> One imagines that many pointer mistakes (bugs) in assembly or C were
> discovered and squashed in that version, modulo the historical unhappiness
> resulting from address zero containing a zero if dereferenced ("NULL
> pointers") in process address space.
>
> What year did that come about?
>
​Diomidis is incorrect that SunOS was the first Unix to set page 0 to zero.
  This was actually forced by a number of the Unix ports much, much
earlier.   The "NUXI" problem and the Page 0 were two of the issues that
guys that did the port to the IBM Series/1.  I want to say that was 1979 or
maybe 1980 timeframe.   IIRC: that was the Winter Usenix in Boulder CO
("The Black Hole" - conference) when I first remember it being described.

It was a well known issue when many of the 7th edition ports began.   The
problem was the some UNIX application bet in it,   The biggest sinner that
relied on that behavior for the Bourne Shell and how it did memory
management.   Almost every port that could not name page 0 writable and
with a 0 in location, had difficulties with their Unix port, although most
created some strategy to find and fix the issues.

By the time of SunOS, a number of firms were making it page zero and opton,
including BSD itself. By the early 1980s, while I can not claim I invented
it, as I had seen other folks do/talk about it previously at USENIX
conferences, but thought it was a good idea.   So, I had hacked up the CAD
system at UCB's because our team wanted it for debugging some of the codes
we were getting from an unnamed computer company who's OS worked different.
  It was an optional link and not for production, I thought of it as a
debug tool.  I know I gave the hack to Sam at one point, but I do not
remember it making it into the mainline.

But by the mid 1980s, a number of firms made it either standard or an
option like SunOS - because it was a useful debugging tool.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161207/4a8eed75/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Dec  8 06:12:03 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  7 Dec 2016 15:12:03 -0500 (EST)
Subject: [TUHS] Unix & Memory Management Units (MMU)
Message-ID: <20161207201203.9E2BF18C07B@mercury.lcs.mit.edu>

    > From: Clem Cole

    > DEC's Custom Special Systems (CSS) group .. build a simple base/limi
    > register device, soon after the 11/20 was released.> ... So an early
    > version of after the original 11/20 port from the PDP-7 had this
    > however.....

Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to
see if anyone had _any_ documentation for this, but so far, nada.

    > I would look at Warren's First Edition work to see if there were dregs
    > of this in that code base

Alas, I'd already had that idea (to try and at least re-create a programming
spec, at least, for the KS11). There do not seem to be any traces there,
perhaps because that code came from a document entitled "Preliminary Release
of Unix Implementation", which argues that it's a very early 'version' of V0
(the early 'versions' weren't very formal, there was a continuous process of
change/improvement going on, apparently).


    > It is also noted that the 45 class system (45/55/70/44) had "17th"
    > address bit - i.e.  split I/D space.  I believe that this is when "magic
    > numbers" were really introduced so that could be supported.

No, they came in first for 'pure text' (0410):

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/sys1.c

which I would expect arrived to minimize swapping on machines with small
amounts of real memmory.

Support for user split-I/D (411) didn't arrive until Version 6:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c

although IIRC split I/D in the kernel was supported supported slightly
before it was in user - although V5 didn't:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.s

so it couldn't have been much earlier than V6.

	 Noel


From earl.baugh at gmail.com  Thu Dec  8 07:00:17 2016
From: earl.baugh at gmail.com (Earl Baugh)
Date: Wed, 7 Dec 2016 16:00:17 -0500
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <20161207201203.9E2BF18C07B@mercury.lcs.mit.edu>
References: <20161207201203.9E2BF18C07B@mercury.lcs.mit.edu>
Message-ID: <CANcLFn6CfiVHEcyNWOB7KXKVf6nk4MGB_M1kM4OfLx=0rm+D3w@mail.gmail.com>

I can at least shed some light on at least when the Sun boxes supported it
(which may or may not help narrow down the date)
The initial Sun 1/100 multibus machines did not support virtual memory.   I
have one of the last (if not the last) original multibus boards
from Sun with the original PROMs...  and it was supported up to Sun OS 0.7.
   This OS was based off UniSoft UNIX v7.     The 0.7 version was released
in 1982.
In order to support virtual memory systems, there was a board upgrade
required.   Anyone who wanted to go to SunOS 1.0 had to get this board
upgrade (which from what I know, was a board swap... not sure if money
traded hands as well... and is one core reason the original boards are
rare).   The release of Sun OS 1.0 was in November 1983.

So, Sun OS didn't see this until late '83.

Earl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161207/9d61a124/attachment.html>

From pnr at planet.nl  Thu Dec  8 18:50:41 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 8 Dec 2016 09:50:41 +0100
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <20161207201203.9E2BF18C07B@mercury.lcs.mit.edu>
References: <20161207201203.9E2BF18C07B@mercury.lcs.mit.edu>
Message-ID: <5660E19B-36F6-4BD2-84FC-C1383DE4E1B3@planet.nl>


>> DEC's Custom Special Systems (CSS) group .. build a simple base/limi
>> register device, soon after the 11/20 was released.> ... So an early
>> version of after the original 11/20 port from the PDP-7 had this
>> however.....
> 
> Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to
> see if anyone had _any_ documentation for this, but so far, nada.

I was looking for that a few years back. Dennis Ritchie's home pages have
some info on this (https://www.bell-labs.com/usr/dmr/www/odd.html).
At the bottom of that page he writes:

""Back around 1970-71, Unix on the PDP-11/20 ran on hardware that not only did not support virtual memory, but didn't support any kind of hardware memory mapping or protection, for example against writing over the kernel. This was a pain, because we were using the machine for multiple users. When anyone was working on a program, it was considered a courtesy to yell "A.OUT?" before trying it, to warn others to save whatever they were editing.
[..snip..]
We knew the PDP-11/45, which did support memory mapping and protection for the kernel and other processes, was coming, but not instantly; in anticipation, we arranged with Digital Special Systems to buy a PDP-11/20 with KS-11 add-on. This was an extra system unit bolted to the processor that made it distinguish kernel from user mode, and provided a classical PDP-10 style "hi-seg" "low-seg" memory mapping unit. I seem to recall that maybe 6 of these had been made when we ordered it.""

My hypothesis is that the very first versions of Unix were using a memory scheme similar to that used in the later LSX and MX derivatives: the kernel resides in lower memory and the user program in upper memory; each process switch implied a swap. Disclaimer: I have not studied the V0 source to verify this hypothesis.

When this topic had my interest I looked for (but did not find) information on what ""the classical PDP-10 style "hi-seg" "low-seg" memory mapping unit"" was. Here my hypothesis would be that in kernel mode mapping was off, and that in user mode there were two segments, each with a base and limit into physical memory -- and that this setup has an echo in how the later KL-11 MMU was used.

Does anyone have an idea what PDP-10 MMU Dennis may have been referring to?

> (the early 'versions' weren't very formal, there was a continuous process of
> change/improvement going on, apparently).
Can't find the reference now, but it is my understanding that this remained the case throughout. The outside world had editions, but inside Bell Labs it was a continuous process. 

>> I believe that this is when "magic
>> numbers" were really introduced so that could be supported.
My understanding is that the first magic number (0407) was present in the earliest PDP11 versions. Apparently, executables were loaded into memory including the header, and control jumped to the first word loaded. This first word then contained a "jmp $+8" to jump over the header. It stayed as a relic until reused to distinguish between regular and pure text binaries. Here, too, I must admit that I have not scrutinized the V0 source to find support for this understanding.

Paul





From schily at schily.net  Thu Dec  8 20:39:50 2016
From: schily at schily.net (Joerg Schilling)
Date: Thu, 08 Dec 2016 11:39:50 +0100
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <CANcLFn6CfiVHEcyNWOB7KXKVf6nk4MGB_M1kM4OfLx=0rm+D3w@mail.gmail.com>
References: <20161207201203.9E2BF18C07B@mercury.lcs.mit.edu>
 <CANcLFn6CfiVHEcyNWOB7KXKVf6nk4MGB_M1kM4OfLx=0rm+D3w@mail.gmail.com>
Message-ID: <58493876.1W9NvDfq/mBC2kze%schily@schily.net>

Earl Baugh <earl.baugh at gmail.com> wrote:

> I can at least shed some light on at least when the Sun boxes supported it
> (which may or may not help narrow down the date)
> The initial Sun 1/100 multibus machines did not support virtual memory.   I
> have one of the last (if not the last) original multibus boards
> from Sun with the original PROMs...  and it was supported up to Sun OS 0.7.
>    This OS was based off UniSoft UNIX v7.     The 0.7 version was released
> in 1982.
> In order to support virtual memory systems, there was a board upgrade
> required.   Anyone who wanted to go to SunOS 1.0 had to get this board
> upgrade (which from what I know, was a board swap... not sure if money
> traded hands as well... and is one core reason the original boards are
> rare).   The release of Sun OS 1.0 was in November 1983.

The oldest Sun I had was a multibus machine with a mc68010.....This was in 
January 1985. These machines still had a keyboard that was connected to the 
frame buffer to play with the row/col readout lines. See:

/usr/include/sys/kbd.h:#define     KB_KLUNK        0x00            /* Micro Switch 103SD32-2 */

which is still in the recent sources ;-)

The problem you describe is not related to virtual memory, but to demanded page 
loading as an enhancement to the old swapping method. This demanded page 
loading did not work at all with the 68000 and even the Bourne Shell triggered 
a bug from this deficit - see below.

BTW: The name of the OS was not SunOS these days. AFAIR, the first time it was 
called "SunOS" was christmas 1985 (the 0-series of first boards with mc68020 
have been built December 24 1985) and the OS was called SunOS-3.0. I never 
understood how Sun managed to get these boards delivered through the customs 
to Berlin in December 27 or 30. At that time, I was working for the first 
large Sun customer H.Berthold AG and we received these boards.

Before SunOS-3.0, it was called similar to "BSD-4.2 UNIX Sun version foo".

I am not sure what you mean with this NULL ptr dereferences. AFAIR, on SunOS I 
never could dereference a NULL pointer but in SVr3 nearly all commands used an 
option parser that caused a NULL pointer dereference. On SunOS they dumped 
core if you tried to compile and run then.

The printf() on SunOS however printed "(null)" for printf("%s", NULL);

SVr4 used a SunOS kernel and thus did not allow to dereference NULL pointers.
The user space commands have been from SVr3 and _most_ of them had been fixed 
to avoid NULL pointer dereferences.

Today, Solaris comes with a libragy 0 at 0 that maps a page of nulls to address 0.
Call "LD_PRELOAD=0@= command" in case you have one of these nasty programs 
developed on Linux that use to dump core on Solaris ;-)

Back to the Bourne Shell:

The original Bourne Shell did not use malloc, but rather had a SIGSEGV handler 
that used to extend the "string stack" called "stak" via sbrk() whenever the 
code tried to access data beyond the end ot the heap.

This method was great, but did not work with the mc68000, as the 68000 had a 
conceptional bug in the micro code. It could not restart code like:

	*to++ = *from++;

correctly after the return from an exception handler trap.

What Sun did at that time was to add tests to the code to avoid that SIGSEGV 
hits. This code is still in recent Bourne Shell versions.

I did however discover a missed place in the code last year while running a 
fuzzer on the code. Note that the "stak" module has been replaced 2012 with 
code based on a rewrite from Geoff Collyer. See:

	http://schilytools.sourceforge.net/bosh.html

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/


From clemc at ccc.com  Fri Dec  9 02:29:14 2016
From: clemc at ccc.com (Clem Cole)
Date: Thu, 8 Dec 2016 11:29:14 -0500
Subject: [TUHS] Moto and MMU issues -- was Unix & Memory Management
	Units (MMU)
Message-ID: <CAC20D2NV7DOaejq5_EHc52jh90HLjXeNkboSn_9wVFd_XYzYjw@mail.gmail.com>

On Thu, Dec 8, 2016 at 5:39 AM, Joerg Schilling <schily at schily.net> wrote:

> Back to the Bourne Shell:
>
> The original Bourne Shell did not use malloc, but rather had a SIGSEGV
> handler
> that used to extend the "string stack" called "stak" via sbrk() whenever
> the
> code tried to access data beyond the end ot the heap.
>

​Right although the 68K was not the first or the only system to have that
problem - again IIRC Series/1 and maybe one of the PE systems.  You are
correct then SunOS and >>some<< of the 68000 based system did have the
problem you suggested.  And in fact, Masscomp (and Apollo) which used
68000's (but used two of them so could run full VM) could survive that
style of fault (because it never occurred).

BTW: the "conceptual problem" , you mentioned while true, is being a little
harsh.   As the one of the 68K designers (Les Crudele) said to me once,
when they wrote the microcode, there were not thinking about instruction
restart - so the issue was that Nick did not save enough state to do it.

The model for the 68000 that they were using was the base/limit PDP-11 and
the original PDP-10.  Also at the time, the competition was the 6800, the
8080, Z80, 6502.   They were trying to put a PDP-11/70 on chip (without
getting into trouble like CalData did - which Les, Nick and team were very
aware having been DEC and CalData customers before they were at Moto].
While we think of the 68000 family has being 32 bit, the fact is inside it
is a 16 bit system (the barrel shifter and execution functions are 16).
And it was a skunk works project -- the 6809 was Moto's real processor.
It was an experiment done by a couple of rogue engineers that said - hey we
can do better,   The fact was they made a chip that was good enough to
actually compete with the Vax in the end, because it was fast enough AND
they had the wisdom to define 32 bits of address space and 32 bit
operations (again having been PDP-11 users), but as Les used to say - part
of the thinking was that while DEC was moving to the Vax, they had hoped to
break into the area that they 16 bits minis claimed - which they in-fact
did.

And if you think in terms of a Clay Christensen's disruption theory, the
fact that VM did not work easily (i.e. was a "worse" technology than the
Vax) was ok - a new breed of customer did not care.  68000 was huge
success, despite Moto marketing ;-)

To me the larger issue with the 68010 was that when Nick did add the
restart microcode, the new '10 microcode actually dumped version dependant
state on the external stack (in Intel terminology -different "step" '10 put
different state on the external stack or worse, could not restart an
instruction that had been saved from a different step processor).

This screw up was a huge issue when we did replaced the "executor" with a
68010, because it meant that all cpu boards had to be the same processor
microcode revision. Masscomp was of course the first to make an MP, so was
the the first firm to run into the issue (I remember debugging it - we
could not reproduce the issue because of course tjt and my own machine's by
chance had "MPU" boards as we called them with the same step -- it was one
of the field service guys that realized that the customer system had a
mixed step board -- i.e. when they replaced a single MPU in the field, the
system stopped working).  IIRC:  Moto never fixed the '10, as that
processor was reasonably short lived in the open market.   They did fix the
microcode in the '20 so the state on the external stack was independent of
stepping.

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

From ron at ronnatalie.com  Fri Dec  9 02:38:44 2016
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 8 Dec 2016 11:38:44 -0500
Subject: [TUHS] Moto and MMU issues -- was Unix & Memory
	Management	Units (MMU)
In-Reply-To: <CAC20D2NV7DOaejq5_EHc52jh90HLjXeNkboSn_9wVFd_XYzYjw@mail.gmail.com>
References: <CAC20D2NV7DOaejq5_EHc52jh90HLjXeNkboSn_9wVFd_XYzYjw@mail.gmail.com>
Message-ID: <07a801d25171$8b473660$a1d5a320$@ronnatalie.com>



The original Bourne Shell did not use malloc, but rather had a SIGSEGV handler
that used to extend the "string stack" called "stak" via sbrk() whenever the
code tried to access data beyond the end ot the heap.

 

The V6 (Mashey) shell did that.   I thought they’d gotten rid of that by the time the Bourne Shell rolled around.

 

When we ported  UNIX to the Denelcor HEP supercomputer, we had only a single base-offset segment (albeit 64 bits).   The data and stack were allocated from that.   In fact, the “stack” was a linked list.

 

 

 

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

From chet.ramey at case.edu  Fri Dec  9 03:12:43 2016
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 8 Dec 2016 12:12:43 -0500
Subject: [TUHS] Moto and MMU issues -- was Unix & Memory Management
 Units (MMU)
In-Reply-To: <07a801d25171$8b473660$a1d5a320$@ronnatalie.com>
References: <CAC20D2NV7DOaejq5_EHc52jh90HLjXeNkboSn_9wVFd_XYzYjw@mail.gmail.com>
 <07a801d25171$8b473660$a1d5a320$@ronnatalie.com>
Message-ID: <a3d8efbf-e2fc-1e0e-63c0-96f96a202f53@case.edu>

On 12/8/16 11:38 AM, Ron Natalie wrote:
> /
> 
> The original Bourne Shell did not use malloc, but rather had a SIGSEGV handler
> that used to extend the "string stack" called "stak" via sbrk() whenever the
> code tried to access data beyond the end ot the heap./
> 
> / /
> 
> The V6 (Mashey) shell did that.   I thought they’d gotten rid of that by
> the time the Bourne Shell rolled around.

That was one of the changes Bourne made during the deliberations over
which shell would be the Unix "standard" for Bell Labs.  It was always
an efficiency hack, meant to address Mashey shell user concerns about
performance.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From bqt at update.uu.se  Fri Dec  9 04:11:13 2016
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 8 Dec 2016 19:11:13 +0100
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <mailman.13.1481217534.3779.tuhs@minnie.tuhs.org>
References: <mailman.13.1481217534.3779.tuhs@minnie.tuhs.org>
Message-ID: <633b4c57-b7c8-e9aa-540c-084582a38704@update.uu.se>

On 2016-12-08 18:18, Paul Ruizendaal <pnr at planet.nl> wrote:
>
>>> DEC's Custom Special Systems (CSS) group .. build a simple base/limi
>>> register device, soon after the 11/20 was released.> ... So an early
>>> version of after the original 11/20 port from the PDP-7 had this
>>> however.....
>> Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to
>> see if anyone had _any_ documentation for this, but so far, nada.
> I was looking for that a few years back. Dennis Ritchie's home pages have
> some info on this (https://www.bell-labs.com/usr/dmr/www/odd.html).
> At the bottom of that page he writes:
>
> ""Back around 1970-71, Unix on the PDP-11/20 ran on hardware that not only did not support virtual memory, but didn't support any kind of hardware memory mapping or protection, for example against writing over the kernel. This was a pain, because we were using the machine for multiple users. When anyone was working on a program, it was considered a courtesy to yell "A.OUT?" before trying it, to warn others to save whatever they were editing.
> [..snip..]
> We knew the PDP-11/45, which did support memory mapping and protection for the kernel and other processes, was coming, but not instantly; in anticipation, we arranged with Digital Special Systems to buy a PDP-11/20 with KS-11 add-on. This was an extra system unit bolted to the processor that made it distinguish kernel from user mode, and provided a classical PDP-10 style "hi-seg" "low-seg" memory mapping unit. I seem to recall that maybe 6 of these had been made when we ordered it.""
>
> My hypothesis is that the very first versions of Unix were using a memory scheme similar to that used in the later LSX and MX derivatives: the kernel resides in lower memory and the user program in upper memory; each process switch implied a swap. Disclaimer: I have not studied the V0 source to verify this hypothesis.
>
> When this topic had my interest I looked for (but did not find) information on what ""the classical PDP-10 style "hi-seg" "low-seg" memory mapping unit"" was. Here my hypothesis would be that in kernel mode mapping was off, and that in user mode there were two segments, each with a base and limit into physical memory -- and that this setup has an echo in how the later KL-11 MMU was used.
>
> Does anyone have an idea what PDP-10 MMU Dennis may have been referring to?

If you read the Wikipedia page about the PDP-10, you'd find the answer.

Basically, kernel mode uses physical memory. User mode have a low 
segment and a high segment. This is decided by the high bit of the address.
For each segment, there is a base register and a length register.
Commonly, the low segment stored read/write data, while the high segment 
could be shared between processes, and have readonly data/code.

But you could play in other ways with it, if you wanted to.

Essex MUD, as far as I remember, had the game data in a shared hiseg, 
which could be written by the program.

So your guessing is pretty good. Not sure I'd say this is similar to how 
the later PDP-11 MMU works, though. But I can see someone making the 
comparison, since the PDP-11 pages can vary in size, within limits.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From pnr at planet.nl  Fri Dec  9 05:24:37 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 8 Dec 2016 20:24:37 +0100
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <633b4c57-b7c8-e9aa-540c-084582a38704@update.uu.se>
References: <mailman.13.1481217534.3779.tuhs@minnie.tuhs.org>
 <633b4c57-b7c8-e9aa-540c-084582a38704@update.uu.se>
Message-ID: <575522CD-E8D4-4FD0-910D-9B43136A359E@planet.nl>

On 8 Dec 2016, at 19:11 , Johnny Billquist wrote:

> So your guessing is pretty good. Not sure I'd say this is similar to how the later PDP-11 MMU works, though. But I can see someone making the comparison, since the PDP-11 pages can vary in size, within limits.

Thanks for that info on the PDP-10 MMU!

What I meant to say was that the high-low scheme has an echo in how the KL-11 was *used* (not how it *worked*). A standard binary (0407 magic) effectively has two segments in PDP11 Unix: a contiguous low segment (for text, data and bss) and a contiguous high segment (for the stack).

Paul




From pnr at planet.nl  Fri Dec  9 05:44:13 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 8 Dec 2016 20:44:13 +0100
Subject: [TUHS] Unix & Memory Management Units (MMU)
Message-ID: <49292DAA-5E7B-445E-8738-5D00028B8EF4@planet.nl>

Finally took a look at the V1 source.

Referring to http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s
Toward the end of the sysexec function there is:

	cmp	core,$405 / br .+14 is first instruction if file is
			  / standard a.out format
	bne	1f / branch, if not standard format
	mov	core+2,r5 / put 2nd word of users program in r5; number of
			  / bytes in program text
	sub	$14,r5 / subtract 12
	cmp	r5,u.count /
	bgt	1f / branch if r5 greater than u.count
	mov	r5,u.count
	jsr	r0,readi / read in rest of user's program text
	add	core+10,u.nread / add size of user data area to u.nread
	br	2f
1:
	jsr	r0,readi / read in rest of file
2:
	mov	u.nread,u.break / set users program break to end of 
				/ user code
	add	$core+14,u.break / plus data area
	jsr	r0,iclose / does nothing
	br	sysret3 / return to core image at $core

$core is equated to 040000 in another file (u0.s). In V1 apparently the a.out header was 6 words (http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/a.out.5), not 8, and hence the magic for a standard executable was 0405. It was already used as magic to distinguish a.out format files from other executables. It also shows that indeed 'exec' jumped to the first word of the header (at location $core).

From this I don't think we will find code for the KS-11 in the V1 source. The file http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u3.s also seems to support a LSX /MX like approach where each process switch equates a swap.

I'd say that the lost V2 is where memory protection first appeared in Unix, i.e. 1972.

Paul

PS Sorry for writing 'V0' earlier -- I meant V1 all along.





From lars at nocrew.org  Fri Dec  9 05:32:32 2016
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 08 Dec 2016 20:32:32 +0100
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <575522CD-E8D4-4FD0-910D-9B43136A359E@planet.nl> (Paul
 Ruizendaal's message of "Thu, 8 Dec 2016 20:24:37 +0100")
References: <mailman.13.1481217534.3779.tuhs@minnie.tuhs.org>
 <633b4c57-b7c8-e9aa-540c-084582a38704@update.uu.se>
 <575522CD-E8D4-4FD0-910D-9B43136A359E@planet.nl>
Message-ID: <86mvg6fc8f.fsf@molnjunk.nocrew.org>

Paul Ruizendaal wrote:
> Thanks for that info on the PDP-10 MMU!

You're one off.  Maybe you're preoccupied with the upcoming DEC-10
holiday?


From jnc at mercury.lcs.mit.edu  Fri Dec  9 06:38:56 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  8 Dec 2016 15:38:56 -0500 (EST)
Subject: [TUHS] Unix & Memory Management Units (MMU)
Message-ID: <20161208203856.552F318C08A@mercury.lcs.mit.edu>

    > Dennis Ritchie's home pages have some info on this

Yeah, I'd read that - I was hoping for some actual technical info on the KS11,
though.

(I'm assuming he has given the name there correctly, or if his memory has
dropped a bit - a thing which human memories do! :-) - since I've never been
able to find a single mention of it, including in the Spare Module Handbook,
which covers other Special Systems products).


    > I looked for (but did not find) information on what ""the classical
    > PDP-10 style "hi-seg" "low-seg" memory mapping unit"" was.

The best description is in the DECSystem-10 Hardware Reference Manual (mine is
EK-10/20-HR-001, but alas that version appears not to be online - I'll scan my
copy and put it online when I get a chance.) This version:

  http://pdp10.nocrew.org/docs/ad-h391a-t1.pdf

does appear to cover it: pp. 5-38 through 5-40 (pp. 352-354 of the PDF) for
the KA10, and pp. 5-15 to 5-30 (pp. 329-344) for the KI10.

The KA10 provided one (optionally) two base/bounds register pairs, where the
base register contains the location in real memory. With two pairs (the
second one applied to high user address space), the high part could be
write-protected, for sharing pure code.

The KI10 provided something similar to this, but more complicated; it included
paging, but also something called User 'Concealed', which allowed proprietary
subroutine packages to be used, while hidden from the rest of the user's code.

    > Does anyone have an idea what PDP-10 MMU Dennis may have been referring
    > to?

Almost certainly the KA10.

    > Here my hypothesis would be that in kernel mode mapping was off, and
    > that in user mode there were two segments, each with a base and limit
    > into physical memory

Hard to say. Kernel mode might or might not have mapping, and User mode might
have provided one, or two, segments; the KA10 did have an option for
single-segment.


    > this setup has an echo in how the later KL-11 MMU was used.

Sorry, what's a KL-11? The only 'KL11' I know of is the serial line board
(M780) which was the predecessor to the DL11.

       Noel



From dave at horsfall.org  Fri Dec  9 08:02:43 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 9 Dec 2016 09:02:43 +1100 (EST)
Subject: [TUHS] That's not a computer...
Message-ID: <alpine.BSF.2.20.1612090857300.79558@aneurin.horsfall.org>

*This* is a computer!

http://archive.computerhistory.org/resources/text/EAI/EAI.HYDAC2400.1963.102646295.pdf

A hybrid analogue/digital box, what could possibly go wrong?  And check 
out the dudes and dudess supporting it (except she'd better be careful 
when moving her chair, in case she takes out a paper tape unit...).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."



From pechter at gmail.com  Fri Dec  9 08:10:03 2016
From: pechter at gmail.com (William Pechter)
Date: Thu, 8 Dec 2016 17:10:03 -0500
Subject: [TUHS] That's not a computer...
In-Reply-To: <alpine.BSF.2.20.1612090857300.79558@aneurin.horsfall.org>
References: <alpine.BSF.2.20.1612090857300.79558@aneurin.horsfall.org>
Message-ID: <821c16ea-cd9a-4587-a9e7-1abcb01a6947.maildroid@localhost>

Built right down the road from Concurrent Computer/Perkin-Elmer/International... 

I serviced their 11/45 and installed their 11/780 back in the mid 1980s...

-----Original Message-----
From: Dave Horsfall <dave at horsfall.org>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Thu, 08 Dec 2016 17:03
Subject: [TUHS] That's not a computer...

*This* is a computer!

http://archive.computerhistory.org/resources/text/EAI/EAI.HYDAC2400.1963.102646295.pdf

A hybrid analogue/digital box, what could possibly go wrong?  And check 
out the dudes and dudess supporting it (except she'd better be careful 
when moving her chair, in case she takes out a paper tape unit...).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."



From pnr at planet.nl  Fri Dec  9 08:39:39 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 8 Dec 2016 23:39:39 +0100
Subject: [TUHS] Unix & Memory Management Units (MMU)
In-Reply-To: <20161208203856.552F318C08A@mercury.lcs.mit.edu>
References: <20161208203856.552F318C08A@mercury.lcs.mit.edu>
Message-ID: <62BEFE90-C5AD-401C-82E1-0B63750039C0@planet.nl>


>> this setup has an echo in how the later KL-11 MMU was used.
> 
> Sorry, what's a KL-11? The only 'KL11' I know of is the serial line board
> (M780) which was the predecessor to the DL11.

Sorry, my bad -- meant KT11.


From grog at lemis.com  Fri Dec  9 08:57:52 2016
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 9 Dec 2016 09:57:52 +1100
Subject: [TUHS] That's not a computer...
In-Reply-To: <alpine.BSF.2.20.1612090857300.79558@aneurin.horsfall.org>
References: <alpine.BSF.2.20.1612090857300.79558@aneurin.horsfall.org>
Message-ID: <20161208225752.GB93546@eureka.lemis.com>

On Friday,  9 December 2016 at  9:02:43 +1100, Dave Horsfall wrote:
> *This* is a computer!
>
> http://archive.computerhistory.org/resources/text/EAI/EAI.HYDAC2400.1963.102646295.pdf
>
> A hybrid analogue/digital box, what could possibly go wrong?  And check
> out the dudes and dudess supporting it (except she'd better be careful
> when moving her chair, in case she takes out a paper tape unit...).

Ah, that brings back memories, though of a different hybrid computer:
EAI 640/3200 combination at CSIRO in Clayton, back in 1971.  I was too
junior in those days to understand all the details, but I do recall
that it was at least twice the size.

It didn't run Unix, though.  We programmed the digital side in some
FORTRAN dialect that included scaled fractions (integers with the
decimal point at the left).

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org 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/20161209/db206ce5/attachment.sig>

From schily at schily.net  Fri Dec  9 20:25:32 2016
From: schily at schily.net (Joerg Schilling)
Date: Fri, 09 Dec 2016 11:25:32 +0100
Subject: [TUHS] Moto and MMU issues -- was Unix & Memory Management
 Units (MMU)
In-Reply-To: <a3d8efbf-e2fc-1e0e-63c0-96f96a202f53@case.edu>
References: <CAC20D2NV7DOaejq5_EHc52jh90HLjXeNkboSn_9wVFd_XYzYjw@mail.gmail.com>
 <07a801d25171$8b473660$a1d5a320$@ronnatalie.com>
 <a3d8efbf-e2fc-1e0e-63c0-96f96a202f53@case.edu>
Message-ID: <584a869c.oO1JvvacT4DqiEYq%schily@schily.net>

Chet Ramey <chet.ramey at case.edu> wrote:

> On 12/8/16 11:38 AM, Ron Natalie wrote:
> > /
> > 
> > The original Bourne Shell did not use malloc, but rather had a SIGSEGV handler
> > that used to extend the "string stack" called "stak" via sbrk() whenever the
> > code tried to access data beyond the end ot the heap./
> > 
> > / /
> > 
> > The V6 (Mashey) shell did that.   I thought they???d gotten rid of that by
> > the time the Bourne Shell rolled around.

Do you like to say that the Mashey shell also used the string stack and a 
SIGSEV handler?

Well, from a talk from Stephen Bourne I know that both the Bourne Shell and the 
Mashey shell did start as a modified Thompson shell. I should have a look at the
Thompson shell sources...

> That was one of the changes Bourne made during the deliberations over
> which shell would be the Unix "standard" for Bell Labs.  It was always
> an efficiency hack, meant to address Mashey shell user concerns about
> performance.

I am not sure whether this kind of SIGSEGV based string handling helps to have 
a good performance. Having a string stack (regardless of what the low level 
part of the implementation looks like) definitely helps. I am using a similar
technique in my "smake" program and it turns out that the concept of a string
stack is helpful when you write software that needs to create many 
intermediate string copies of unpredictable length.

What I definitely know is that replacing the low level support code from 
Stephen Bourne (stak.c) with an implementation based on the ideas from Geoff 
Collyer did not affect the performance of the Bourne Shell.

The Korn shell did introduce something similar (maybe even also from Geoff 
Collyer with ksh88) and ksh93 is the fastest known shell implementation if it 
is compiled the way, it is in the OpenSolaris integration of the Solaris "ON"
code base.

For today, numbers definitely look different. 30% of the total amount of CPU 
time spend by the Bourne Shell is spend by the conversion from multy-byte 
strings to wide strings and vice versa. BTW: "dash" is faster than bash just 
because it does not imlement multy-byte support. If it did, it would become 
slower than bash.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/


From pnr at planet.nl  Fri Dec  9 21:20:52 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 9 Dec 2016 12:20:52 +0100
Subject: [TUHS] Moto and MMU issues -- was Unix & Memory Management
	Units (MMU)
In-Reply-To: <584a869c.oO1JvvacT4DqiEYq%schily@schily.net>
References: <CAC20D2NV7DOaejq5_EHc52jh90HLjXeNkboSn_9wVFd_XYzYjw@mail.gmail.com>
 <07a801d25171$8b473660$a1d5a320$@ronnatalie.com>
 <a3d8efbf-e2fc-1e0e-63c0-96f96a202f53@case.edu>
 <584a869c.oO1JvvacT4DqiEYq%schily@schily.net>
Message-ID: <B21255F2-3EE6-406B-B193-EE8D962CD3AF@planet.nl>


> Do you like to say that the Mashey shell also used the string stack and a 
> SIGSEV handler?
Don't think it did: http://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s2/sh.c

> Well, from a talk from Stephen Bourne I know that both the Bourne Shell and the 
> Mashey shell did start as a modified Thompson shell. I should have a look at the
> Thompson shell sources…
Also did not: http://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/sh.c



From arnold at skeeve.com  Fri Dec  9 22:13:19 2016
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 09 Dec 2016 05:13:19 -0700
Subject: [TUHS] Moto and MMU issues -- was Unix & Memory Management
 Units (MMU)
In-Reply-To: <584a869c.oO1JvvacT4DqiEYq%schily@schily.net>
References: <CAC20D2NV7DOaejq5_EHc52jh90HLjXeNkboSn_9wVFd_XYzYjw@mail.gmail.com>
 <07a801d25171$8b473660$a1d5a320$@ronnatalie.com>
 <a3d8efbf-e2fc-1e0e-63c0-96f96a202f53@case.edu>
 <584a869c.oO1JvvacT4DqiEYq%schily@schily.net>
Message-ID: <201612091213.uB9CDJSl009834@freefriends.org>

Getting a bit off topic...

schily at schily.net (Joerg Schilling) wrote:

> For today, numbers definitely look different. 30% of the total amount of CPU 
> time spend by the Bourne Shell is spend by the conversion from multy-byte 
> strings to wide strings and vice versa. BTW: "dash" is faster than bash just 
> because it does not imlement multy-byte support. If it did, it would become 
> slower than bash.

Interesting. Gawk stores everything in multibyte form and only converts
to/from wide characters when needed (length, substr, match, a few others).

I don't have timings either way, but I'm pretty sure that gawk doesn't
spend anything like 30% of its time doing those conversions. :-)

Arnold


From dave at horsfall.org  Sat Dec 10 05:11:05 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 10 Dec 2016 06:11:05 +1100 (EST)
Subject: [TUHS] Happy birthday, J.F.Ossanna!
Message-ID: <alpine.BSF.2.20.1612100600040.79558@aneurin.horsfall.org>

J.F.Ossanna was given unto us in 1928; a prolific programmer, he not only 
had a hand in developing Unix but also gave us the ROFF series.

PS: Ada Lovelace, arguably the world's first computer programmer, was 
given unto us in 1815; she saw the potential in Charles Babbage's 
new-fangled thing.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From wkt at tuhs.org  Sun Dec 18 08:34:16 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 18 Dec 2016 08:34:16 +1000
Subject: [TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?
Message-ID: <20161217223416.GA12706@minnie.tuhs.org>

All, I'm writing a paper based on my June 2016 talk on PDP-7 Unix. As part
of that I was looking at the BCPL -> B -> NB -> C history. And as part of
that, I was reading Ken's B manual, written in 1972:

https://www.bell-labs.com/usr/dmr/www/kbman.pdf

Then I noticed at the end Ken refers to:

	Ritchie, D.M.  The UNIX Time Sharing System.  MM 71-1273-4.

which makes me think that the draft version Doug McIlroy found
(now at http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/UnixEditionZero-Threshold_OCR.pdf)
must have made it into a full memorandum.

Given that we  have the memorandum number, does anybody know if it
would be possible to find it in the archives from what was Bell Labs?

Cheers, Warren


From doug at cs.dartmouth.edu  Sat Dec 17 12:09:16 2016
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 16 Dec 2016 21:09:16 -0500
Subject: [TUHS] How Unix made it to the top
Message-ID: <201612170209.uBH29G4k022238@coolidge.cs.Dartmouth.EDU>

It has often been told how the Bell Labs law department became the
first non-research department to use Unix, displacing a newly acquired
stand-alone word-processing system that fell short of the department's
hopes because it couldn't number the lines on patent applications,
as USPTO required. When Joe Ossanna heard of this, he told them about
roff and promised to give it line-numbering capability the next day.
They tried it and were hooked. Patent secretaries became remote
members of the fellowship of the Unix lab. In due time the law
department got its own machine.

Less well known is how Unix made it into the head office of AT&T. It
seems that the CEO, Charlie Brown, did not like to be seen wearing
glasses when he read speeches. Somehow his PR assistant learned of
the CAT phototypesetter in the Unix lab and asked whether it might be
possible to use it to produce scripts in large type. Of course it was.
As connections to the top never hurt, the CEO's office was welcomed
as another ouside user. The cost--occasionally having to develop film
for the final copy of a speech--was not onerous.

Having teethed on speeches, the head office realized that Unix could
also be useful for things that didn't need phototypesetting. Other
documents began to accumulate in their directory. By the time we became
aware of it, the hoard came to include minutes of AT&T board meetings.
It didn't seem like a very good idea for us to be keeping records from
the inner sanctum of the corporation on a computer where most everybody
had super-user privileges. A call to the PR guy convinced him of the
wisdom of keeping such things on their own premises. And so the CEO's
office bought a Unix system.

Just as one hears of cars chosen for their cupholders, so were these
users converted to Unix for trivial reasons: line numbers and vanity.

Doug


From kayparker at mailite.com  Sun Dec 18 18:54:17 2016
From: kayparker at mailite.com (=?utf-8?Q?Kay=20Parker=20=09=20?=)
Date: Sun, 18 Dec 2016 00:54:17 -0800
Subject: [TUHS] How Unix made it to the top
In-Reply-To: <201612170209.uBH29G4k022238@coolidge.cs.Dartmouth.EDU>
References: <201612170209.uBH29G4k022238@coolidge.cs.Dartmouth.EDU>
Message-ID: <1482051257.3477435.822560385.08D55CE8@webmail.messagingengine.com>

thanks a lot Doug!

On Fri, Dec 16, 2016, at 06:09 PM, Doug McIlroy wrote:
> It has often been told how the Bell Labs law department became the
> first non-research department to use Unix, displacing a newly acquired
> stand-alone word-processing system that fell short of the department's
> hopes because it couldn't number the lines on patent applications,
> as USPTO required. When Joe Ossanna heard of this, he told them about
> roff and promised to give it line-numbering capability the next day.
> They tried it and were hooked. Patent secretaries became remote
> members of the fellowship of the Unix lab. In due time the law
> department got its own machine.
> 
> Less well known is how Unix made it into the head office of AT&T. It
> seems that the CEO, Charlie Brown, did not like to be seen wearing
> glasses when he read speeches. Somehow his PR assistant learned of
> the CAT phototypesetter in the Unix lab and asked whether it might be
> possible to use it to produce scripts in large type. Of course it was.
> As connections to the top never hurt, the CEO's office was welcomed
> as another ouside user. The cost--occasionally having to develop film
> for the final copy of a speech--was not onerous.
> 
> Having teethed on speeches, the head office realized that Unix could
> also be useful for things that didn't need phototypesetting. Other
> documents began to accumulate in their directory. By the time we became
> aware of it, the hoard came to include minutes of AT&T board meetings.
> It didn't seem like a very good idea for us to be keeping records from
> the inner sanctum of the corporation on a computer where most everybody
> had super-user privileges. A call to the PR guy convinced him of the
> wisdom of keeping such things on their own premises. And so the CEO's
> office bought a Unix system.
> 
> Just as one hears of cars chosen for their cupholders, so were these
> users converted to Unix for trivial reasons: line numbers and vanity.
> 
> Doug


-- 
  Kay Parker       
  kayparker at mailite.com

-- 
http://www.fastmail.com - The way an email service should be



From arnold at skeeve.com  Mon Dec 19 00:20:00 2016
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 18 Dec 2016 07:20:00 -0700
Subject: [TUHS] Re Dennis' Draft of the Unix Timesharing System: not so
	draft?
Message-ID: <201612181420.uBIEK0Fe024630@freefriends.org>

I forwarded your note to BWK who seems to still have a few tenuous
connections to the Labs.

Good luck with it.

Arnold


From scj at yaccman.com  Sun Dec 18 15:48:55 2016
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 17 Dec 2016 21:48:55 -0800
Subject: [TUHS] How Unix made it to the top
In-Reply-To: <201612170209.uBH29G4k022238@coolidge.cs.Dartmouth.EDU>
Message-ID: <6765d35491677b6b2ca2e5a49176ece794aaf07b@webmail.yaccman.com>

As a postscript, on at least one occasion, the speech was finished so
close to
the time of delivery that a helicopter was sent to land on the lawn at
Bell Labs
to pick up the large-print version so it would get to the CEO in
time...

Steve

----- Original Message -----
From: "Doug McIlroy" <doug at cs.dartmouth.edu>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Fri, 16 Dec 2016 21:09:16 -0500
Subject:[TUHS] How Unix made it to the top

 It has often been told how the Bell Labs law department became the
 first non-research department to use Unix, displacing a newly
acquired
 stand-alone word-processing system that fell short of the
department's
 hopes because it couldn't number the lines on patent applications,
 as USPTO required. When Joe Ossanna heard of this, he told them about
 roff and promised to give it line-numbering capability the next day.
 They tried it and were hooked. Patent secretaries became remote
 members of the fellowship of the Unix lab. In due time the law
 department got its own machine.

 Less well known is how Unix made it into the head office of AT&T. It
 seems that the CEO, Charlie Brown, did not like to be seen wearing
 glasses when he read speeches. Somehow his PR assistant learned of
 the CAT phototypesetter in the Unix lab and asked whether it might be
 possible to use it to produce scripts in large type. Of course it
was.
 As connections to the top never hurt, the CEO's office was welcomed
 as another ouside user. The cost--occasionally having to develop film
 for the final copy of a speech--was not onerous.

 Having teethed on speeches, the head office realized that Unix could
 also be useful for things that didn't need phototypesetting. Other
 documents began to accumulate in their directory. By the time we
became
 aware of it, the hoard came to include minutes of AT&T board
meetings.
 It didn't seem like a very good idea for us to be keeping records
from
 the inner sanctum of the corporation on a computer where most
everybody
 had super-user privileges. A call to the PR guy convinced him of the
 wisdom of keeping such things on their own premises. And so the CEO's
 office bought a Unix system.

 Just as one hears of cars chosen for their cupholders, so were these
 users converted to Unix for trivial reasons: line numbers and vanity.

 Doug

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

From dds at aueb.gr  Tue Dec 20 05:47:28 2016
From: dds at aueb.gr (Diomidis Spinellis)
Date: Mon, 19 Dec 2016 21:47:28 +0200
Subject: [TUHS] nm on Third Edition .o files?
Message-ID: <1773a15e-99fb-ea7e-1d30-1af29e048d90@aueb.gr>

Has anyone got a setup where they can run something like nm(1) on the 
compiled Third Edition Unix C files and send me the output? 
(Alternatively, just send me the .o files, and I'll whip up something to 
read their symbols.)  I tried to compile the source code on a modern 
system by hacking old C to something closer to what GCC will accept, 
with commands such as the following.

cc -E dp.c |
sed 's/=\([&|+-]\)/\1=/g;s/struct[ \t]*(/struct {/' |
gcc -w -x c -

However, I stumbled on the use of structure fields on things that aren't 
structures, e.g. "0177776->int =| 300"


From scj at yaccman.com  Tue Dec 20 06:33:29 2016
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 19 Dec 2016 12:33:29 -0800
Subject: [TUHS] nm on Third Edition .o files?
In-Reply-To: <1773a15e-99fb-ea7e-1d30-1af29e048d90@aueb.gr>
Message-ID: <8321e9e73e4a168ba3da1cf4129fe07728705f8c@webmail.yaccman.com>

That's a construction that's left over from B.  The number on the
left is a PDP-11 address, probably for some kind of control register.

In B, all data was stored in the same sized bucket.  For arrays, the
bucket contained the address of the beginning of the storage allocated
for the array.  For data, the bucket contained the data.  On a
byte-addressed machine, Dennis had to do some real magic to load and
execute these programs (e.g., shift addresses right by a bit).  And,
of course, because there were no types, there was no type checking,
and thus no way to disambiguate structure members, so all names of
structure members had to be unique.  If one structure had a member
"next", no other structure could have a member "next".   (actually,
it could if they were at the same offset in the two structures, but
that was pretty dangerous...).  And early C (originally called nb,
"new B") had to be able to run most B programs by just adding some
declarations...

I can't help you with nm, but it might not tell you much if you had
it...

Steve

----- Original Message -----
From: "Diomidis Spinellis" <dds at aueb.gr>
To:"TUHS main list" <tuhs at minnie.tuhs.org>
Cc:
Sent:Mon, 19 Dec 2016 21:47:28 +0200
Subject:[TUHS] nm on Third Edition .o files?

. . .

 However, I stumbled on the use of structure fields on things that
aren't 
 structures, e.g. "0177776->int =| 300"

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

From jnc at mercury.lcs.mit.edu  Tue Dec 20 06:10:31 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 19 Dec 2016 15:10:31 -0500 (EST)
Subject: [TUHS] Dennis' Draft of the Unix Timesharing System: not so
	draft?
Message-ID: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>

    > From: Warren Toomey

    >  Ritchie, D.M.  The UNIX Time Sharing System.  MM 71-1273-4.
    >  which makes me think that the draft version Doug McIlroy found

Not really a response to your question, but I'd looked at that
'UnixEditionZero' and was very taken with this line, early on:

  "the most important features of UNIX are its simplicity [and] elegance"

and had been meaning for some time to send in a rant.

The variants of Unix done later by others sure fixed that, didn't they? :-(


On a related note, great as my respect is for Ken and Doug for their work on
early Unix (surely the system with the greatest bang/buck ratio ever), I have
to disagree with them about Multics. In particular, if one is going to have a
system as complex as modern Unices have become, one might as well get the
power of Multics for it. Alas, we have the worst of both worlds - the size,
_without_ the power.

(Of course, Multics made some mistakes - primarly in thinking that the future
of computing lay in large, powerful central machines, but other aspects of
the system - such as the single-level store - clearly were the right
direction. And wouldn't it be nice to have AIM boxes to run our browers and
mail-readers in - so much for malware!)

	Noel


From dds at aueb.gr  Tue Dec 20 06:49:20 2016
From: dds at aueb.gr (Diomidis Spinellis)
Date: Mon, 19 Dec 2016 22:49:20 +0200
Subject: [TUHS] nm on Third Edition .o files?
In-Reply-To: <8321e9e73e4a168ba3da1cf4129fe07728705f8c@webmail.yaccman.com>
References: <8321e9e73e4a168ba3da1cf4129fe07728705f8c@webmail.yaccman.com>
Message-ID: <b067aa24-3050-f060-3eca-e263a56d75a7@aueb.gr>

Thank you so much for the explanation.  I was aware that in old C 
structures a->b references were interpreted as *(a + b), but didn't know 
that early C was so close to B that it could run most B programs by just 
adding some declarations.  It seems a logical evolutionary and 
bootstrapping step.

What I'm trying to do is study the dependencies between the kernel's 
files.  Maybe a good approximation would be to consider all functions as 
global and ignore variables.

On 19/12/2016 22:33, Steve Johnson wrote:
> That's a construction that's left over from B.  The number on the left
> is a PDP-11 address, probably for some kind of control register.
>
> In B, all data was stored in the same sized bucket.  For arrays, the
> bucket contained the address of the beginning of the storage allocated
> for the array.  For data, the bucket contained the data.  On a
> byte-addressed machine, Dennis had to do some real magic to load and
> execute these programs (e.g., shift addresses right by a bit).  And, of
> course, because there were no types, there was no type checking, and
> thus no way to disambiguate structure members, so all names of structure
> members had to be unique.  If one structure had a member "next", no
> other structure could have a member "next".   (actually, it could if
> they were at the same offset in the two structures, but that was pretty
> dangerous...).  And early C (originally called nb, "new B") had to be
> able to run most B programs by just adding some declarations...
>
> I can't help you with nm, but it might not tell you much if you had it...
>
> Steve
>
>
>
>     ----- Original Message -----
>     From:
>     "Diomidis Spinellis" <dds at aueb.gr>
>
>     To:
>     "TUHS main list" <tuhs at minnie.tuhs.org>
>     Cc:
>
>     Sent:
>     Mon, 19 Dec 2016 21:47:28 +0200
>     Subject:
>     [TUHS] nm on Third Edition .o files?
>
>     . . .
>
>     However, I stumbled on the use of structure fields on things that
>     aren't
>     structures, e.g. "0177776->int =| 300"
>



From crossd at gmail.com  Tue Dec 20 06:50:50 2016
From: crossd at gmail.com (Dan Cross)
Date: Mon, 19 Dec 2016 15:50:50 -0500
Subject: [TUHS] Dennis' Draft of the Unix Timesharing System: not so
	draft?
In-Reply-To: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>
References: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>
Message-ID: <CAEoi9W7xAPCtYQc1xdw611YO0G2C+ngUxhD=bfqEb8nDw-8sXg@mail.gmail.com>

On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Warren Toomey
>
>     >  Ritchie, D.M.  The UNIX Time Sharing System.  MM 71-1273-4.
>     >  which makes me think that the draft version Doug McIlroy found
>
> Not really a response to your question, but I'd looked at that
> 'UnixEditionZero' and was very taken with this line, early on:
>
>   "the most important features of UNIX are its simplicity [and] elegance"
>
> and had been meaning for some time to send in a rant.
>
> The variants of Unix done later by others sure fixed that, didn't they? :-(
>
>
> On a related note, great as my respect is for Ken and Doug for their work
> on
> early Unix (surely the system with the greatest bang/buck ratio ever), I
> have
> to disagree with them about Multics. In particular, if one is going to
> have a
> system as complex as modern Unices have become, one might as well get the
> power of Multics for it. Alas, we have the worst of both worlds - the size,
> _without_ the power.
>
> (Of course, Multics made some mistakes - primarly in thinking that the
> future
> of computing lay in large, powerful central machines, but other aspects of
> the system - such as the single-level store - clearly were the right
> direction. And wouldn't it be nice to have AIM boxes to run our browers and
> mail-readers in - so much for malware!)


I've been thinking that there's likely a PhD hiding in building a
Multics-style ring-like abstraction from nested virtual machines; the Dune
work at Stanford took a similar tack, if one squints at it a little bit.
Come to think of it, I always kind of wanted to get a PhD. Maybe that'd be
an interesting research idea. Anyone looking for a student? :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161219/6edbcd20/attachment.html>

From clemc at ccc.com  Tue Dec 20 06:59:37 2016
From: clemc at ccc.com (Clem Cole)
Date: Mon, 19 Dec 2016 15:59:37 -0500
Subject: [TUHS] Dennis' Draft of the Unix Timesharing System: not so
	draft?
In-Reply-To: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>
References: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>
Message-ID: <CAC20D2M93zPXUuh0zvQeK7KpPueKBs1j5fWjvKxD=eFZEehieg@mail.gmail.com>

On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
>
> Not really a response to your question, but I'd looked at that
> ​ ​
> 'UnixEditionZero' and was very taken with this line, early on:
>
>   "the most important features of UNIX are its simplicity [and] elegance"
>
> and had been meaning for some time to send in a rant.
>
> The variants of Unix done later by others sure fixed that, didn't they? :-(
>
​One of my favorite comparisons and definitions of "bloat" came when I
discovered years ago that the SVR3 >>boot<< system was larger than the V6
kernel.
​

>
>
> On a related note, great as my respect is for Ken and Doug for their work
> on
> ​ ​
> early Unix (surely the system with the greatest bang/buck ratio ever),

​+1​




> I have
> ​ ​
> to disagree with them about Multics. In particular, if one is going to
> have a
> ​ ​
> system as complex as modern Unices have become, one might as well get the
> ​ ​
> power of Multics for it. Alas, we have the worst of both worlds - the size,
> ​ ​
> _without_ the power.
>
​Mumble -- Other than one important idea (single-level-store as you said),
I'm not so sure.​  I think we ended up with most of what was envisioned,
and some of the SW things (like the "continuation" model and how
dyn-linking ended up working in practice) - I think we are ahead of
Multics.   Winders more than UNIX (IMO) ended up with the complexity and
bloat and most of the bad ideas without the good.  But I think UNIX mostly
was able to stick to what was important (except for the loss of "small is
beautiful" - my rant).  Some of the HW idea moved on - Intel picked up
segments and rings. Look at INTEL*64, we use 2 rings and stopped using
using segments because it too hard to program around them ---  both proved
to be unusable/impractical when they were released.





>
> (Of course, Multics made some mistakes - primarily in thinking that the
> future
> ​ ​
> of computing lay in large, powerful central machines, but other aspects of
> the system - such as the single-level store - clearly were the right
> ​ ​
> direction.

​I agree, and this may yet come back.   It's too bad too many of the
younger engineers have not studied it.  I was recently reviewing some stuff
from a couple of our younger Linux jockeys and they have re-invented
something like it.   I smiled and said -- yes it >>is<< a great idea, but
it has been done.​





> And wouldn't it be nice to have AIM boxes to run our browsers and
> ​ ​
> mail-readers in - so much for malware!)
>
​Indeed.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161219/0a844aac/attachment.html>

From michael at kjorling.se  Tue Dec 20 07:03:23 2016
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Mon, 19 Dec 2016 21:03:23 +0000
Subject: [TUHS] nm on Third Edition .o files?
In-Reply-To: <8321e9e73e4a168ba3da1cf4129fe07728705f8c@webmail.yaccman.com>
References: <1773a15e-99fb-ea7e-1d30-1af29e048d90@aueb.gr>
 <8321e9e73e4a168ba3da1cf4129fe07728705f8c@webmail.yaccman.com>
Message-ID: <20161219210323.GA20777@yeono.kjorling.se>

On 19 Dec 2016 12:33 -0800, from scj at yaccman.com (Steve Johnson):
>> e.g. "0177776->int =| 300"
> 
> The number on the
> left is a PDP-11 address, probably for some kind of control register.

That was my guess, too. I also want to point out that 0177776 ==
0xfffe. IMO this being near an obvious binary boundary would further
support the theory that it's a control register of some kind.

Interesting bit of C history, Steve; thank you for that tidbit.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From crossd at gmail.com  Tue Dec 20 07:11:16 2016
From: crossd at gmail.com (Dan Cross)
Date: Mon, 19 Dec 2016 16:11:16 -0500
Subject: [TUHS] Dennis' Draft of the Unix Timesharing System: not so
	draft?
In-Reply-To: <CAC20D2M93zPXUuh0zvQeK7KpPueKBs1j5fWjvKxD=eFZEehieg@mail.gmail.com>
References: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>
 <CAC20D2M93zPXUuh0zvQeK7KpPueKBs1j5fWjvKxD=eFZEehieg@mail.gmail.com>
Message-ID: <CAEoi9W5n6QAK4NLO0RXnZBsxiduXHbX+CzWgtOJRwHoUF9NyBQ@mail.gmail.com>

On Mon, Dec 19, 2016 at 3:59 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
>
>>
>> Not really a response to your question, but I'd looked at that
>> ​ ​
>> 'UnixEditionZero' and was very taken with this line, early on:
>>
>>   "the most important features of UNIX are its simplicity [and] elegance"
>>
>> and had been meaning for some time to send in a rant.
>>
>> The variants of Unix done later by others sure fixed that, didn't they?
>> :-(
>>
> ​One of my favorite comparisons and definitions of "bloat" came when I
> discovered years ago that the SVR3 >>boot<< system was larger than the V6
> kernel.
>

To be fair, I think some of the complexity is because hardware is more
complex now. It never ceases to amaze me how baroque some of Intel's stuff
has become.

On a related note, great as my respect is for Ken and Doug for their work on
>> ​ ​
>> early Unix (surely the system with the greatest bang/buck ratio ever),
>
> ​+1​
>
>
>
>
>> I have
>> ​ ​
>> to disagree with them about Multics. In particular, if one is going to
>> have a
>> ​ ​
>> system as complex as modern Unices have become, one might as well get the
>> ​ ​
>> power of Multics for it. Alas, we have the worst of both worlds - the
>> size,
>> ​ ​
>> _without_ the power.
>>
> ​Mumble -- Other than one important idea (single-level-store as you
> said), I'm not so sure.​  I think we ended up with most of what was
> envisioned, and some of the SW things (like the "continuation" model and
> how dyn-linking ended up working in practice) - I think we are ahead of
> Multics.   Winders more than UNIX (IMO) ended up with the complexity and
> bloat and most of the bad ideas without the good.  But I think UNIX mostly
> was able to stick to what was important (except for the loss of "small is
> beautiful" - my rant).  Some of the HW idea moved on - Intel picked up
> segments and rings. Look at INTEL*64, we use 2 rings and stopped using
> using segments because it too hard to program around them ---  both
> proved to be unusable/impractical when they were released.
>

Yeah. The only remaining vestige of x86 segmentation seems to be FS and GS,
which are often used for thread local storage.

(Of course, Multics made some mistakes - primarily in thinking that the
>> future
>> ​ ​
>> of computing lay in large, powerful central machines, but other aspects of
>> the system - such as the single-level store - clearly were the right
>> ​ ​
>> direction.
>
> ​I agree, and this may yet come back.   It's too bad too many of the
> younger engineers have not studied it.  I was recently reviewing some stuff
> from a couple of our younger Linux jockeys and they have re-invented
> something like it.   I smiled and said -- yes it >>is<< a great idea, but
> it has been done.​
>
>
>
>
>
>> And wouldn't it be nice to have AIM boxes to run our browsers and
>> ​ ​
>> mail-readers in - so much for malware!)
>>
> ​Indeed.​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161219/e51dac2e/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Dec 20 07:33:08 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 19 Dec 2016 16:33:08 -0500 (EST)
Subject: [TUHS] nm on Third Edition .o files?
Message-ID: <20161219213308.DCEB018C09D@mercury.lcs.mit.edu>

    > From: "Steve Johnson"

    > The number on the left is a PDP-11 address, probably for some kind of
    > control register.

It's the Processor Status Word, which contained the CPU's hardware priority
level, condition codes, etc.

    > That's a construction that's left over from B.

I wonder why it was written as "0177776->integ", rather than "*017776"?
Probably the former allowed the C compiler to work out what size the operand
was. (BTW, 'integ' was declared in a structure declaration as follows:

    struct {
	int	integ;
    };

(Did the code looked at actually say "0177776->int"? The compiler might have
barfed on a reserved keyword being used like that.)

       Noel


From clemc at ccc.com  Tue Dec 20 07:34:14 2016
From: clemc at ccc.com (Clem Cole)
Date: Mon, 19 Dec 2016 16:34:14 -0500
Subject: [TUHS] Dennis' Draft of the Unix Timesharing System: not so
	draft?
In-Reply-To: <CAEoi9W5n6QAK4NLO0RXnZBsxiduXHbX+CzWgtOJRwHoUF9NyBQ@mail.gmail.com>
References: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>
 <CAC20D2M93zPXUuh0zvQeK7KpPueKBs1j5fWjvKxD=eFZEehieg@mail.gmail.com>
 <CAEoi9W5n6QAK4NLO0RXnZBsxiduXHbX+CzWgtOJRwHoUF9NyBQ@mail.gmail.com>
Message-ID: <CAC20D2POnxDuxJr268-_XWPyYp0prHHMn_iXk+puiNJCH4S2Sg@mail.gmail.com>

On Mon, Dec 19, 2016 at 4:11 PM, Dan Cross <crossd at gmail.com> wrote:

> To be fair, I think some of the complexity is because hardware is more
> complex now. It never ceases to amaze me how baroque some of Intel's stuff
> has become.


​May the record show - the boot was for the WE32100 - AT&T's "UNIX"
chip-set.  My copy of the AT&T book on same show a publication date of
January 1985.

Clem

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

From dot at dotat.at  Tue Dec 20 22:24:22 2016
From: dot at dotat.at (Tony Finch)
Date: Tue, 20 Dec 2016 12:24:22 +0000
Subject: [TUHS] nm on Third Edition .o files?
In-Reply-To: <20161219213308.DCEB018C09D@mercury.lcs.mit.edu>
References: <20161219213308.DCEB018C09D@mercury.lcs.mit.edu>
Message-ID: <alpine.DEB.2.11.1612201221110.14104@grey.csi.cam.ac.uk>

Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

> I wonder why it was written as "0177776->integ", rather than "*017776"?
> Probably the former allowed the C compiler to work out what size the
> operand was.

I guess the alternatives would be casting (when did C get its cast
operator?) or assigning the number to a pointer variable.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire: Southerly veering southwesterly later, 7 to severe gale
9, occasionally storm 10 in north. Very rough or high. Occasional rain. Good,
occasionally poor.


From jnc at mercury.lcs.mit.edu  Tue Dec 20 23:05:53 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 20 Dec 2016 08:05:53 -0500 (EST)
Subject: [TUHS] nm on Third Edition .o files?'
Message-ID: <20161220130553.15FDC18C098@mercury.lcs.mit.edu>

    > From: Tony Finch

    > when did C get its cast operator?

Well after that piece of code was written! :-)

I don't recall exactly off the top of my head, but I recall 2-3 notes to
users about the evolution of C post 'vanilla' V6; I think a lot of it was
related to work being done on typetting stuff, hence the moniker
'phototypsetter compiler' which was applied to that 'improved' C. 

One of the notes is fairly common, but another I have only in hardcopy
(although I scanned it at one point).

I'll try and turn all of them, along with some notes I made about the
differences between 'vanilla' V6 C and 'phototypsetter C' (which a lot of the
later V6 users started with - I certainly did), into an article on the
Computer History wiki on the early evolution of C.

	Noel


From jnc at mercury.lcs.mit.edu  Wed Dec 21 00:15:08 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 20 Dec 2016 09:15:08 -0500 (EST)
Subject: [TUHS] nm on Third Edition .o files?'
Message-ID: <20161220141508.6769318C083@mercury.lcs.mit.edu>

PS:

    > I recall 2-3 notes to users about the evolution of C post 'vanilla' V6
    > ...
    > One of the notes is fairly common, but another I have only in hardcopy
    > (although I scanned it at one point).

More here:

  http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html

If anyone knows of any other documentation of C evolution, I'd be interested
in hearing about it for the Computer History wiki page.

	Noel



From clemc at ccc.com  Wed Dec 21 01:49:30 2016
From: clemc at ccc.com (Clem Cole)
Date: Tue, 20 Dec 2016 10:49:30 -0500
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <20161220130553.15FDC18C098@mercury.lcs.mit.edu>
References: <20161220130553.15FDC18C098@mercury.lcs.mit.edu>
Message-ID: <CAC20D2PY3iH0ftkRsSeT4He_ks+sApEbftRbAZZu-yHWn_1M_g@mail.gmail.com>

On Tue, Dec 20, 2016 at 8:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I think a lot of it was
> ​ ​
> related to work being done on typetting stuff, hence the moniker
> 'phototypsetter compiler' which was applied to that 'improved' C.
>

​Need to ask someone like Doug or Steve - but I thought/IIRC the moniker
was because it was the compiler an end user got when you get the typesetter
code.   ​That said, you have to be right in that it was the typesetter work
that seems to be the forcing function.  As for dating it, it has to have
predated the "white book" because we had the typesetter compiler at CMU
before Ted Kowalski showed up for his OYOC year which I'm pretty sure was
'76.

He had brought UNIX/TS with him and a xerographic copy of the white book
proofs.  We had been running 5th and then 6th edition in '75 - when I
started hacking.   Ted updated us to his system and that spread everywhere
but the two CS IUS and SUS (image and speech understanding systems).

I believe that I can date this because IUS and SUS had a special CMU 11/40e
microcode (csav and cret instructions) and hacked typesetter C compiler,
which was different from what Ted was using (which was even later).   So
these systems could not use Ted's new kernel until someone in CS brought
the two compilers in sync (Dan Klein maybe??) - I remember is was a pain in
the tuckus because you could not take a binary from the CS systems and run
them on the EE Dept systems.  But the CS system had more disk than we did,
so they had all of the sources from outside places like MIT, UCB, et al on
line.   We I was grabbing tools from those systems to update the EE systems
and pushing what we wrote back to them.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/383818e0/attachment.html>

From ron at ronnatalie.com  Wed Dec 21 02:04:13 2016
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 20 Dec 2016 11:04:13 -0500
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <CAC20D2PY3iH0ftkRsSeT4He_ks+sApEbftRbAZZu-yHWn_1M_g@mail.gmail.com>
References: <20161220130553.15FDC18C098@mercury.lcs.mit.edu>
 <CAC20D2PY3iH0ftkRsSeT4He_ks+sApEbftRbAZZu-yHWn_1M_g@mail.gmail.com>
Message-ID: <006701d25ada$b64262a0$22c727e0$@ronnatalie.com>

If I recall, we got the typesetter (troff) tape in between V6 and the later (I think we got PWB next then V7).    It had a compiler on it.    I presume that it was needed to compile troff, but most of us installed it as a more up to date C compiler.    If I recall properly (and boy my mind is hazy on this), is that it supported the “new” += syntax while warning that =+ was deprecated.   

 

At some point, the structure elements being made unique to the structure they were defined in, and the ability to assign/pass structures got supported, though I thought that was the compiler that came with V7.

I’m still annoyed they didn’t fix arrays when they fixed structs.

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

From lm at mcvoy.com  Wed Dec 21 02:09:41 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 20 Dec 2016 08:09:41 -0800
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <006701d25ada$b64262a0$22c727e0$@ronnatalie.com>
References: <20161220130553.15FDC18C098@mercury.lcs.mit.edu>
 <CAC20D2PY3iH0ftkRsSeT4He_ks+sApEbftRbAZZu-yHWn_1M_g@mail.gmail.com>
 <006701d25ada$b64262a0$22c727e0$@ronnatalie.com>
Message-ID: <20161220160941.GS11813@mcvoy.com>

On Tue, Dec 20, 2016 at 11:04:13AM -0500, Ron Natalie wrote:
> At some point, the structure elements being made unique to the structure they were defined in

I, for one, would have been really OK if that had been optional.
If it is what I am thinking about, that all struct elements were in the
same namespace, forcing names like "st_size" instead of just "size",
I love that.  I get that it doesn't scale but man, so nice when reading
code to know that s.st_size is a stat structure.


From clemc at ccc.com  Wed Dec 21 02:21:41 2016
From: clemc at ccc.com (Clem Cole)
Date: Tue, 20 Dec 2016 11:21:41 -0500
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <20161220160941.GS11813@mcvoy.com>
References: <20161220130553.15FDC18C098@mercury.lcs.mit.edu>
 <CAC20D2PY3iH0ftkRsSeT4He_ks+sApEbftRbAZZu-yHWn_1M_g@mail.gmail.com>
 <006701d25ada$b64262a0$22c727e0$@ronnatalie.com>
 <20161220160941.GS11813@mcvoy.com>
Message-ID: <CAC20D2NwBn59HS6ne13OtcM9XPf6sM148+MSN8Kvca1F=_Dcwg@mail.gmail.com>

On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm at mcvoy.com> wrote:

> I get that it doesn't scale but man, so nice when reading
> code to know that s.st_size is a stat structure.
>

​Amen!!!​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/8fd7815f/attachment.html>

From ron at ronnatalie.com  Wed Dec 21 02:23:34 2016
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 20 Dec 2016 11:23:34 -0500
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <CAC20D2NwBn59HS6ne13OtcM9XPf6sM148+MSN8Kvca1F=_Dcwg@mail.gmail.com>
References: <20161220130553.15FDC18C098@mercury.lcs.mit.edu>
 <CAC20D2PY3iH0ftkRsSeT4He_ks+sApEbftRbAZZu-yHWn_1M_g@mail.gmail.com>
 <006701d25ada$b64262a0$22c727e0$@ronnatalie.com>
 <20161220160941.GS11813@mcvoy.com>
 <CAC20D2NwBn59HS6ne13OtcM9XPf6sM148+MSN8Kvca1F=_Dcwg@mail.gmail.com>
Message-ID: <007e01d25add$6a18ad00$3e4a0700$@ronnatalie.com>

And nothing precludes you from tagging the structure elements.    We continued to do that long after the compiler was “fixed.”



 

From: Clem Cole [mailto:clemc at ccc.com] 
Sent: Tuesday, December 20, 2016 11:22 AM
To: Larry McVoy
Cc: Ron Natalie; Noel Chiappa; TUHS main list
Subject: Re: [TUHS] nm on Third Edition .o files?'

 

 

On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm at mcvoy.com> wrote:

I get that it doesn't scale but man, so nice when reading
code to know that s.st_size is a stat structure.

 

​Amen!!!​

 

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

From lm at mcvoy.com  Wed Dec 21 02:26:17 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 20 Dec 2016 08:26:17 -0800
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <007e01d25add$6a18ad00$3e4a0700$@ronnatalie.com>
References: <20161220130553.15FDC18C098@mercury.lcs.mit.edu>
 <CAC20D2PY3iH0ftkRsSeT4He_ks+sApEbftRbAZZu-yHWn_1M_g@mail.gmail.com>
 <006701d25ada$b64262a0$22c727e0$@ronnatalie.com>
 <20161220160941.GS11813@mcvoy.com>
 <CAC20D2NwBn59HS6ne13OtcM9XPf6sM148+MSN8Kvca1F=_Dcwg@mail.gmail.com>
 <007e01d25add$6a18ad00$3e4a0700$@ronnatalie.com>
Message-ID: <20161220162617.GT11813@mcvoy.com>

On Tue, Dec 20, 2016 at 11:23:34AM -0500, Ron Natalie wrote:
> And nothing precludes you from tagging the structure elements.
> We continued to do that long after the compiler was ???fixed.???

Oh, agreed.  The aware people do that.  I just wish it was the default
that it enforced one namespace.  For all i know gcc has this and I 
haven't noticed.


From jnc at mercury.lcs.mit.edu  Wed Dec 21 04:44:59 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 20 Dec 2016 13:44:59 -0500 (EST)
Subject: [TUHS] nm on Third Edition .o files?'
Message-ID: <20161220184459.7CE1B18C09E@mercury.lcs.mit.edu>

    > From: "Ron Natalie"

    > At some point .. and the ability to assign/pass structures got
    > supported, though I thought that was the compiler that came with V7.

That is my vague recollection too.

    > I'm still annoyed they didn't fix arrays when they fixed structs.

Which aspect? The ability to assign/pass/return arrays, or the funky way that
array naming worked (I'm trying to remember the details, I think it was
something to do with 'arrays' passed as arguments - it was actually a pointer
that was passed, but the declaration didn't have to say 'pointer').

	Noel


From jnc at mercury.lcs.mit.edu  Wed Dec 21 06:01:41 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 20 Dec 2016 15:01:41 -0500 (EST)
Subject: [TUHS] nm on Third Edition .o files?'
Message-ID: <20161220200141.7010118C09A@mercury.lcs.mit.edu>

    > More here:
    >   http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html

Which sez:

  There is a second document, untitled, no date, which I have not been able to
  locate online at all.
  ..
  From the content, it seems to be from shortly after the previous one, so say,
  circa 1977.

I poked around in a dump of the CSR Unix which I now have available to me, and
found a copy of it. I just checked the Internet (using the canonical search
engine) for various phrases from it, but I still could not turn it up. So,
here it is in machine-readable form:

  http://ana-3.lcs.mit.edu/~jnc/history/unix/CChanges.txt

Hope this is some use to someone... :-)

	Noel


From scj at yaccman.com  Wed Dec 21 06:23:44 2016
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 20 Dec 2016 12:23:44 -0800
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <CAC20D2NwBn59HS6ne13OtcM9XPf6sM148+MSN8Kvca1F=_Dcwg@mail.gmail.com>
Message-ID: <cdb1b6d289efeafdc8bce509b3e7996e217f8f23@webmail.yaccman.com>

I had a funny and somewhat embarrassing experience around the whole
issue of structure name spaces.  When types were spreading through C,
we had a lot of discussion about whether we should require all
programs to call structures with a structure pointer (which would
allow a separate name space for structure members of each
structure).   We all thought it was a good idea, but the problem was
there was a lot of code out there that didn't conform, including a lot
of OS code.  As we started to port Unix to the Interdata (a 32-bit
machine), the situation became critical.  So I took a deep breath and
implemented the following: the compiler would use the old style
structure rules until I saw a "new style" structure reference in the
code.  At that point I would start to enforce the new rules, which
involved translating the symbol table, and starting to complain if the
types didn't match.   This was a very ugly hack, and I had inserted
many firewalls and assertions to check that the data structures were
correct after this translation.

Now, a word about error messages.  The PDP-11 didn't have much
memory.  But at the same time it didn't have much of a debugger in
those days.  So the main aim was to identify what went wrong in a
small number of characters so you could put in print statements and
run it again.  This meant that the message produced had to be short
but also unique.  I was producing error checks at a great rate in
this code and running out of synonyms for "corrupted" in my messages.

I "published" the code, and everything seemed to be working for a
couple of days.  Then Ken, who was working on the Interdata file
system, tried to compile a structure declaration that contained a
sizeof of a structure that was recursively declared inside of the
sizeof, and my code gave up the ghost.  Ken came into my office with
a strange look on his face and asked "What is a gummy structure?"

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Larry McVoy" <lm at mcvoy.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>, "Noel Chiappa"
<jnc at mercury.lcs.mit.edu>
Sent:
Tue, 20 Dec 2016 11:21:41 -0500
Subject:
Re: [TUHS] nm on Third Edition .o files?'

On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm at mcvoy.com [1]>
 wrote:

I get that it doesn't scale but man, so nice when reading
 code to know that s.st_size is a stat structure.

​Amen!!!​

 

Links:
------
[1] mailto:lm at mcvoy.com

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

From clemc at ccc.com  Wed Dec 21 06:30:46 2016
From: clemc at ccc.com (Clem Cole)
Date: Tue, 20 Dec 2016 15:30:46 -0500
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <cdb1b6d289efeafdc8bce509b3e7996e217f8f23@webmail.yaccman.com>
References: <CAC20D2NwBn59HS6ne13OtcM9XPf6sM148+MSN8Kvca1F=_Dcwg@mail.gmail.com>
 <cdb1b6d289efeafdc8bce509b3e7996e217f8f23@webmail.yaccman.com>
Message-ID: <CAC20D2ML6-voB_mBZFsk=+Ym_Lsv-Lnbx=Q3WUiNUUSVR-PnFQ@mail.gmail.com>

touchė

On Tue, Dec 20, 2016 at 3:23 PM, Steve Johnson <scj at yaccman.com> wrote:

> I had a funny and somewhat embarrassing experience around the whole issue
> of structure name spaces.  When types were spreading through C, we had a
> lot of discussion about whether we should require all programs to call
> structures with a structure pointer (which would allow a separate name
> space for structure members of each structure).   We all thought it was a
> good idea, but the problem was there was a lot of code out there that
> didn't conform, including a lot of OS code.  As we started to port Unix to
> the Interdata (a 32-bit machine), the situation became critical.  So I took
> a deep breath and implemented the following: the compiler would use the old
> style structure rules until I saw a "new style" structure reference in the
> code.  At that point I would start to enforce the new rules, which involved
> translating the symbol table, and starting to complain if the types didn't
> match.   This was a very ugly hack, and I had inserted many firewalls and
> assertions to check that the data structures were correct after this
> translation.
>
> Now, a word about error messages.  The PDP-11 didn't have much memory.
> But at the same time it didn't have much of a debugger in those days.  So
> the main aim was to identify what went wrong in a small number of
> characters so you could put in print statements and run it again.  This
> meant that the message produced had to be short but also unique.  I was
> producing error checks at a great rate in this code and running out of
> synonyms for "corrupted" in my messages.
>
> I "published" the code, and everything seemed to be working for a couple
> of days.  Then Ken, who was working on the Interdata file system, tried to
> compile a structure declaration that contained a sizeof of a structure that
> was recursively declared inside of the sizeof, and my code gave up the
> ghost.  Ken came into my office with a strange look on his face and asked
> "What is a gummy structure?"
>
>
> ----- Original Message -----
> From:
> "Clem Cole" <clemc at ccc.com>
>
> To:
> "Larry McVoy" <lm at mcvoy.com>
> Cc:
> "TUHS main list" <tuhs at minnie.tuhs.org>, "Noel Chiappa" <
> jnc at mercury.lcs.mit.edu>
> Sent:
> Tue, 20 Dec 2016 11:21:41 -0500
> Subject:
> Re: [TUHS] nm on Third Edition .o files?'
>
>
>
> On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> I get that it doesn't scale but man, so nice when reading
>> code to know that s.st_size is a stat structure.
>>
>
> ​Amen!!!​
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/b941b212/attachment.html>

From ron at ronnatalie.com  Wed Dec 21 09:40:29 2016
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 20 Dec 2016 18:40:29 -0500
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <20161220184459.7CE1B18C09E@mercury.lcs.mit.edu>
References: <20161220184459.7CE1B18C09E@mercury.lcs.mit.edu>
Message-ID: <00cd01d25b1a$733cafc0$59b60f40$@ronnatalie.com>

I was referring to the fact that arrays sometimes are types and sometimes
dissolve into pointers to their first elements.    It's a kludgy concept.
Assignment of array objects or passing/returning them should have been
really implemented at the same time sturct passing/return/assignment was
done.
The fact that a function that appears to pass/take array arguments magically
converts to pointers is kludgy.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa
Sent: Tuesday, December 20, 2016 1:45 PM
To: tuhs at minnie.tuhs.org
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: [TUHS] nm on Third Edition .o files?'

    > From: "Ron Natalie"

    > At some point .. and the ability to assign/pass structures got
    > supported, though I thought that was the compiler that came with V7.

That is my vague recollection too.

    > I'm still annoyed they didn't fix arrays when they fixed structs.

Which aspect? The ability to assign/pass/return arrays, or the funky way
that array naming worked (I'm trying to remember the details, I think it was
something to do with 'arrays' passed as arguments - it was actually a
pointer that was passed, but the declaration didn't have to say 'pointer').

	Noel



From doug at cs.dartmouth.edu  Wed Dec 21 10:26:26 2016
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 20 Dec 2016 19:26:26 -0500
Subject: [TUHS]  phototypesetter C (was nm on Third Edition .o files)
Message-ID: <201612210026.uBL0QQAf105735@tahoe.cs.Dartmouth.EDU>

Amusing, I don't think I ever heard the appellation "phototypesetter C"
before. Certainly C and the phottypesetter developed independently, though
in the same room. But the explanation that they got linked by appearing
in the same tape release makes perfect sense. Thanks for the tidbit.

Doug


From wkt at tuhs.org  Wed Dec 21 19:03:27 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 21 Dec 2016 19:03:27 +1000
Subject: [TUHS] 14 new TUHS members
Message-ID: <20161221090327.GA21190@minnie.tuhs.org>

All, I've just got back from a few days away to find 14 new subscription
requests to the TUHS mailing list. Welcome aboard to you all.

Normally I only get one request a month, so I have some concerns about
the legitimacy of all these requests, so accept my apologies in advance
if there is any off-topic e-mails in the next few days.

P.S The mail while I was away was very interesting. Noel, you might
also be interested in the B interpreter and Robert Swierczick's B
compiler the PDP-7 Unix. The original B compiler doesn't exist, so
Robert took the 11/20 C compiler and "undid" the code that does types
so that it "became" a B compiler.

https://github.com/DoctorWkt/pdp7-unix/tree/master/src/other

Cheers all
	Warren


From dot at dotat.at  Wed Dec 21 20:34:27 2016
From: dot at dotat.at (Tony Finch)
Date: Wed, 21 Dec 2016 10:34:27 +0000
Subject: [TUHS] nm on Third Edition .o files?'
In-Reply-To: <20161220200141.7010118C09A@mercury.lcs.mit.edu>
References: <20161220200141.7010118C09A@mercury.lcs.mit.edu>
Message-ID: <alpine.DEB.2.11.1612211032570.7102@grey.csi.cam.ac.uk>

Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
>   http://ana-3.lcs.mit.edu/~jnc/history/unix/CChanges.txt

This is great, thanks! It's interesting how much of C was still quite new
when K&R1 was written.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Rockall, Malin, Hebrides, Bailey, Fair Isle, Faeroes: West or southwest 7 to
severe gale 9. High, occasionally very high except in Fair Isle. Squally
wintry showers, occasionally thundery. Good, occasionally poor.


From dds at aueb.gr  Wed Dec 21 21:15:59 2016
From: dds at aueb.gr (Diomidis Spinellis)
Date: Wed, 21 Dec 2016 13:15:59 +0200
Subject: [TUHS] 14 new TUHS members
In-Reply-To: <20161221090327.GA21190@minnie.tuhs.org>
References: <20161221090327.GA21190@minnie.tuhs.org>
Message-ID: <bda845ec-ab7c-2a0e-7c21-2af03bdec157@aueb.gr>

I occasionally tweet pointers to archived messages when I see a gem in 
our list that merits wider dissemination.  I did so this week: "The 
reasons AT&T's CEO and legal started using Unix are not the ones you'd 
expect. http://minnie.tuhs.org/pipermail/tuhs/2016-December/007519.html"

https://twitter.com/CoolSWEng/status/810498608718036992

If you'd prefer to keep this list less public I can avoid such posts.

Diomidis

On 21/12/2016 11:03, Warren Toomey wrote:
> All, I've just got back from a few days away to find 14 new subscription
> requests to the TUHS mailing list. Welcome aboard to you all.
>
> Normally I only get one request a month, so I have some concerns about
> the legitimacy of all these requests, so accept my apologies in advance
> if there is any off-topic e-mails in the next few days.
>
> P.S The mail while I was away was very interesting. Noel, you might
> also be interested in the B interpreter and Robert Swierczick's B
> compiler the PDP-7 Unix. The original B compiler doesn't exist, so
> Robert took the 11/20 C compiler and "undid" the code that does types
> so that it "became" a B compiler.
>
> https://github.com/DoctorWkt/pdp7-unix/tree/master/src/other
>
> Cheers all
> 	Warren
>



From rootkea at gmail.com  Wed Dec 21 23:16:02 2016
From: rootkea at gmail.com (Avinash Sonawane)
Date: Wed, 21 Dec 2016 18:46:02 +0530
Subject: [TUHS] 14 new TUHS members
In-Reply-To: <20161221090327.GA21190@minnie.tuhs.org>
References: <20161221090327.GA21190@minnie.tuhs.org>
Message-ID: <CAJ9BSW8KkBdQ6K6A7zSzPo9SktZe5ri0iRK82RK5CGbbo=EJ-Q@mail.gmail.com>

On Wed, Dec 21, 2016 at 2:33 PM, Warren Toomey <wkt at tuhs.org> wrote:
> All, I've just got back from a few days away to find 14 new subscription
> requests to the TUHS mailing list. Welcome aboard to you all.
>
> Normally I only get one request a month

May be it's because "How Unix made it to the top"[0] made it to the
front page of Hacker News[1], a forum frequented by geeks.

[0] http://minnie.tuhs.org/pipermail/tuhs/2016-December/007519.html
[1] https://news.ycombinator.com/item?id=13204054

-- 
Avinash Sonawane (rootKea)
PICT, Pune
https://rootkea.wordpress.com


From kayparker at mailite.com  Thu Dec 22 00:41:01 2016
From: kayparker at mailite.com (=?utf-8?Q?Kay=20Parker=20=09=20?=)
Date: Wed, 21 Dec 2016 06:41:01 -0800
Subject: [TUHS] 14 new TUHS members
In-Reply-To: <CAJ9BSW8KkBdQ6K6A7zSzPo9SktZe5ri0iRK82RK5CGbbo=EJ-Q@mail.gmail.com>
References: <20161221090327.GA21190@minnie.tuhs.org>
 <CAJ9BSW8KkBdQ6K6A7zSzPo9SktZe5ri0iRK82RK5CGbbo=EJ-Q@mail.gmail.com>
Message-ID: <1482331261.612450.825968641.1F9509A8@webmail.messagingengine.com>

Hello,

I'm researching Computer history, especially Unix. I noticed the
mentioned article reading a mail from this great list.

On Wed, Dec 21, 2016, at 05:16 AM, Avinash Sonawane wrote:
> On Wed, Dec 21, 2016 at 2:33 PM, Warren Toomey <wkt at tuhs.org> wrote:
> > All, I've just got back from a few days away to find 14 new subscription
> > requests to the TUHS mailing list. Welcome aboard to you all.
> >
> > Normally I only get one request a month
> 
> May be it's because "How Unix made it to the top"[0] made it to the
> front page of Hacker News[1], a forum frequented by geeks.
> 
> [0] http://minnie.tuhs.org/pipermail/tuhs/2016-December/007519.html
> [1] https://news.ycombinator.com/item?id=13204054
> 
> -- 
> Avinash Sonawane (rootKea)
> PICT, Pune
> https://rootkea.wordpress.com


-- 
  Kay Parker       
  kayparker at mailite.com

-- 
http://www.fastmail.com - The professional email service



From edouardklein at gmail.com  Thu Dec 22 01:04:09 2016
From: edouardklein at gmail.com (Edouard KLEIN)
Date: Wed, 21 Dec 2016 15:04:09 +0000
Subject: [TUHS] 14 new TUHS members
In-Reply-To: <1482331261.612450.825968641.1F9509A8@webmail.messagingengine.com>
References: <20161221090327.GA21190@minnie.tuhs.org>
 <CAJ9BSW8KkBdQ6K6A7zSzPo9SktZe5ri0iRK82RK5CGbbo=EJ-Q@mail.gmail.com>
 <1482331261.612450.825968641.1F9509A8@webmail.messagingengine.com>
Message-ID: <CANiMCTMdyJfcTJC6KzAxtqWMhMAnQaOyyt=0v8baDrOzjzS7LQ@mail.gmail.com>

I too got there from Hacker News.

I like to read stories from the Unix Lore, and discover the history of the
tools that are everywhere in my computing environment at home and at work.
I fear I'll have nothing to contribute, as I'm younger than System V, but
I'll read the list with interest :)

On Wed, 21 Dec 2016 at 15:41 Kay Parker <kayparker at mailite.com> wrote:

> Hello,
>
> I'm researching Computer history, especially Unix. I noticed the
> mentioned article reading a mail from this great list.
>
> On Wed, Dec 21, 2016, at 05:16 AM, Avinash Sonawane wrote:
> > On Wed, Dec 21, 2016 at 2:33 PM, Warren Toomey <wkt at tuhs.org> wrote:
> > > All, I've just got back from a few days away to find 14 new
> subscription
> > > requests to the TUHS mailing list. Welcome aboard to you all.
> > >
> > > Normally I only get one request a month
> >
> > May be it's because "How Unix made it to the top"[0] made it to the
> > front page of Hacker News[1], a forum frequented by geeks.
> >
> > [0] http://minnie.tuhs.org/pipermail/tuhs/2016-December/007519.html
> > [1] https://news.ycombinator.com/item?id=13204054
> >
> > --
> > Avinash Sonawane (rootKea)
> > PICT, Pune
> > https://rootkea.wordpress.com
>
>
> --
>   Kay Parker
>   kayparker at mailite.com
>
> --
> http://www.fastmail.com - The professional email service
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161221/7e2e094e/attachment.html>

From lm at mcvoy.com  Thu Dec 22 01:31:46 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 21 Dec 2016 07:31:46 -0800
Subject: [TUHS] 14 new TUHS members
In-Reply-To: <CANiMCTMdyJfcTJC6KzAxtqWMhMAnQaOyyt=0v8baDrOzjzS7LQ@mail.gmail.com>
References: <20161221090327.GA21190@minnie.tuhs.org>
 <CAJ9BSW8KkBdQ6K6A7zSzPo9SktZe5ri0iRK82RK5CGbbo=EJ-Q@mail.gmail.com>
 <1482331261.612450.825968641.1F9509A8@webmail.messagingengine.com>
 <CANiMCTMdyJfcTJC6KzAxtqWMhMAnQaOyyt=0v8baDrOzjzS7LQ@mail.gmail.com>
Message-ID: <20161221153146.GC15531@mcvoy.com>

You newcomers are in for a treat.  A bunch of the original Unix people
are here.  All sorts of gems get teased out.

I get that too "young" feeling, I was just a little too young to make 
it to Bell Labs.  Not sure they would have let me in but if I had
been younger I would have fought hard to get in, those guys were my
inspiration.

On Wed, Dec 21, 2016 at 03:04:09PM +0000, Edouard KLEIN wrote:
> I too got there from Hacker News.
> 
> I like to read stories from the Unix Lore, and discover the history of the
> tools that are everywhere in my computing environment at home and at work.
> I fear I'll have nothing to contribute, as I'm younger than System V, but
> I'll read the list with interest :)
> 
> On Wed, 21 Dec 2016 at 15:41 Kay Parker <kayparker at mailite.com> wrote:
> 
> > Hello,
> >
> > I'm researching Computer history, especially Unix. I noticed the
> > mentioned article reading a mail from this great list.
> >
> > On Wed, Dec 21, 2016, at 05:16 AM, Avinash Sonawane wrote:
> > > On Wed, Dec 21, 2016 at 2:33 PM, Warren Toomey <wkt at tuhs.org> wrote:
> > > > All, I've just got back from a few days away to find 14 new
> > subscription
> > > > requests to the TUHS mailing list. Welcome aboard to you all.
> > > >
> > > > Normally I only get one request a month
> > >
> > > May be it's because "How Unix made it to the top"[0] made it to the
> > > front page of Hacker News[1], a forum frequented by geeks.
> > >
> > > [0] http://minnie.tuhs.org/pipermail/tuhs/2016-December/007519.html
> > > [1] https://news.ycombinator.com/item?id=13204054
> > >
> > > --
> > > Avinash Sonawane (rootKea)
> > > PICT, Pune
> > > https://rootkea.wordpress.com
> >
> >
> > --
> >   Kay Parker
> >   kayparker at mailite.com
> >
> > --
> > http://www.fastmail.com - The professional email service
> >
> >

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


From dave at horsfall.org  Thu Dec 22 06:31:43 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 22 Dec 2016 07:31:43 +1100 (EST)
Subject: [TUHS] Happy birthday, Tommy Flowers!
Message-ID: <alpine.BSF.2.20.1612220724390.43538@aneurin.horsfall.org>

Tommy Flowers MBE was born on this day in 1905; amongst other things he 
designed Colossus, the world's first programmable electronic computer, 
which was used to break the German Lorenz cipher (not Enigma, as some 
think).

Relevance to Unix?  Well, without the world's first usable computer we 
would not have the world's first usable OS, and M$ would probably reign 
supreme by now...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From michael at kjorling.se  Thu Dec 22 06:37:20 2016
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 21 Dec 2016 20:37:20 +0000
Subject: [TUHS] Happy birthday, Tommy Flowers!
In-Reply-To: <alpine.BSF.2.20.1612220724390.43538@aneurin.horsfall.org>
References: <alpine.BSF.2.20.1612220724390.43538@aneurin.horsfall.org>
Message-ID: <20161221203720.GH20777@yeono.kjorling.se>

On 22 Dec 2016 07:31 +1100, from dave at horsfall.org (Dave Horsfall):
> Relevance to Unix?  Well, without the world's first usable computer we 
> would not have the world's first usable OS, and M$ would probably reign 
> supreme by now...

Just imagine how differently things would have turned out had a major
software company, in the dawn of the 1980s, decided to seriously
pursue its UNIX variant rather than a clone of CP/M as it turned out.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From usotsuki at buric.co  Thu Dec 22 07:54:13 2016
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 21 Dec 2016 16:54:13 -0500 (EST)
Subject: [TUHS] Happy birthday, Tommy Flowers!
In-Reply-To: <20161221203720.GH20777@yeono.kjorling.se>
References: <alpine.BSF.2.20.1612220724390.43538@aneurin.horsfall.org>
 <20161221203720.GH20777@yeono.kjorling.se>
Message-ID: <alpine.BSF.2.02.1612211652140.24979@frieza.hoshinet.org>

On Wed, 21 Dec 2016, Michael Kjörling wrote:

> On 22 Dec 2016 07:31 +1100, from dave at horsfall.org (Dave Horsfall):
>> Relevance to Unix?  Well, without the world's first usable computer we
>> would not have the world's first usable OS, and M$ would probably reign
>> supreme by now...
>
> Just imagine how differently things would have turned out had a major
> software company, in the dawn of the 1980s, decided to seriously
> pursue its UNIX variant rather than a clone of CP/M as it turned out.

It did get a lot better after they added a Unix-like file API to v2.0, 
though. ;)

-uso.

From pnr at planet.nl  Thu Dec 22 08:06:28 2016
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 21 Dec 2016 23:06:28 +0100
Subject: [TUHS] Happy birthday, Tommy Flowers!
In-Reply-To: <20161221203720.GH20777@yeono.kjorling.se>
References: <alpine.BSF.2.20.1612220724390.43538@aneurin.horsfall.org>
 <20161221203720.GH20777@yeono.kjorling.se>
Message-ID: <36B2BD73-710B-4F00-BB80-40A8F8358164@planet.nl>


On 21 Dec 2016, at 21:37 , Michael Kjörling wrote:

> Just imagine how differently things would have turned out had a major
> software company, in the dawn of the 1980s, decided to seriously
> pursue its UNIX variant rather than a clone of CP/M as it turned out.

That could refer to either IBM or MS. At the time IBM perhaps wasn't a software company and MS wasn't major.

In any case, I don't think it would have made much difference:

[1] Even early Unix did not work well without a hard disk and/or ample RAM. Two years ago I ported LSX and whilst it is amazing to see a minimal Unix work with only 48KB and a floppy disk, it is much less usable than CP/M on 8088 class hardware. The constant swapping to floppy disk kills performance and the 3 FIFO process design quickly becomes a nuisance to the Unix experience.

[2] Hard disks and 256KB RAM did not become common on PC's until perhaps 1985, when DOS had already entrenched itself. Also, by 1985 almost half of all computers in the world were PC's.

[3] By 1980 CP/M had already an eco system with some 8,000 applications around it, including full screen word processors, spreadsheets, etc. CBASIC and dBASE had already spawned a cottage industry for line-of-business apps. These could be ported with modest effort to DOS. It would have taken years for a similar Unix eco system to develop.

In short, my guess would be that if IBM and MS would have pursued PC/IX and Xenix for the PC in the dawn of the 1980s, Gary Kildall would have become a billionaire pursuing CP/M-86 for the PC.

Paul




From wes.parish at paradise.net.nz  Thu Dec 22 10:12:00 2016
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Thu, 22 Dec 2016 13:12:00 +1300 (NZDT)
Subject: [TUHS] 14 new TUHS members
In-Reply-To: <CANiMCTMdyJfcTJC6KzAxtqWMhMAnQaOyyt=0v8baDrOzjzS7LQ@mail.gmail.com>
References: <20161221090327.GA21190@minnie.tuhs.org>
 <CAJ9BSW8KkBdQ6K6A7zSzPo9SktZe5ri0iRK82RK5CGbbo=EJ-Q@mail.gmail.com>
 <1482331261.612450.825968641.1F9509A8@webmail.messagingengine.com>
 <CANiMCTMdyJfcTJC6KzAxtqWMhMAnQaOyyt=0v8baDrOzjzS7LQ@mail.gmail.com>
Message-ID: <1482365520.585b1a50a4889@www.paradise.net.nz>

Well, don't feel yourself put out by your relative youth. I discovered Unix about the time I (seriously) 
discovered computers in 1990. I'd read up what little info I could get on computers while I was at High 
School in Canberra  - they actually had (general theory) books on computers, but then, Canberra hosts 
an observatory and a couple of high-quality universities, so it stands to reason ...

I read (in Bits and Bytes, an NZ computer mag) about Minix and Coherent, and their multitasking and 
whatnot, and thought, now I've got started in computers, let's get serious.(I'd got started on Macintosh 
then tried my hand at MS DOS)

Unix is to computer geeks as Bach (or Coltrane) is to music geeks. Discussion and arguments aplenty, 
but nobody's denying the importance.

Welcome aboard.

Wesley Parish

Quoting Edouard KLEIN <edouardklein at gmail.com>:

> I too got there from Hacker News.
> 
> I like to read stories from the Unix Lore, and discover the history of
> the
> tools that are everywhere in my computing environment at home and at
> work.
> I fear I'll have nothing to contribute, as I'm younger than System V,
> but
> I'll read the list with interest :)
> 
> On Wed, 21 Dec 2016 at 15:41 Kay Parker <kayparker at mailite.com> wrote:
> 
> > Hello,
> >
> > I'm researching Computer history, especially Unix. I noticed the
> > mentioned article reading a mail from this great list.
> >
> > On Wed, Dec 21, 2016, at 05:16 AM, Avinash Sonawane wrote:
> > > On Wed, Dec 21, 2016 at 2:33 PM, Warren Toomey <wkt at tuhs.org>
> wrote:
> > > > All, I've just got back from a few days away to find 14 new
> > subscription
> > > > requests to the TUHS mailing list. Welcome aboard to you all.
> > > >
> > > > Normally I only get one request a month
> > >
> > > May be it's because "How Unix made it to the top"[0] made it to the
> > > front page of Hacker News[1], a forum frequented by geeks.
> > >
> > > [0] http://minnie.tuhs.org/pipermail/tuhs/2016-December/007519.html
> > > [1] https://news.ycombinator.com/item?id=13204054
> > >
> > > --
> > > Avinash Sonawane (rootKea)
> > > PICT, Pune
> > > https://rootkea.wordpress.com
> >
> >
> > --
> > Kay Parker
> > kayparker at mailite.com
> >
> > --
> > http://www.fastmail.com - The professional email service
> >
> >
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn


From dds at aueb.gr  Thu Dec 22 17:27:20 2016
From: dds at aueb.gr (Diomidis Spinellis)
Date: Thu, 22 Dec 2016 09:27:20 +0200
Subject: [TUHS] User maintained programs in the Second Edition
Message-ID: <335aede9-7b7c-42e3-a22d-ef3918e92625@aueb.gr>

The Second Edition manual has a section titled "User Maintained 
Programs" listing the following utilities and games: basic, bc, bj, cal, 
chash, cre, das, dli, dpt, moo, ptx, tmg, and ttt.  In the Introduction, 
the reader is asked to consult their authors for more information.

Does anyone remember whether at the time these were installed in the 
system-wide /bin directory, or whether they were only available in their 
owners' home directories?


From schily at schily.net  Thu Dec 22 19:22:32 2016
From: schily at schily.net (Joerg Schilling)
Date: Thu, 22 Dec 2016 10:22:32 +0100
Subject: [TUHS] User maintained programs in the Second Edition
In-Reply-To: <335aede9-7b7c-42e3-a22d-ef3918e92625@aueb.gr>
References: <335aede9-7b7c-42e3-a22d-ef3918e92625@aueb.gr>
Message-ID: <585b9b58.gqyK0iLT316eaCsZ%schily@schily.net>

Diomidis Spinellis <dds at aueb.gr> wrote:

> Does anyone remember whether at the time these were installed in the 
> system-wide /bin directory, or whether they were only available in their 
> owners' home directories?

>From what I remember from a talk from Stephen Bourne at a Sun user group 
meeting in 1990, user maintained programs have been installed in /usr/bin.

Stephen Bourne after some time wrote a cron job that checked whether an update
in a binary also resulted in an updated man page and otherwise removed the 
binary. This is why these programs have man pages.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/


From spedraja at gmail.com  Thu Dec 22 19:28:57 2016
From: spedraja at gmail.com (SPC)
Date: Thu, 22 Dec 2016 10:28:57 +0100
Subject: [TUHS] User maintained programs in the Second Edition
In-Reply-To: <585b9b58.gqyK0iLT316eaCsZ%schily@schily.net>
References: <335aede9-7b7c-42e3-a22d-ef3918e92625@aueb.gr>
 <585b9b58.gqyK0iLT316eaCsZ%schily@schily.net>
Message-ID: <CACytpF-=-BHxDk1YS58D+z2ZK3veaktw3uu-Ssyi+ZmxTgAuuw@mail.gmail.com>

2016-12-22 10:22 GMT+01:00 Joerg Schilling <schily at schily.net>:
> Diomidis Spinellis <dds at aueb.gr> wrote:
>
>> Does anyone remember whether at the time these were installed in the
>> system-wide /bin directory, or whether they were only available in their
>> owners' home directories?
>
> From what I remember from a talk from Stephen Bourne at a Sun user group
> meeting in 1990, user maintained programs have been installed in /usr/bin.
>
> Stephen Bourne after some time wrote a cron job that checked whether an update
> in a binary also resulted in an updated man page and otherwise removed the
> binary. This is why these programs have man pages.
>
> Jörg
>
> --
>  EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
>        joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
>  URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

Impressive. Everything has a reason, that's clear. A primitive but
more or less effective security measure for new software installations
:-)

Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations

--
Sergio Pedraja
--
twitter: @sergio_pedraja | skype: Sergio Pedraja
--
http://plus.google.com/u/0/101292256663392735405
http://www.linkedin.com/in/sergiopedraja
http://spedraja.wordpress.com
-----
No crea todo lo que ve, ni crea que está viéndolo todo
-----
"El estado de una Copia de Seguridad es desconocido
hasta que intentas restaurarla" (- nixCraft)


From dave at horsfall.org  Fri Dec 23 02:14:04 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 23 Dec 2016 03:14:04 +1100 (EST)
Subject: [TUHS] User maintained programs in the Second Edition
In-Reply-To: <585b9b58.gqyK0iLT316eaCsZ%schily@schily.net>
References: <335aede9-7b7c-42e3-a22d-ef3918e92625@aueb.gr>
 <585b9b58.gqyK0iLT316eaCsZ%schily@schily.net>
Message-ID: <alpine.BSF.2.20.1612230310310.43538@aneurin.horsfall.org>

On Thu, 22 Dec 2016, Joerg Schilling wrote:

> Stephen Bourne after some time wrote a cron job that checked whether an 
> update in a binary also resulted in an updated man page and otherwise 
> removed the binary. This is why these programs have man pages.

An effective way of enforcing compliance :-)  I like it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From tfb at tfeb.org  Fri Dec 23 02:36:27 2016
From: tfb at tfeb.org (Tim Bradshaw)
Date: Thu, 22 Dec 2016 16:36:27 +0000
Subject: [TUHS] Dennis' Draft of the Unix Timesharing System: not so
 draft?
In-Reply-To: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>
References: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu>
Message-ID: <5EFEE7CA-7FB3-4652-A354-00C4276A1406@tfeb.org>


> On 19 Dec 2016, at 20:10, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> On a related note, great as my respect is for Ken and Doug for their work on
> early Unix (surely the system with the greatest bang/buck ratio ever), I have
> to disagree with them about Multics. In particular, if one is going to have a
> system as complex as modern Unices have become, one might as well get the
> power of Multics for it. Alas, we have the worst of both worlds - the size,
> _without_ the power.

This is slightly tangential, but I think it's fairly hard to take a simple system and turn it into a complicated system without ending up with a mess (and I claim that modern Unix is a mess).

I spent a bunch of my life programming in Common Lisp: CL was famously thought of in the about 1990 as an *extremely* large language with many baroque complexities: the standards document I think was over a thousand pages, even with lots of things you actually need missing, and there were features which people regarded as hard to implement efficiently without special hardware support (they were wrong, but it was a common thing for people to say at the time).

And whatever CL was it was not particularly pretty or elegant as a language, at least on the surface: the standards people valued agreement with each other and easy compatibility with older Lisps over elegance, so there were just lots of things which were there for no really good reason other than that they had been there in older Lisps.

(Of course 'extremely large & baroque language' means 'a tiny fraction the size of modern C++', but this was in the early 1990s before the true horror of C++ had become apparent.)

A lot of people were just derisive about CL: in particular the Scheme people.  Scheme was this tiny and *extremely* elegant language.  Programming in Scheme was just nice, because it was so small: R4RS seems to be 55 pages, including formal semantics and macros, I can't find R3RS in page-countable form, but it must have been 40 pages or something (no macros).  And tail-call elimination with first-class continuations: all the guilty pleasure of GO TO without the guilt.

Scheme was just great, except you couldn't do anything useful because it was so minimal.  But apart from that, great.

So now I use Racket which is a sort of Scheme which has eaten too much and read too many computer science text books.  And although it's just an enormously nice language, the moment you try to use some of its more industrial parts (structures or the object system) you realise *just how careful the design of those things in CL was*.  Nothing about the CL design was pretty, but it was designed by people who had both used the system themselves *and talked to many other users*, and addressed the things that made their lives hard.  So, of course, I still program in CL because, though it's ugly as shit, it's very very sorted out.

So, finally getting to the point: I think it's significantly hard, to take small elegant systems and turn them into large industrial systems: if you want large industrial, you need to design for large industrial and not worry too much about elegance.  Unix is kind of the poster child for what happens when you don't do that.

--tim

From doug at cs.dartmouth.edu  Fri Dec 23 12:28:08 2016
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 22 Dec 2016 21:28:08 -0500
Subject: [TUHS] User maintained programs in the Second Edition
Message-ID: <201612230228.uBN2S8Mg000927@coolidge.cs.Dartmouth.EDU>

> Does anyone remember whether at the time these were installed in the
> system-wide /bin directory,

Those that I remember were in /usr/bin. 

Doug


From dds at aueb.gr  Fri Dec 23 19:37:25 2016
From: dds at aueb.gr (Diomidis Spinellis)
Date: Fri, 23 Dec 2016 11:37:25 +0200
Subject: [TUHS] User maintained programs in the Second Edition
In-Reply-To: <201612230228.uBN2S8Mg000927@coolidge.cs.Dartmouth.EDU>
References: <201612230228.uBN2S8Mg000927@coolidge.cs.Dartmouth.EDU>
Message-ID: <4d58ff50-dd59-35dc-6c9a-db9d6fd0feac@aueb.gr>

On 23/12/2016 04:28, Doug McIlroy wrote:
 >> Does anyone remember whether at the time these were installed in the
 >> system-wide /bin directory,
 >
 > Those that I remember were in /usr/bin.

So was "/usr/bin" initially only for user-contributed binaries, or was 
it from its inception a place for binaries that were not essential for 
system boot and could not fit in the root partition?

The second reason is the one that is popularly documented e.g.:

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
http://askubuntu.com/questions/130186/what-is-the-rationale-for-the-usr-directory




From schily at schily.net  Fri Dec 23 20:27:05 2016
From: schily at schily.net (Joerg Schilling)
Date: Fri, 23 Dec 2016 11:27:05 +0100
Subject: [TUHS] User maintained programs in the Second Edition
In-Reply-To: <4d58ff50-dd59-35dc-6c9a-db9d6fd0feac@aueb.gr>
References: <201612230228.uBN2S8Mg000927@coolidge.cs.Dartmouth.EDU>
 <4d58ff50-dd59-35dc-6c9a-db9d6fd0feac@aueb.gr>
Message-ID: <585cfbf9./QvpLi9Own5BWHBz%schily@schily.net>

Diomidis Spinellis <dds at aueb.gr> wrote:

> On 23/12/2016 04:28, Doug McIlroy wrote:
>  >> Does anyone remember whether at the time these were installed in the
>  >> system-wide /bin directory,
>  >
>  > Those that I remember were in /usr/bin.
>
> So was "/usr/bin" initially only for user-contributed binaries, or was 
> it from its inception a place for binaries that were not essential for 
> system boot and could not fit in the root partition?

>From the talk from Stephen Bourne around 1990 at the Sun User Group meeting, 
/usr/bin started with user contributed binaries only.

Later the directory was aquired by the system after many of the user 
contributed programs have been integrated into UNIX.

At that time people started to use /usr/local and in order to interrupt this 
chain of bad naming, /opt/<vendor>/bin has been introduced.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/


From jnc at mercury.lcs.mit.edu  Fri Dec 23 22:50:47 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 23 Dec 2016 07:50:47 -0500 (EST)
Subject: [TUHS] phototypesetter C (was nm on Third Edition .o files)
Message-ID: <20161223125047.0519218C0BA@mercury.lcs.mit.edu>

    > I don't think I ever heard the appellation "phototypesetter C"
    > before.

Interesting data point; thanks for passing that along.

    > Certainly C and the phottypesetter developed independently, though in
    > the same room. But the explanation that they got linked by appearing in
    > the same tape release makes perfect sense.

I have this vague memory of being told, or reading somewhere, that many of the
changes from 'vanilla V6' C to 'phototypsetter' C were added because they were
needed for that project, hence the name. Alas, I have no idea where I might
have gotten that from (I had a quick look at a few likely documentary sources,
but no joy).

It's quite possible that this was a supposition on someone outside Bell's part
(or perhaps inside Bell, but outside the Unix group), because the two came out
in the same tape.

Reading the notes about the upgrades (in particular, "newstuff.nr") makes it
seem like a more likely driver of _some_ of the changes was the Interdata port
(which was also happening at around the same time, if I have the timeline
correct). And of course some might have been driven by general utility (e.g.
the ability to initialize structures).

It would be interesting to see if anyone remembers why these changes were made.

   Noel


From clemc at ccc.com  Sat Dec 24 01:28:05 2016
From: clemc at ccc.com (Clem Cole)
Date: Fri, 23 Dec 2016 10:28:05 -0500
Subject: [TUHS] phototypesetter C (was nm on Third Edition .o files)
In-Reply-To: <20161223125047.0519218C0BA@mercury.lcs.mit.edu>
References: <20161223125047.0519218C0BA@mercury.lcs.mit.edu>
Message-ID: <CAC20D2PAq2uupcQ2DvQqds6dX=Ji8yqJmTBObO3bWA_NvjDRyw@mail.gmail.com>

On Fri, Dec 23, 2016 at 7:50 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > I don't think I ever heard the appellation "phototypesetter C"
>     > before.
>
> Interesting data point; thanks for passing that along.

​Indeed.​




>
>
>     > Certainly C and the phottypesetter developed independently, though
> in
>     > the same room. But the explanation that they got linked by appearing
> in
>     > the same tape release makes perfect sense.
>
> I have this vague memory of being told, or reading somewhere, that many of
> the
> changes from 'vanilla V6' C to 'phototypsetter' C were added because they
> were
> needed for that project, hence the name. Alas, I have no idea where I might
> have gotten that from (I had a quick look at a few likely documentary
> sources,
> but no joy).

​My memory also.   I may have gotten that from Dennis or srb in
conversation at some point​ at an early USENIX conference.




>
>
> It's quite possible that this was a supposition on someone outside Bell's
> part
> (or perhaps inside Bell, but outside the Unix group), because the two came
> out
> in the same tape.

​Yes - in fact why many of us called it "Typesetter C" because the way we
got that compiler was with the independent Phototypesetter release from
AT&T.   It was all a licensing thing - and the folks in the labs may
otohave realized it -- it was a moniker we used outside of the labs to
differentiate between the different versions of the compiler in the wild.​

I'm trying to remember all of the details/sequences and frankly, I may not
have everything.   But IIRC at CMU I >>believe<< the path we ran 5th, then
6th, got Phototypesetter, then TS, than V7.  i.e. Ken made RK05 images for
us for the 5th edition and that was brought up circia 74/75.   They were
updated to v6 shortly there after via 9track, IIRC, as was the
Phototypsetter code.   tjk brought TS to us on RK05 images on boot-able
9-tracks and V7 was a 1600 bpi tape.

IIRC the CS csv/cret changes were done to a V6 based compiler and then
updated to the Phototypesetter compiler.   When Ted brought us TS ( which
had a different compiler ) we had to hack the compiler per my previous
message.

When V7 was about to be be released we were pumping Ted for info, which he
had some but not all what what we wanted to know.   I remember having a
conversation with some of the BTL folks a @ USENIX (I think it was with
Dennis, but srb may have been part of it also ) asking about the soon to be
delivered 7th edition.  Again, IIRC Klein and I were trying to figure out
what had be changed and how we CS was going to keep going (dvk's domain)
and EE/Mellon Institute (mine own).   The own issue was that CS UNIX
systems were lot of mostly 11/40e's with a couple maybe 45's, but EE,
Mellon, Bio et all were running 11/34's.


>
>
> Reading the notes about the upgrades (in particular, "newstuff.nr") makes
> it
> seem like a more likely driver of _some_ of the changes was the Interdata
> port
> (which was also happening at around the same time, if I have the timeline
> correct).

​Right -- I'm trying to line up what we were doing around the same period
to see if I can help date it a little.​




> And of course some might have been driven by general utility (e.g.
> the ability to initialize structures).

 I want to say the Mergenthaler and the APS5 must have been on the
horizon at BTL?  Doug or aps - can either of you offer any enlightenment?
I remember a different conversation with Brian and he saying that when he
was were doing the ditroff work and Ken was reverse engineering the
mergenthaler, Dennis was adding things to make ditroff easier to write.



>
>
> It would be interesting to see if anyone remembers why these changes were
> made.

​We should ask Brian,  I would think, he would have been mixed up in all.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161223/5e552afa/attachment.html>

From clemc at ccc.com  Sat Dec 24 02:57:02 2016
From: clemc at ccc.com (Clem Cole)
Date: Fri, 23 Dec 2016 11:57:02 -0500
Subject: [TUHS] User maintained programs in the Second Edition
In-Reply-To: <585cfbf9./QvpLi9Own5BWHBz%schily@schily.net>
References: <201612230228.uBN2S8Mg000927@coolidge.cs.Dartmouth.EDU>
 <4d58ff50-dd59-35dc-6c9a-db9d6fd0feac@aueb.gr>
 <585cfbf9./QvpLi9Own5BWHBz%schily@schily.net>
Message-ID: <CAC20D2N6RsnhZekDagDEGRXeP45qMptAOGCbQjkOkm+uBsQrJw@mail.gmail.com>

below...

On Fri, Dec 23, 2016 at 5:27 AM, Joerg Schilling <schily at schily.net> wrote:

> Diomidis Spinellis <dds at aueb.gr> wrote:
>
> > On 23/12/2016 04:28, Doug McIlroy wrote:
> >  >> Does anyone remember whether at the time these were installed in the
> >  >> system-wide /bin directory,
> >  >
> >  > Those that I remember were in /usr/bin.
> >
> > So was "/usr/bin" initially only for user-contributed binaries, or was
> > it from its inception a place for binaries that were not essential for
> > system boot and could not fit in the root partition?
>
> From the talk from Stephen Bourne around 1990 at the Sun User Group
> meeting,
> /usr/bin started with user contributed binaries only.
>
> Later the directory was aquired by the system after many of the user
> contributed programs have been integrated into UNIX.

​Right - that follows what I had been told.   So /usr/local (for locally
compiled) and /usr/ucb (to differentiate from Research programs) were
introduced, which worked when UNIX was a source release.​

​Many makefiles in USENIX tapes use the /usr/local convention for new
programs but it failed to deal with binary distributions from ISV's ​




>
>
> At that time people started to use /usr/local and in order to interrupt
> this
> chain of bad naming, /opt/<vendor>/bin has been introduced.

​Almost right --- This was one of the things the /usr/group gave us.   IIRC
it was Heinz Lyclamia that proposed it BTW.   Before IEEE P1003 (aka POSIX)
the burgeoning industry folks started to talk about how to deal with the
plethora of almost, but not quite the same UNIX flavors.   The 1985
/usr/group API was the result (which would begat POSIX but that's a
different story).

Heinz was the pushing an ABI not an API.   He was sure UNIX would never be
able to compete with VMS or the like and get ISV's to the table without
one.  Two of the things he insisted that we consider was where to install
vendors code and /usr/opt/vendor was born (** /opt would come later **)​.
It was put in /usr because symlink did not yet exist AND people agreed that
the root file system should be as small as possible.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161223/06ce5618/attachment.html>

From dds at aueb.gr  Sat Dec 24 03:15:04 2016
From: dds at aueb.gr (Diomidis Spinellis)
Date: Fri, 23 Dec 2016 19:15:04 +0200
Subject: [TUHS] Validating the s2-bits tape epoch
Message-ID: <5f63c34a-aa66-f462-8a39-cce86348aa27@aueb.gr>

The document 
http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Readme 
discusses the uncertainty regarding the epoch used for the file timestamps.

"The biggest problem here is to pin down the epoch for the files. In the
early version of UNIX, timestamps were in 1/60th second units. A 32-bit
counter using these units overflows in 2.5 years, so the epoch had to
be changed periodically, and I believe 1970, 1971, 1972 and 1973 were
all epochs at one stage or another."

"Given that the C compiler passes, and the library, are dated in June
of the epoch year, and that Dennis has said ``1972-73 were the truly
formative years in the development of the C language'', it's therefore
unlikely that the epoch for the s2 tape is 1971: it is more likely to
be 1972. The tape also contains several 1st Edition a.out binaries,
which also makes it unlikely to be 1973."

"Therefore, Warren's decoding of the s2-bits file, in s2-bits.tar.gz,
uses 1972 as the epoch. However, Dennis decoding in s2.tar.gz uses 1973."

"Finally, the date(1) a.out on the tape uses 1971 as its archive. How 
annoying! After a bit of discussion, Dennis and Warren have agreed that 
1972 is the most probable epoch for s2-bits."

I thought I could validate the epoch by looking at the distribution of 
weekdays for the three alternative years (1971 to 1973).  Here are the 
results.

wget 
http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Readme
for guess in 1971 1972 1973 ; do
   echo $guess
   EPOCH=$(date +'%s' -d "$guess/01/01 00:00 UTC")
   awk '/\/core/,/\/etc\/init/ {
    if ($9) print strftime("%a", '$EPOCH' + $9 / 60)}' Readme |
    sort |
    uniq -c |
    sort -n
done

1971
       1 Sat
       6 Mon
       8 Thu
       8 Tue
      17 Fri
      21 Wed
      34 Sun
1972
       1 Sun
       6 Tue
       8 Fri
       8 Wed
      17 Sat
      21 Thu
      34 Mon
1973
       1 Tue
       6 Thu
       8 Fri
       8 Sun
      17 Mon
      21 Sat
      34 Wed

As you can see, unless weekends at the Bell Labs were highly atypical, 
1972 has the most probable distribution of work among the days of the week.


From jnc at mercury.lcs.mit.edu  Sat Dec 24 04:25:05 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 23 Dec 2016 13:25:05 -0500 (EST)
Subject: [TUHS] Utility of C changes (Was: phototypesetter C)
Message-ID: <20161223182505.44FD918C0BB@mercury.lcs.mit.edu>

    > of course some [of the changes to C in this time period] might have been
    > driven by general utility (e.g. the ability to initialize structures).

I was thinking about this, with my memory of the changes refreshed by
re-reading those 'changes to C' notes, and it's interested how many of them
were ones I personally (and most of the people working with me) didn't use.

Here is a list of the changes described in those 3 documents:

'newstuff':

- Longs 
- Unsigneds
- Blocks (locals declared inside a non-top-level {} pair)
- Initialization of structures
- Initialization of automatic variables
- Bit fields
- Macro functions
- Macro conditionals (#ifdef)
- Arguments in registers
- Typedefs
- 'Static' scope

'Changes':

- Multi-line macros
- Undefine
- Conditional expressions (#if)
- Unions
- Casts
- Sizeof() on abstractions
- '=' in initializations
- Change binary operators from trailing to leading
- 'extern' does not allocate storage

(This note also includes unsigneds, blocks, and structure initializations,
from the earlier? note.)

'cchanges':

- Structure assignment and argument/return-value
- Enum


Of these, I never really used quite a few: blocks, automatic initializations,
typedefs, unions, structure assignment/etc, or enum. I'm not sure if I ever
used bit fields, either. Some of these are understandable; e.g. automatic
initializations are just syntactic sugar (as are register arguments, but I did
use those).

Typedef is also effectively syntactic sugar; you can always use a macro and
get almost (entirely?) the same result. In fact, I devised an entire system of
types to make the code I was working on (almost entirely networking code, so
lots of packet headers from other machines, etc) more rigorous - and later it
turned out it had made it much more portable; it all used macros, not typedef.
I don't think I ever used typedef...

(The details of that might be of some interest: instead of int, long, etc we
had things of the form {type}{len}, where {type}pe} was 'int', 'uns', 'bit',
etc and length was 'b', 's', 'l', or two other interesting ones 'w' and 'f' -
'w' meant the machine's native word length, and 'f' meant whatever was fastest
on the machine. So 'unsl' mean '32-bit unsigned'. Depending on the machine,
the compiler couldn't always produce them all - e.g. the PDP-11 didn't have
unsl - so sometimes you had to live with non-optimal replacements. There were
also un-typed types, i.e. 'byte', 'swrd', 'lwrd' - 8, 16 and 32 bits - and
'word' - the machine's native length.)

Unions didn't get used much either, in our stuff, although one would think it
would be useful in network code - you get a packet with a pile of bits inside
it, which can be one of N different formats, seems like a perfect application
for a union. The problemis that it tied two different subsystems intimately
together. If you have protocol A and protocol B, if you use a union to define
the header format, the union has to have both A and B in it. Now if you want
to add protocol C, that requires modifying that union definition. It was much
easier to just take a pointer to the outer packet's data area, and assign
(with cast) it to a new pointer variable which was of the correct type for the
header you were trying to process.

Some of the new things were incredibly useful, though - or, in fact, one
couldn't get by without them. Casts were incredibly useful once the compiler
got pickier. Initialization of structures was huge - other than 'bdevsw'-like
hacks, there was just no other way to do that.

    Noel


From doug at cs.dartmouth.edu  Sat Dec 24 04:52:14 2016
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 23 Dec 2016 13:52:14 -0500
Subject: [TUHS] tuhs@minnie.tuhs.org Re: User maintained programs in the
 Second Edition
Message-ID: <201612231852.uBNIqE7u012552@coolidge.cs.Dartmouth.EDU>


> So was "/usr/bin" initially only for user-contributed binaries, or was
it from its inception a place for binaries that were not essential for
system boot and could not fit in the root partition?

The latter is my understanding, but early on the two 
interpretations would have been nearly coextensive.
Remember, though, that even Ken wrote some "user-contributed"
code.

Doug


From wkt at tuhs.org  Sat Dec 24 05:25:08 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 24 Dec 2016 05:25:08 +1000
Subject: [TUHS] Validating the s2-bits tape epoch
In-Reply-To: <5f63c34a-aa66-f462-8a39-cce86348aa27@aueb.gr>
References: <5f63c34a-aa66-f462-8a39-cce86348aa27@aueb.gr>
Message-ID: <20161223192508.GA2831@minnie.tuhs.org>

On Fri, Dec 23, 2016 at 07:15:04PM +0200, Diomidis Spinellis wrote:
> "Finally, the date(1) a.out on the tape uses 1971 as its archive. How
> annoying! After a bit of discussion, Dennis and Warren have agreed that 1972
> is the most probable epoch for s2-bits."
> 
> I thought I could validate the epoch by looking at the distribution of
> weekdays for the three alternative years (1971 to 1973).  Here are the
> results.
...
> As you can see, unless weekends at the Bell Labs were highly atypical, 1972
> has the most probable distribution of work among the days of the week.

Thanks Diomidis, that helps to confirm the 1972 date for the s2-bits tape.

Cheers, Warren


From wkt at tuhs.org  Sat Dec 24 05:28:19 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 24 Dec 2016 05:28:19 +1000
Subject: [TUHS] phototypesetter C (was nm on Third Edition .o files)
In-Reply-To: <20161223125047.0519218C0BA@mercury.lcs.mit.edu>
References: <20161223125047.0519218C0BA@mercury.lcs.mit.edu>
Message-ID: <20161223192819.GB2831@minnie.tuhs.org>

On Fri, Dec 23, 2016 at 07:50:47AM -0500, Noel Chiappa wrote:
> I have this vague memory of being told, or reading somewhere, that many of the
> changes from 'vanilla V6' C to 'phototypsetter' C were added because they were
> needed for that project, hence the name. Alas, I have no idea where I might
> have gotten that from (I had a quick look at a few likely documentary sources,
> but no joy).

I'm sure I saw some information in the old AUUG newsletters. They are at
http://minnie.tuhs.org/Archive/Documentation/AUUGN/

I'm just off on vacation, so I don't have a chance to check myself.

Cheers all & have a good festive season, Warren


From rochkind at basepath.com  Sat Dec 24 07:09:16 2016
From: rochkind at basepath.com (Marc Rochkind)
Date: Fri, 23 Dec 2016 14:09:16 -0700
Subject: [TUHS] tuhs@minnie.tuhs.org Re: User maintained programs in the
 Second Edition
In-Reply-To: <201612231852.uBNIqE7u012552@coolidge.cs.Dartmouth.EDU>
References: <201612231852.uBNIqE7u012552@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAOkr1zXe85Rf7doOmtJ-xaiEwbG2WQSKJBycBDurGZkkr5zf3Q@mail.gmail.com>

I vaguely recall that the system was supposed to run if /usr/bin wasn't
mounted.

There was, obviously, a big difference in criticality between, say, sh and
ed vs. troff and... everything I ever did.

--Marc

On Fri, Dec 23, 2016 at 11:52 AM, Doug McIlroy <doug at cs.dartmouth.edu>
wrote:

>
> > So was "/usr/bin" initially only for user-contributed binaries, or was
> it from its inception a place for binaries that were not essential for
> system boot and could not fit in the root partition?
>
> The latter is my understanding, but early on the two
> interpretations would have been nearly coextensive.
> Remember, though, that even Ken wrote some "user-contributed"
> code.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161223/81e16d8a/attachment.html>

From dave at horsfall.org  Sat Dec 24 09:08:09 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 24 Dec 2016 10:08:09 +1100 (EST)
Subject: [TUHS] Leap Second
Message-ID: <alpine.BSF.2.20.1612240952310.43538@aneurin.horsfall.org>

Let me be the first to say that the International Earth Rotation Service 
has announced that there will be a Leap Second inserted at 23:59:59 UTC on 
the 31st December, due to the earth slowly slowing down.  It's fun to 
listen to see how the time beeps handle it; will your GPS clock display 
23:59:60, or will it go nuts like my last one did (I had to power cycle 
the thing)?

My recording of the last one: horsfall.org/leapsecond.webm .

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From michael at kjorling.se  Sat Dec 24 09:19:35 2016
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Fri, 23 Dec 2016 23:19:35 +0000
Subject: [TUHS] Leap Second
In-Reply-To: <alpine.BSF.2.20.1612240952310.43538@aneurin.horsfall.org>
References: <alpine.BSF.2.20.1612240952310.43538@aneurin.horsfall.org>
Message-ID: <20161223231935.GW20777@yeono.kjorling.se>

On 24 Dec 2016 10:08 +1100, from dave at horsfall.org (Dave Horsfall):
> Let me be the first to say that the International Earth Rotation Service 
> has announced that there will be a Leap Second inserted at 23:59:59 UTC on 
> the 31st December,

I told a coworker about leap seconds the other day, in the middle of
discussing software that doesn't understand 24:00:00 as a time of day.
For a while, I believe he thought that I was pulling a prank on him.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From charles.unix.pro at gmail.com  Sat Dec 24 11:33:27 2016
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Fri, 23 Dec 2016 17:33:27 -0800
Subject: [TUHS] Leap Second
In-Reply-To: <alpine.BSF.2.20.1612240952310.43538@aneurin.horsfall.org>
References: <alpine.BSF.2.20.1612240952310.43538@aneurin.horsfall.org>
Message-ID: <CANV78LQxfhOpHpg3QZfJFX_=3Zme26x6YkbM=6Wedq_euhBtjA@mail.gmail.com>

On Fri, Dec 23, 2016 at 3:08 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Let me be the first to say that the International Earth Rotation Service
> has announced that there will be a Leap Second inserted at 23:59:59 UTC on
> the 31st December, due to the earth slowly slowing down.


A year and half ago, a running Multics emulation (Multics, so slightly on
topic) was crashed by the leap second. An improbable race condition in a in
a messaging library used by the DPS8M emulator fired an assertion, bring
the whole thing down.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161223/43a34ebd/attachment.html>

From lm at mcvoy.com  Sun Dec 25 13:16:37 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 24 Dec 2016 19:16:37 -0800
Subject: [TUHS] merry christmas
Message-ID: <20161225031637.GF12180@mcvoy.com>

As Neil Young said when he played with the band, it's been of one of
the great joys of my life to be here with you (yeah, I paraphrased).

As a kid who wanted to be at Bell Labs, a student who got the troff
manual and used it for the next 30 years, a student who got an account
on the vax 11/750 that had the BSD source on it and learned so much,
I just want to thank all of the Bell Labs people for being here and
Warren for putting this list together and for Unix teaching me so much.

If I could have one thing for Christmas it would be bwk joining the list.
I did some extensions to awk and asked him about it and he tarred up
~bwk/awk and sent it to me.  I've got the awk source and the book source
in english and french (I think).  Brian is awesome, it would be cool to
have him on this list.

All that said, I super grateful to be here amongst the people who were 
there when you got an image from Ken.  You guys are lucky.

--lm


From wkt at tuhs.org  Sun Dec 25 18:39:47 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 25 Dec 2016 18:39:47 +1000
Subject: [TUHS] Musings on PDP-7 Unix
Message-ID: <20161225083947.GA28327@minnie.tuhs.org>

[ This whole article is just a flight of fancy; feel free to ignore it or
  at least treat it as the whimsy that it is. ]

The PDP-7 Unix system is the first step on the evolution of Unix as we know it.
We have a snapshot of the system around the end of 1970/beginning of 1971 at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/
and a reconstructed and working partial system at
https://github.com/DoctorWkt/pdp7-unix

PDP-7 Unix was a playground for Ken, Dennis and others to try out ideas and
implementations, and it was quickly superseded by 1st Edition PDP-11 Unix.
Details of how it evolved are at https://www.bell-labs.com/usr/dmr/www/hist.html
and https://www.bell-labs.com/usr/dmr/www/chist.html

All fine and good. However, I keep wondering, how far could they have taken
Unix on the PDP-7 platform?

The Kernel
----------
The reconstructed kernel only occupies 3070 words of 4096 words available,
so there is room left for more code. There is already an alternative
reconstruction where the "dd" concept has been replaced with the ".."
concept (see https://github.com/DoctorWkt/pdp7-unix/tree/master/src/alt).

PDP-7 Unix doesn't have the concept of absolute or relative filenames
(e.g. /usr/bin/ls or a/b/c or ../../file), Could the nami kernel function
be modified to do this? It would probably mean changing from two characters
packed into a word to a single character per word (to make searching for
'/' easier), and this would turn it into something more recognisable as Unix.

What about pipes? They should not be too hard to implement. Even sixteen
pipes with a 16-word buffer each would only be 256+ extra data words in
the kernel. And a hundred words of code?

There are only a few special devices in the kernel: ttyin, ttyout, keyboard,
display, pptin, pptout. What about a disk block device? Was there a PDP-7
tape device, and if so, why not a tape driver and block device?

Filesystem
----------
The implementation of the filesystem is, in some places, quite inefficient.
The free block list is implemented as follows. In each block, there are
10 free block numbers then a pointer to the next part of the free list.
However, each block can hold 64 block numbers, so why are only 10 free
block numbers stored in each block? By using the whole of a block to store
free block numbers, there would actually be more free blocks to use!

Each i-node (size 12 words, 7 of which are direct or indirect pointers)
has one word which holds a unique value. This doesn't seem to be used at
all. If it was reused as a block pointer, this would allow files to be
up to 8*64=512 (small) or 8*64*64=32768 (large) words in length, instead of
7*64=448 words (small) or 7*64*64=28672 (large) words.

The system is set up to only use one side of the two-sided disk device.
It looks like the other side was used to backup (snapshot) a working
system in case of catastrophic filesystem corruption: they could simply
copy the blocks from the "snapshot" side back to the working side. We
could double the size of the filesystem quite easily.

Macro Assembler
---------------
The kernel is written using fairly tight assembly code, and there probably
isn't a way to translate it into a high-level language. The PDP-7 has an
arcane instruction set, and the existing assembler syntax is nothing special.
What about a macro assembler that makes it easier to write code, especially
readable code? Here are some ideas based on the existing kernel:

u.rq := 8	==> lac 8; dac u.rq

function swap	==> swap: 0
{
  return; 	    jmp swap i
}

subroutine .fork ==> fork: line 1	// i.e. not a function
{
  line 1
}

loop		==> 1:
{
}			jmp 1b

if (sad dm1)    ==> 	sad dm1
{			  jmp 1f
  code1			code1
} else {	    1:  code2
  code2
}

  betwen(o101,o132) ==> jms betwen; o101; o132

There are probably a bunch more that could be added. The aim is to
make the control structures easier to read and write. The programmer
still has to grok the PDP-7 instruction set.


B (or other) Language
---------------------
PDP-7 Unix has a B compiler while compiles source down to a virtual
instruction set which is interpreted by the B interpreter. We have the
B interpreter code, and Robert Swierczek managed to rewrite the B compiler,
see https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/b.b

At first glance, the PDP-7 architecture is not that amenable to high level
languages, but it turns out that it is indeed possible to write a compiler for
a C subset that targets the PDP-7, see https://github.com/DoctorWkt/a-compiler.
So, could the B compiler be modified to actually output PDP-7 assembly code?
If so, we could rewrite the utilities (cp, mv, ls etc.) in a high-level
language and make the system easier to maintain. I would recommend treating
int and char as the same and only storing one char per word.

And then, even though the PDP-7 architecture doesn't support it, how hard
would it be to add int/char types and bring the language one step closer to C?

Conclusion
----------
All of this is pie in the sky. It can certainly be done, but a) who has
the time and b) it would be a "tour de force", nothing really useful. But
imagine if, at the beginning of 1970, Unix had a proper B or C compiler,
utilities written in this high-level language, a kernel written in a semi-high
level language, and a system with pipes and proper pathnames.

Cheers, Warren


From downing.nick at gmail.com  Mon Dec 26 07:44:13 2016
From: downing.nick at gmail.com (Nick Downing)
Date: Mon, 26 Dec 2016 08:44:13 +1100
Subject: [TUHS] merry christmas
In-Reply-To: <20161225031637.GF12180@mcvoy.com>
References: <20161225031637.GF12180@mcvoy.com>
Message-ID: <CAH1jEzaAL-0cEYGzxry4FkJWEZ=+oxQbNhz6WsUoVj03qquq4w@mail.gmail.com>

Yeah :)

I'm only an occasional contributor to the list, more of a lurker really
since I was pretty busy this year. Well I promised a guy on the list some
Unixy stuff that I had and have been gradually going through it and putting
it on bitbucket but have not had time to write it all up yet.

But I wanted to jump in and say something to the new people who joined the
list owing to whatever was the recent media coverage we had. Welcome and
all that. But IT ISN'T NECESSARY to have been around at the inception of
Unix to get into it and to learn about the retro flavours, come up to speed
in PDP-11 asm or learn about the old filesystems or whatever it is that
floats your boat :)

Personally when I discover something AWESOME I immediately want to take it
apart and learn EVERYTHING about it. For me in the case of Unix, I quit my
job in about 2005 and had about 3-6 months of downtime while considering my
next moves, I had next to no money so I could not really leave the house,
but I had a houseful of computers and a 33.6k modem so I set myself the
task of learning about this mysterious Linux thing. I downloaded Slackware
4.0 onto a set of floppies and followed the Linux From Scratch instructions
to build and bring up my own Linux flavour from that.

This was very educational and it highlights the main point of my post which
is you MUST GET YOUR HANDS DIRTY, reading ancient source code is fine but
one doesn't retain much info unless one reads for a purpose (why the hell
won't this RK05 boot my system etc). So anyway a lot of things still
remained a bit mysterious after my LFS adventures since they are that way
for historical reasons, and I found myself bringing up earlier Unices on
simh to take a peek and joining this list etc.

But as I said one does not retain much unless one has a purpose and
probably the project that taught me the most was bringing up someone's
hobby Unix V7 clone on a cash register motherboard from the equipment I
used to sell in my day job. The software is called UZI (Unix Z80
implementation). I remembered waaay way back when I was pottering around
with CP/M and enhancements like ZCPR3 I saw this mentioned in a newsgroup
or similar, with a description that it runs Unix in 64k by loading the
kernel in first 32k and a process in second 32k and uses "total swapping"
i.e. it multitasks or implements child processes by writing the second 32k
to a swapfile on floppy disk and loading it back in later. This sounded
very intriguing and I wanted to try it out. So, years after reading this
newsgroup post I obtained it and compiled it (using the IAR compiler we
used for cash register development) for my cash register.

Long story short the thing was soon utilizing various kinds of bank
switched memory available in this cash register (which had a Z180 CPU and
hence behaved like a Z80 with an MMU and other integrated peripherals) and
had a network stack from Phil Karn's NOS, it had lots of communication
ports for barcode scanners, printers, modem etc and I had them running SLIP
and communicating with publicly available FTP servers, I used to use
mirror.aarnet.edu.au for testing and my cash register could download small
files.

I became frustrated with the limitations of both UZI and NOS and decided to
port 2.11BSD to the cash register as the next step, my goal was (a) make it
cross compile from Linux to PDP-11, (b) check it can build an identical
release tape through cross compilation, (c) port it to Z80 using my
existing cross compiler. Well I don't think I got all the way through this
ambitious programme before putting it aside and starting a new job but I
sure as hell learned a lot about building PDP-11 Unix. The buildsystem is
complicated and contains its share of hacks, but overall much simpler than
something like gnu's configure/make or cmake or etc.

Although I was not around for early Unix (was probably a 10yr old taking
apart an Apple II and trying to learn 6502 code without the benefit of an
assembler in 1985 when stuff like SVR4 was popular) I probably know as much
about its internals and development environment as many people here, due to
having got my hands dirty, albeit 30 years later. In fact I FEEL LIKE I WAS
THERE. So my suggestion to newbies is, get your simh on, and tackle some
interesting project such as reconstructing an early source for something
from the fragmentary surviving pieces, backporting some useful tool to an
earlier Unix, or whatever. Just get your hands dirty and it will be an
infinitely rewarding experience. Because Unix is AWESOME. Retrocomputing is
AWESOME. Simulators are AWESOME. :)

cheers, Nick

On Dec 25, 2016 2:17 PM, "Larry McVoy" <lm at mcvoy.com> wrote:

> As Neil Young said when he played with the band, it's been of one of
> the great joys of my life to be here with you (yeah, I paraphrased).
>
> As a kid who wanted to be at Bell Labs, a student who got the troff
> manual and used it for the next 30 years, a student who got an account
> on the vax 11/750 that had the BSD source on it and learned so much,
> I just want to thank all of the Bell Labs people for being here and
> Warren for putting this list together and for Unix teaching me so much.
>
> If I could have one thing for Christmas it would be bwk joining the list.
> I did some extensions to awk and asked him about it and he tarred up
> ~bwk/awk and sent it to me.  I've got the awk source and the book source
> in english and french (I think).  Brian is awesome, it would be cool to
> have him on this list.
>
> All that said, I super grateful to be here amongst the people who were
> there when you got an image from Ken.  You guys are lucky.
>
> --lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161226/ff6e5788/attachment.html>

From usotsuki at buric.co  Mon Dec 26 08:21:31 2016
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 25 Dec 2016 17:21:31 -0500 (EST)
Subject: [TUHS] merry christmas
In-Reply-To: <CAH1jEzaAL-0cEYGzxry4FkJWEZ=+oxQbNhz6WsUoVj03qquq4w@mail.gmail.com>
References: <20161225031637.GF12180@mcvoy.com>
 <CAH1jEzaAL-0cEYGzxry4FkJWEZ=+oxQbNhz6WsUoVj03qquq4w@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1612251712530.65296@frieza.hoshinet.org>

On Mon, 26 Dec 2016, Nick Downing wrote:

> I'm only an occasional contributor to the list, more of a lurker really
> since I was pretty busy this year. Well I promised a guy on the list some
> Unixy stuff that I had and have been gradually going through it and putting
> it on bitbucket but have not had time to write it all up yet.

I'm mostly a lurker myself.

> But I wanted to jump in and say something to the new people who joined the
> list owing to whatever was the recent media coverage we had. Welcome and
> all that. But IT ISN'T NECESSARY to have been around at the inception of
> Unix to get into it and to learn about the retro flavours, come up to speed
> in PDP-11 asm or learn about the old filesystems or whatever it is that
> floats your boat :)

QFT

> Personally when I discover something AWESOME I immediately want to take it
> apart and learn EVERYTHING about it. For me in the case of Unix, I quit my
> job in about 2005 and had about 3-6 months of downtime while considering my
> next moves, I had next to no money so I could not really leave the house,
> but I had a houseful of computers and a 33.6k modem so I set myself the
> task of learning about this mysterious Linux thing. I downloaded Slackware
> 4.0 onto a set of floppies and followed the Linux From Scratch instructions
> to build and bring up my own Linux flavour from that.

I got some exposure in the mid-late 90s on a Solaris shell before 
experimenting with Linux.  Actually, I installed DJGPP on one of my PCs so 
I got a basic feel for how the command line stuff worked even before I had 
Linux operational on my own systems.

> This was very educational and it highlights the main point of my post which
> is you MUST GET YOUR HANDS DIRTY, reading ancient source code is fine but
> one doesn't retain much info unless one reads for a purpose (why the hell
> won't this RK05 boot my system etc). So anyway a lot of things still
> remained a bit mysterious after my LFS adventures since they are that way
> for historical reasons, and I found myself bringing up earlier Unices on
> simh to take a peek and joining this list etc.

Knowing about the history of Unix certainly makes some of the decisions in 
Linux make more sense.

> But as I said one does not retain much unless one has a purpose and
> probably the project that taught me the most was bringing up someone's
> hobby Unix V7 clone on a cash register motherboard from the equipment I
> used to sell in my day job. The software is called UZI (Unix Z80
> implementation).

I played around with a fork of UZI on an MSX emulator once.  Interesting 
stuff, that.

<snip>

> Long story short the thing was soon utilizing various kinds of bank
> switched memory available in this cash register (which had a Z180 CPU and
> hence behaved like a Z80 with an MMU and other integrated peripherals) and
> had a network stack from Phil Karn's NOS, it had lots of communication
> ports for barcode scanners, printers, modem etc and I had them running SLIP
> and communicating with publicly available FTP servers, I used to use
> mirror.aarnet.edu.au for testing and my cash register could download small
> files.
>
> I became frustrated with the limitations of both UZI and NOS and decided to
> port 2.11BSD to the cash register as the next step, my goal was (a) make it
> cross compile from Linux to PDP-11, (b) check it can build an identical
> release tape through cross compilation, (c) port it to Z80 using my
> existing cross compiler.

A Z180 is powerful enough to run 2.11BSD? o.o;

<snip>

> Although I was not around for early Unix (was probably a 10yr old taking
> apart an Apple II and trying to learn 6502 code without the benefit of an
> assembler in 1985 when stuff like SVR4 was popular) I probably know as much
> about its internals and development environment as many people here, due to
> having got my hands dirty, albeit 30 years later.

I was messing around on the Apple //e back then myself.  Didn't know 
anything about ASM until many years later (I was *5* back then), but I 
probably could have learned it since the //c and the later version of the 
//e had built-in mini-assemblers.

> In fact I FEEL LIKE I WAS THERE. So my suggestion to newbies is, get 
> your simh on, and tackle some interesting project such as reconstructing 
> an early source for something from the fragmentary surviving pieces, 
> backporting some useful tool to an earlier Unix, or whatever. Just get 
> your hands dirty and it will be an infinitely rewarding experience. 
> Because Unix is AWESOME. Retrocomputing is AWESOME. Simulators are 
> AWESOME. :)

Heck, even v7x86 is probably enough to learn with.

-uso.


From hellwig.geisse at mni.thm.de  Mon Dec 26 08:57:14 2016
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Sun, 25 Dec 2016 23:57:14 +0100
Subject: [TUHS] Musings on PDP-7 Unix
In-Reply-To: <20161225083947.GA28327@minnie.tuhs.org>
References: <20161225083947.GA28327@minnie.tuhs.org>
Message-ID: <1482706634.7877.18.camel@mni.thm.de>

On So, 2016-12-25 at 18:39 +1000, Warren Toomey wrote:
> Filesystem
> ----------
> The implementation of the filesystem is, in some places, quite
> inefficient.
> The free block list is implemented as follows. In each block, there
> are
> 10 free block numbers then a pointer to the next part of the free
> list.
> However, each block can hold 64 block numbers, so why are only 10
> free
> block numbers stored in each block? By using the whole of a block to
> store
> free block numbers, there would actually be more free blocks to use!

Possibly there is a cache for free block numbers
located in the superblock? This is at least in V7
the reason for the limited number of free block
numbers contained in free blocks: if the cache
is to be refilled, the contents of a whole free
block must go into the cache, and this of course
cannot span a whole block, because its size is
only a fraction of the superblock's size.

Hellwig


From peter at rulingia.com  Wed Dec 28 17:14:22 2016
From: peter at rulingia.com (Peter Jeremy)
Date: Wed, 28 Dec 2016 18:14:22 +1100
Subject: [TUHS] merry christmas
In-Reply-To: <alpine.BSF.2.02.1612251712530.65296@frieza.hoshinet.org>
References: <20161225031637.GF12180@mcvoy.com>
 <CAH1jEzaAL-0cEYGzxry4FkJWEZ=+oxQbNhz6WsUoVj03qquq4w@mail.gmail.com>
 <alpine.BSF.2.02.1612251712530.65296@frieza.hoshinet.org>
Message-ID: <20161228071422.GA30016@server.rulingia.com>

On 2016-Dec-25 17:21:31 -0500, Steve Nickolas <usotsuki at buric.co> wrote:
>On Mon, 26 Dec 2016, Nick Downing wrote:
>> I became frustrated with the limitations of both UZI and NOS and decided to
>> port 2.11BSD to the cash register as the next step, my goal was (a) make it
>> cross compile from Linux to PDP-11, (b) check it can build an identical
>> release tape through cross compilation, (c) port it to Z80 using my
>> existing cross compiler.
>
>A Z180 is powerful enough to run 2.11BSD? o.o;

I suspect shoe-horning 2.11BSD onto a Z180 would be difficult - 2.11BSD
on a PDP-11 requires split I+D and has kernel and userland in separate
address spaces.  Even with that, keeping the non-overlay part of the
kernel in 64KB is difficult.  Equivalent Z180 code is going to be much
larger than PDP-11 code.

I'd be happy to be proved wrong.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161228/21e03861/attachment.sig>

From downing.nick at gmail.com  Wed Dec 28 22:24:20 2016
From: downing.nick at gmail.com (Nick Downing)
Date: Wed, 28 Dec 2016 23:24:20 +1100
Subject: [TUHS] merry christmas
In-Reply-To: <20161228071422.GA30016@server.rulingia.com>
References: <20161225031637.GF12180@mcvoy.com>
 <CAH1jEzaAL-0cEYGzxry4FkJWEZ=+oxQbNhz6WsUoVj03qquq4w@mail.gmail.com>
 <alpine.BSF.2.02.1612251712530.65296@frieza.hoshinet.org>
 <20161228071422.GA30016@server.rulingia.com>
Message-ID: <CAH1jEzZVD1Wu+=Z0vSDH-oAoK9mWVy5B6O2WNiEs0DTH5k7x3w@mail.gmail.com>

I will let you know when I get it working :) It's not a current focus,
but I will return to it someday. In the meantime, I'm putting it on
bitbucket, so others will be able to pick it up if they wish. However,
this also isn't my current focus, it's there, but it's not documented.

The IAR compiler on the Z180 supports a memory model similar to the
old "medium" memory model that we used to use with Microsoft or Turbo
C on DOS machines, that is, multiple code segments with a single data
segment. Yes, the Z180 compiled C code is larger than the PDP-11
compiled C code, but luckily you can have multiple code segments,
which you cannot (easily) have on the PDP-11.

Unfortunately code and data segments share the same 64 kbyte logical
address space, so what I did was to partition the address space into 4
kbytes (always mapped, used for interrupt handlers, bank switching
routines, IAR compiler helper routines, etc), 56 kbytes (kernel or
current process data and stack) and 4 kbytes (currently executing
function). The currently executing function couldn't be more than 4
kbytes and couldn't cross a physical 4 kbyte boundary due to the
hardware mapping granularity, but this was acceptable in practice.

I got the Unix V7 clone working OK under this model and then added the
networking, so although it was a bit of a dogs breakfast, it proves
the concept works. My memory management left a fair bit to be desired
(too much work to fix) however I think porting 2.11BSD would solve
this problem since it works in the PDP-11 under split I/D, which has
similar constraints except the 4 kbyte code constraint.

My understanding is 2.11BSD is actually a cut down 4.3BSD running on
the HAL from 2.xxBSD, I would like to audit each change from 4.3BSD to
make sure I agree with it, so essentially my project would be porting
4.3BSD rather than 2.11BSD. But I'd take the networking stack and
possibly a lot more code from 2.11BSD, since it is simplified, for
instance the networking stack does not use SYN cookies.

cheers, Nick

On Wed, Dec 28, 2016 at 6:14 PM, Peter Jeremy <peter at rulingia.com> wrote:
> On 2016-Dec-25 17:21:31 -0500, Steve Nickolas <usotsuki at buric.co> wrote:
>>On Mon, 26 Dec 2016, Nick Downing wrote:
>>> I became frustrated with the limitations of both UZI and NOS and decided to
>>> port 2.11BSD to the cash register as the next step, my goal was (a) make it
>>> cross compile from Linux to PDP-11, (b) check it can build an identical
>>> release tape through cross compilation, (c) port it to Z80 using my
>>> existing cross compiler.
>>
>>A Z180 is powerful enough to run 2.11BSD? o.o;
>
> I suspect shoe-horning 2.11BSD onto a Z180 would be difficult - 2.11BSD
> on a PDP-11 requires split I+D and has kernel and userland in separate
> address spaces.  Even with that, keeping the non-overlay part of the
> kernel in 64KB is difficult.  Equivalent Z180 code is going to be much
> larger than PDP-11 code.
>
> I'd be happy to be proved wrong.
>
> --
> Peter Jeremy


From dave at horsfall.org  Thu Dec 29 09:59:32 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 29 Dec 2016 10:59:32 +1100 (EST)
Subject: [TUHS] Leap Second
Message-ID: <alpine.BSF.2.20.1612291058070.43538@aneurin.horsfall.org>

(Yes, a repeat, but this momentous event only happens every few years.)

The International Earth Rotation Service has announced that there will be 
a Leap Second inserted at 23:59:59 UTC on the 31st December, due to the 
earth slowly slowing down.  It's fun to listen to see how the time beeps 
handle it; will your GPS clock display 23:59:60, or will it go nuts 
(because the programmer was an idiot)?

I actually have a recording of the last one, over at 
www.horsfall.org/leapsecond.webm (yes, I am a tragic geek),

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From peter at rulingia.com  Thu Dec 29 10:21:05 2016
From: peter at rulingia.com (Peter Jeremy)
Date: Thu, 29 Dec 2016 11:21:05 +1100
Subject: [TUHS] Leap Second
In-Reply-To: <alpine.BSF.2.20.1612291058070.43538@aneurin.horsfall.org>
References: <alpine.BSF.2.20.1612291058070.43538@aneurin.horsfall.org>
Message-ID: <20161229002105.GB94858@server.rulingia.com>

On 2016-Dec-29 10:59:32 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>(Yes, a repeat, but this momentous event only happens every few years.)

Actually, they've been more frequent of late.

>The International Earth Rotation Service has announced that there will be 
>a Leap Second inserted at 23:59:59 UTC on the 31st December, due to the 
>earth slowly slowing down.  It's fun to listen to see how the time beeps 
>handle it; will your GPS clock display 23:59:60, or will it go nuts 
>(because the programmer was an idiot)?

Google chose an alternative approach to avoiding the 23:59:60 issue and will
smear the upcoming leap second across the period 2016-12-31 14:00:00 UTC
through 2017-01-01 10:00:00 UTC (see https://developers.google.com/time/smear).
Of course, this means that mixing time.google.com with normal NTP servers
will have "interesting" effects.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161229/c8d492e6/attachment.sig>

From bqt at update.uu.se  Thu Dec 29 12:35:59 2016
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 29 Dec 2016 03:35:59 +0100
Subject: [TUHS] 2.11BSD on a Z180 (was: merry christmas)
In-Reply-To: <mailman.1.1482976801.31902.tuhs@minnie.tuhs.org>
References: <mailman.1.1482976801.31902.tuhs@minnie.tuhs.org>
Message-ID: <c77e8050-faec-626d-9f11-644bad115bd2@update.uu.se>

On 2016-12-29 03:00, Nick Downing <downing.nick at gmail.com> wrote:

> I will let you know when I get
> it working :) It's not a current focus, but I will return to it someday.
> In the meantime, I'm putting it on bitbucket, so others will be able to
> pick it up if they wish. However, this also isn't my current focus, it's
> there, but it's not documented.
 >
> The IAR compiler on the Z180 supports a
> memory model similar to the old "medium" memory model that we used to
> use with Microsoft or Turbo C on DOS machines, that is, multiple code
> segments with a single data segment. Yes, the Z180 compiled C code is
> larger than the PDP-11 compiled C code, but luckily you can have
> multiple code segments, which you cannot (easily) have on the PDP-11.
 >
> Unfortunately code and data segments share the same 64 kbyte logical
> address space, so what I did was to partition the address space into 4
> kbytes (always mapped, used for interrupt handlers, bank switching
> routines, IAR compiler helper routines, etc), 56 kbytes (kernel or
> current process data and stack) and 4 kbytes (currently executing
> function). The currently executing function couldn't be more than 4
> kbytes and couldn't cross a physical 4 kbyte boundary due to the
> hardware mapping granularity, but this was acceptable in practice.
 >
> I got
> the Unix V7 clone working OK under this model and then added the
> networking, so although it was a bit of a dogs breakfast, it proves the
> concept works. My memory management left a fair bit to be desired (too
> much work to fix) however I think porting 2.11BSD would solve this
> problem since it works in the PDP-11 under split I/D, which has similar
> constraints except the 4 kbyte code constraint. My understanding is
> 2.11BSD is actually a cut down 4.3BSD running on the HAL from 2.xxBSD, I
> would like to audit each change from 4.3BSD to make sure I agree with
> it, so essentially my project would be porting 4.3BSD rather than
> 2.11BSD. But I'd take the networking stack and possibly a lot more code
> from 2.11BSD, since it is simplified, for instance the networking stack
> does not use SYN cookies. cheers, Nick

Having written quite some code on the Z180, as well as god knows how 
much code on the PDP-11, I'm going to agree with Peter Jeremy in that I 
do not believe 2.11BSD can be made to run on a Z180. (Well, of course, 
anything is possible, you could just write a 68000-emulator, for 
example, but natively... no.)

Unix V7 is miles from 2.11BSD. Unix V7 can run on very modest PDP-11 
models. 2.11BSD cannot be made to run on a PDP-11 without split I/D 
space, which effectively gives you 128K of address space to play with, 
in addition to the overlaying done with the MMU remappings.
The MMU remappings might be possible to emulate enough with the segment 
registers of the Z180 for the Unix needs, but the split I/D space just 
won't happen.

2.9BSD was the last version (I believe) which ran on non split-I/D machines.

	Johnny

 >
> On Wed, Dec 28, 2016 at 6:14 PM, Peter Jeremy <peter at rulingia.com> wrote:
>> On 2016-Dec-25 17:21:31 -0500, Steve Nickolas <usotsuki at buric.co> wrote:
>>> On Mon, 26 Dec 2016, Nick Downing wrote:
>>>> I became frustrated with the limitations of both UZI and NOS and decided to
>>>> port 2.11BSD to the cash register as the next step, my goal was (a) make it
>>>> cross compile from Linux to PDP-11, (b) check it can build an identical
>>>> release tape through cross compilation, (c) port it to Z80 using my
>>>> existing cross compiler.
>>> A Z180 is powerful enough to run 2.11BSD? o.o;
>> I suspect shoe-horning 2.11BSD onto a Z180 would be difficult - 2.11BSD
>> on a PDP-11 requires split I+D and has kernel and userland in separate
>> address spaces.  Even with that, keeping the non-overlay part of the
>> kernel in 64KB is difficult.  Equivalent Z180 code is going to be much
>> larger than PDP-11 code.
>>
>> I'd be happy to be proved wrong.
>>
>> --
>> Peter Jeremy


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From ron at ronnatalie.com  Fri Dec 30 04:20:28 2016
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 29 Dec 2016 13:20:28 -0500
Subject: [TUHS] 2.11BSD on a Z180 (was: merry christmas)
In-Reply-To: <c77e8050-faec-626d-9f11-644bad115bd2@update.uu.se>
References: <mailman.1.1482976801.31902.tuhs@minnie.tuhs.org>
 <c77e8050-faec-626d-9f11-644bad115bd2@update.uu.se>
Message-ID: <019c01d26200$3c30aa30$b491fe90$@ronnatalie.com>

Yes.   Before the networking code in, the kernels on the non-split I/D machines got by with using a couple of the segments to make code overlays.    The mbufs required a overlay register of their own and once you got the minimal data segment as well as the top one for the stack, you just couldn't do it with 8 total.   With Split I/D you had 8 code and 8 data segments and that you could make work.

It was a boon for me.   I had started with Noel's MIT C Gateway but abandoned it for my own "Little OS" based version (Noel had been exiled to the Bahamas or some warm place and the MIT code was lacking in some necessary featuers for us).   I took all the non-split I/D machines around the lbs... everything from PDP-11/23's and 11/24's up to some 11/34's we had.   Eventually, UNIX got too big for even the 11/70's that were left, and those were turned into ( rather compute heavy) routers as well.

The 11/34's were an another amusing piece of recycling.   A contractor sold those to the government to be graphics remotes for our CDC 7600 mainframe.   Each one had a Vector General graphics station, an 11/34 with a couple of RK05's, a punched card reader, and a DQ11 and 56KB modem.   The contractor couldn't get the things to work with the mainframes, and Mike Muuss's standard answer to extra compute hardware was to put UNIX on it.   We did, and Mike wrote the early version of the BRL CAD for the Vector General (this was 1980, I remember him giving a talk on this at the Univ. of Delaware UUG).     We took the DQ/modems to make an early BRLNET (pre-IP) link.    Late one summer evening Mike and I wrote a version of ASTEROIDS for the system.   We finished about dawn, and when the real ballistic researchers came in that morning to play it they decided our physics was all wrong so by the time we returned later, it had been recoded.    Such was the lab in those days.



From arnold at skeeve.com  Fri Dec 30 05:09:57 2016
From: arnold at skeeve.com (Arnold Robbins)
Date: Thu, 29 Dec 2016 21:09:57 +0200
Subject: [TUHS] Other people I'd like to see on this list
Message-ID: <201612291909.uBTJ9vEA003649@skeeve.com>

Since Larry started the wish-listing of people we'd like to see on the
list, I'll add mine:

* Doug Gwynn
* Chris Torek
* Guy Harris

Anyone know how to track down any of these folks?

My two cents. :-)

Happy New Year everyone,

Arnold


From wkt at tuhs.org  Fri Dec 30 10:24:21 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 30 Dec 2016 10:24:21 +1000
Subject: [TUHS] Also, what missing stuff do we still need to search for?
In-Reply-To: <201612291909.uBTJ9vEA003649@skeeve.com>
References: <201612291909.uBTJ9vEA003649@skeeve.com>
Message-ID: <20161230002421.GA3130@minnie.tuhs.org>

On Thu, Dec 29, 2016 at 09:09:57PM +0200, Arnold Robbins wrote:
> Since Larry started the wish-listing of people we'd like to see on the list.

Also, it's time to ask for any outstanding software, documentation, anecdotes,
information that we still have not yet collected. Anybody with tapes in a
cupboard/under the bed? Anybody with paper documents that have not yet been
scanned in?

Cheers all & Happy New Year,
	Warren


From lm at mcvoy.com  Fri Dec 30 10:28:04 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 29 Dec 2016 16:28:04 -0800
Subject: [TUHS] Also, what missing stuff do we still need to search for?
In-Reply-To: <20161230002421.GA3130@minnie.tuhs.org>
References: <201612291909.uBTJ9vEA003649@skeeve.com>
 <20161230002421.GA3130@minnie.tuhs.org>
Message-ID: <20161230002804.GG26780@mcvoy.com>

On Fri, Dec 30, 2016 at 10:24:21AM +1000, Warren Toomey wrote:
> On Thu, Dec 29, 2016 at 09:09:57PM +0200, Arnold Robbins wrote:
> > Since Larry started the wish-listing of people we'd like to see on the list.
> 
> Also, it's time to ask for any outstanding software, documentation, anecdotes,
> information that we still have not yet collected. Anybody with tapes in a
> cupboard/under the bed? Anybody with paper documents that have not yet been
> scanned in?

I've already asked Clem but I'd love the troff source the network programming
overview (or programmer's guide, whatever it was called it was the intro to
programming with sockets).  The one that Masscomp did.  It was by far the
best version of that stuff I've ever seen.  Be fun to update that or just
post it.

Sun's intro manuals were pretty good.

There isn't any legal way to get the SunOS 4.1.3 source, is there?  Last
4.x release I worked on I believe.

--lm


From wkt at tuhs.org  Fri Dec 30 15:40:22 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 30 Dec 2016 15:40:22 +1000
Subject: [TUHS] Other people I'd like to see on this list
In-Reply-To: <201612291909.uBTJ9vEA003649@skeeve.com>
References: <201612291909.uBTJ9vEA003649@skeeve.com>
Message-ID: <20161230054022.GA14155@minnie.tuhs.org>

On Thu, Dec 29, 2016 at 09:09:57PM +0200, Arnold Robbins wrote:
> Since Larry started the wish-listing of people we'd like to see on the
> list, I'll add mine:
> * Doug Gwynn
> * Chris Torek
> * Guy Harris

Arnold helped me track a couple of these down, and I've sent off e-mails
to them and a few others. One has joined up, I won't say who, but "1969"
and "?" should be clues.

Cheers all & Happy New Year, Warren


From ron at ronnatalie.com  Fri Dec 30 21:02:16 2016
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 30 Dec 2016 06:02:16 -0500
Subject: [TUHS] Other people I'd like to see on this list
In-Reply-To: <20161230054022.GA14155@minnie.tuhs.org>
References: <201612291909.uBTJ9vEA003649@skeeve.com>
 <20161230054022.GA14155@minnie.tuhs.org>
Message-ID: <021e01d2628c$303b6cb0$90b24610$@ronnatalie.com>

Doug's not here?    I thought I mentioned it to him last year sometime.
He only has one "n" in his name, by the way.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Warren Toomey
Sent: Friday, December 30, 2016 12:40 AM
Cc: tuhs at tuhs.org
Subject: Re: [TUHS] Other people I'd like to see on this list

On Thu, Dec 29, 2016 at 09:09:57PM +0200, Arnold Robbins wrote:
> Since Larry started the wish-listing of people we'd like to see on the 
> list, I'll add mine:
> * Doug Gwynn
> * Chris Torek
> * Guy Harris

Arnold helped me track a couple of these down, and I've sent off e-mails to
them and a few others. One has joined up, I won't say who, but "1969"
and "?" should be clues.

Cheers all & Happy New Year, Warren



From arnold at skeeve.com  Fri Dec 30 21:42:17 2016
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 30 Dec 2016 04:42:17 -0700
Subject: [TUHS] Other people I'd like to see on this list
In-Reply-To: <021e01d2628c$303b6cb0$90b24610$@ronnatalie.com>
References: <201612291909.uBTJ9vEA003649@skeeve.com>
 <20161230054022.GA14155@minnie.tuhs.org>
 <021e01d2628c$303b6cb0$90b24610$@ronnatalie.com>
Message-ID: <201612301142.uBUBgHlr001992@freefriends.org>

"Ron Natalie" <ron at ronnatalie.com> wrote:

> Doug's not here?    I thought I mentioned it to him last year sometime.

I haven't seen anything from him in recent memory ...

> He only has one "n" in his name, by the way.

Sorry 'bout that. I couldn't remember for sure.

Arnold


From ron at ronnatalie.com  Fri Dec 30 21:49:06 2016
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 30 Dec 2016 06:49:06 -0500
Subject: [TUHS] Other people I'd like to see on this list
In-Reply-To: <201612301142.uBUBgHlr001992@freefriends.org>
References: <201612291909.uBTJ9vEA003649@skeeve.com>
 <20161230054022.GA14155@minnie.tuhs.org>
 <021e01d2628c$303b6cb0$90b24610$@ronnatalie.com>
 <201612301142.uBUBgHlr001992@freefriends.org>
Message-ID: <023401d26292$bc99f7c0$35cde740$@ronnatalie.com>

I've sent messages to both Doug Gwyn and Chris Torek inviting them to come
here.

-----Original Message-----
From: arnold at skeeve.com [mailto:arnold at skeeve.com] 
Sent: Friday, December 30, 2016 6:42 AM
To: wkt at tuhs.org; ron at ronnatalie.com
Cc: tuhs at tuhs.org
Subject: Re: [TUHS] Other people I'd like to see on this list

"Ron Natalie" <ron at ronnatalie.com> wrote:

> Doug's not here?    I thought I mentioned it to him last year sometime.

I haven't seen anything from him in recent memory ...

> He only has one "n" in his name, by the way.

Sorry 'bout that. I couldn't remember for sure.

Arnold



From imp at bsdimp.com  Sat Dec 31 09:33:01 2016
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 30 Dec 2016 16:33:01 -0700
Subject: [TUHS] Historic Linux versions not on kernel.org
Message-ID: <CANCZdfqcUiXtznQ2GLG1dnkiehATnZgUMP_X_f_piC83DA836Q@mail.gmail.com>

I have a ImageMagic CD that I got back in 1994 that I found in my
garage. It has a bunch of versions of linux that aren't on kernel.org.
The 0.99 series, the 0.98 series and what looks like 1.0 alpha pl14
and pl15.

Is anybody here interested in them?

I have fallen out of contact with the Linux folks, so don't know if
anybody on kernel.org would be interested in these. Does anybody care?

Warner


From wes.parish at paradise.net.nz  Sat Dec 31 10:01:21 2016
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Sat, 31 Dec 2016 13:01:21 +1300 (NZDT)
Subject: [TUHS] Historic Linux versions not on kernel.org
In-Reply-To: <CANCZdfqcUiXtznQ2GLG1dnkiehATnZgUMP_X_f_piC83DA836Q@mail.gmail.com>
References: <CANCZdfqcUiXtznQ2GLG1dnkiehATnZgUMP_X_f_piC83DA836Q@mail.gmail.com>
Message-ID: <1483142481.5866f55183651@www.paradise.net.nz>

There was a site I encountered in 2007-2008 collecting old Linux distros, but I haven't been back since 
then. I've forgotten its name, but I think that could be remedied easily enough. I've also got some 1994-
6 Linux CDs - FWLIW, I put an SLS distro on the Bochs site in 2002-3: I don't know what's happened 
since then.

Wesley Parish

Quoting Warner Losh <imp at bsdimp.com>:

> I have a ImageMagic CD that I got back in 1994 that I found in my
> garage. It has a bunch of versions of linux that aren't on kernel.org.
> The 0.99 series, the 0.98 series and what looks like 1.0 alpha pl14
> and pl15.
> 
> Is anybody here interested in them?
> 
> I have fallen out of contact with the Linux folks, so don't know if
> anybody on kernel.org would be interested in these. Does anybody care?
> 
> Warner
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn


From downing.nick at gmail.com  Sat Dec 31 11:35:54 2016
From: downing.nick at gmail.com (Nick Downing)
Date: Sat, 31 Dec 2016 12:35:54 +1100
Subject: [TUHS] 2.11BSD on a Z180 (was: merry christmas)
In-Reply-To: <019c01d26200$3c30aa30$b491fe90$@ronnatalie.com>
References: <mailman.1.1482976801.31902.tuhs@minnie.tuhs.org>
 <c77e8050-faec-626d-9f11-644bad115bd2@update.uu.se>
 <019c01d26200$3c30aa30$b491fe90$@ronnatalie.com>
Message-ID: <CAH1jEzZMqE1UvtLXQ1fkj5Tb7UV_gSExs9uVhW98a-O1YtTtaw@mail.gmail.com>

Yes, OK, I see that there are unanticipated problems with the 2BSD
Z180 port. Basically I had thought that the kernel ran like a
userspace program, I knew there might be overlays involved with the
code space, but I hadn't realized there are also overlays with the
data space (from what you say I guess the mbufs are accessed using a
kind of a "far" pointer). Anyway, I will check into it further.

Based on the previous day's conversations I got inspired to continue
the project, I got out the 2.11BSD toolchain which I had ported to a
modern machine as a cross compiler (actually Mac OSX although I was
using it like a poor man's Linux)... started again using Linux and a
different way of building that would require less change to the
Makefiles, fixed all compile warnings, fixed many bugs, it now
produces:
bin/ar
bin/as
bin/cc
bin/ld
bin/nm
lib/c0
lib/c1
lib/c2
lib/cpp
lib/crt0.o
lib/libc.a
lib/mcrt0.o
usr/bin/lorder
usr/bin/ranlib
usr/lib/libc_p.a

The executables above are x86-64 Linux ELF executables that work alike
to the corresponding PDP-11 2.11BSD a.out executables, except that
hard coded paths like /usr/include or /usr/lib have an extra prefix
added to them, at the moment it works like this:
  /home/nick/src/2bsd_cc.git/bin/cc contains a hard coded executable
path of /home/nick/2bsd_cc.git/lib.cpp
  /home/nick/src/2bsd_cc.git/lib/cpp contains a hard coded include
path of /home/nick/src/2bsd_cc.git/usr/include
and so on, these are set up at build time. Changes to the makefiles
are pretty minimal, in the libc source directory I had to change
things a bit to make it refer to the cross compiler rather than the
native compiler, by changing stuff like "cc" to "${CC}" and adding
stuff like:
  DESTDIR=../../..
  CC=${DESTDIR}/bin/cc
and so forth. The revised toolchain if compiled with -DPDP11 will be
more-or-less as original, so it should not break the self-hosted
compile system (up to possible minor breakage because I haven't tested
this mode yet), for instance if the original code looked like this:
  int some_function();
  ...
  some_function(a) int a; { some code }
then it would now look like this:
  int some_function PARAMS((int a));
  ...
  int some_function(a) int a; { some code }
where the PARAMS macro is set up appropriately depending on whether we
are compiling on the PDP-11 or the modern Linux machine.

One significant difference with the cross toolchain is that I have
translated the PDP-11 assembler /bin/as from assembler into C. So I
guess it will be slightly slower and use slightly more memory, but I
doubt the difference would be noticeable in practice. In future when I
merge my changes into 2.11BSD and fix any breakage, I'll probably just
delete the as0.s, as2.s and replace with as0.c, as2.c. Also I fixed
some memory allocation bugs and illegal pointer dereferences in the
other utilities that just happened to be benign on PDP-11.

Anyway, I'm pretty stoked because after successfully building the C
library, etc, with the cross toolchain, I compiled a hello world
program and copied it into the running simh system, it executed
without problems. When I compiled the same program on the self-hosted
compile system in the running simh system everything was the same
except the final executable, I will have to pay a bit of attention to
the lorder and tsort stuff when it builds the C library, to make sure
everything comes out in a predictable way for comparison.

I will test this more extensively in the coming weeks, e.g. by
building a kernel using the cross toolchain and checking it's the
same. I am nearly ready to put the cross toolchain on bitbucket, but I
just want to take a bit of care before doing "git commit" to make sure
it's not capturing any junk I don't want in there, so I will do it
later. I had better pay some attention to the family :) Happy new year
everyone.

cheers, Nick

On Fri, Dec 30, 2016 at 5:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
> Yes.   Before the networking code in, the kernels on the non-split I/D machines got by with using a couple of the segments to make code overlays.    The mbufs required a overlay register of their own and once you got the minimal data segment as well as the top one for the stack, you just couldn't do it with 8 total.   With Split I/D you had 8 code and 8 data segments and that you could make work.
>
> It was a boon for me.   I had started with Noel's MIT C Gateway but abandoned it for my own "Little OS" based version (Noel had been exiled to the Bahamas or some warm place and the MIT code was lacking in some necessary featuers for us).   I took all the non-split I/D machines around the lbs... everything from PDP-11/23's and 11/24's up to some 11/34's we had.   Eventually, UNIX got too big for even the 11/70's that were left, and those were turned into ( rather compute heavy) routers as well.
>
> The 11/34's were an another amusing piece of recycling.   A contractor sold those to the government to be graphics remotes for our CDC 7600 mainframe.   Each one had a Vector General graphics station, an 11/34 with a couple of RK05's, a punched card reader, and a DQ11 and 56KB modem.   The contractor couldn't get the things to work with the mainframes, and Mike Muuss's standard answer to extra compute hardware was to put UNIX on it.   We did, and Mike wrote the early version of the BRL CAD for the Vector General (this was 1980, I remember him giving a talk on this at the Univ. of Delaware UUG).     We took the DQ/modems to make an early BRLNET (pre-IP) link.    Late one summer evening Mike and I wrote a version of ASTEROIDS for the system.   We finished about dawn, and when the real ballistic researchers came in that morning to play it they decided our physics was all wrong so by the time we returned later, it had been recoded.    Such was the lab in those days.
>


From rmswierczek at gmail.com  Sat Dec 31 15:18:41 2016
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Sat, 31 Dec 2016 00:18:41 -0500
Subject: [TUHS] Historic Linux versions not on kernel.org
In-Reply-To: <1483142481.5866f55183651@www.paradise.net.nz>
References: <CANCZdfqcUiXtznQ2GLG1dnkiehATnZgUMP_X_f_piC83DA836Q@mail.gmail.com>
 <1483142481.5866f55183651@www.paradise.net.nz>
Message-ID: <CAAFR5pZ_aS76HyOi-cGO-Nx_tXot0XmhZgUmeA7EFoiwYF9K3Q@mail.gmail.com>

> There was a site I encountered in 2007-2008 collecting old Linux distros, but I haven't been back since then.

These two sites come to mind.  Definitely worth exploring.

http://www.oldlinux.org/
http://www.ibiblio.org/pub/historic-linux/distributions/


From rmswierczek at gmail.com  Sat Dec 31 16:11:48 2016
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Sat, 31 Dec 2016 01:11:48 -0500
Subject: [TUHS] 2.11BSD on a Z180 (was: merry christmas)
In-Reply-To: <CAH1jEzZMqE1UvtLXQ1fkj5Tb7UV_gSExs9uVhW98a-O1YtTtaw@mail.gmail.com>
References: <mailman.1.1482976801.31902.tuhs@minnie.tuhs.org>
 <c77e8050-faec-626d-9f11-644bad115bd2@update.uu.se>
 <019c01d26200$3c30aa30$b491fe90$@ronnatalie.com>
 <CAH1jEzZMqE1UvtLXQ1fkj5Tb7UV_gSExs9uVhW98a-O1YtTtaw@mail.gmail.com>
Message-ID: <CAAFR5pZc9CEhXxFH0hh24qyx_MtSXrJwDo1h_EjGyA1ONvs1XQ@mail.gmail.com>

Have you looked into apout?  It is a user level simulator for Unix
a.out binaries:
https://github.com/DoctorWkt/unix-jun72/tree/master/tools/apout

I have used it successfully for running some standalone binaries such
as (~/v1/fs/root)/bin/as.


From downing.nick at gmail.com  Sat Dec 31 20:27:48 2016
From: downing.nick at gmail.com (Nick Downing)
Date: Sat, 31 Dec 2016 21:27:48 +1100
Subject: [TUHS] 2.11BSD on a Z180 (was: merry christmas)
In-Reply-To: <CAAFR5pZc9CEhXxFH0hh24qyx_MtSXrJwDo1h_EjGyA1ONvs1XQ@mail.gmail.com>
References: <mailman.1.1482976801.31902.tuhs@minnie.tuhs.org>
 <c77e8050-faec-626d-9f11-644bad115bd2@update.uu.se>
 <019c01d26200$3c30aa30$b491fe90$@ronnatalie.com>
 <CAH1jEzZMqE1UvtLXQ1fkj5Tb7UV_gSExs9uVhW98a-O1YtTtaw@mail.gmail.com>
 <CAAFR5pZc9CEhXxFH0hh24qyx_MtSXrJwDo1h_EjGyA1ONvs1XQ@mail.gmail.com>
Message-ID: <CAH1jEzYwe56JiFJhrVkBHETt=_MyT+uMYy64DvuxARRva+QNhA@mail.gmail.com>

Yes, I am aware of the concept, I had used a similar emulator to run CP/M
binaries on MS-DOS, specifically Microsoft Macro-80, Link-80 and Basic-80
compiler. Yes I was doing cash registers that far back :) :) It is really
convenient having access to your host filesystem (compared with attaching a
simh formatted emulated tape image, tarring to/from it, and converting
to/rom simh format and plain binary as I did yesterday).

I hadn't seen apout but it is a good idea, I was toying with doing the same
thing by cross compiling the 2.11BSD kernel to create something like User
Mode Linux (but then adding user mode PDP-11 CPU emulation since it does
not make sense to compile x86-64 2.11BSD userspace executables even though
it is theoretically possible). I don't know how stable is the ABI between
Unix V7 and BSD or between BSD versions. I suspect it is very similar but
there would be differences in things like struct stat which are bound to
cause breakage. So I think it has to run the correct kernel to get the
correct ABI, and in turn that kernel has to have null or pass thru drivers
to access the host facilities. I do hope to get this working someday,
especially since a full cross compile of 2.11BSD includes the f77 stuff
which cannot reasonably be compiled on a modern system given the compiler
is not written in C, I think it is PDP-11 assembly.

For now I am trying to reduce the amount of stuff I need to change, so my
idea is to modify simh to allow switching between Z80 and PDP-11
instruction sets (I could use the PSW so that it can process an interrupt
or syscall in PDP-11 mode and transparently return to Z80 mode when it
restores the PSW) and then just convert little pieces at a time, I could
compile a Z80 hello world program and then link it against the PDP-11 C
library for instance. So this puts off having to deal with MMU or driver
issues till later on. I am looking at changing /lib/c1 and /bin/as to add a
.z80 directive and the z80 instruction set.

cheers, Nick

On 31/12/2016 5:19 PM, "Robert Swierczek" <rmswierczek at gmail.com> wrote:

> Have you looked into apout?  It is a user level simulator for Unix
> a.out binaries:
> https://github.com/DoctorWkt/unix-jun72/tree/master/tools/apout
>
> I have used it successfully for running some standalone binaries such
> as (~/v1/fs/root)/bin/as.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161231/8bb33261/attachment.html>

From michael at kjorling.se  Sat Dec 31 21:13:39 2016
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 31 Dec 2016 11:13:39 +0000
Subject: [TUHS] Historic Linux versions not on kernel.org
In-Reply-To: <CANCZdfqcUiXtznQ2GLG1dnkiehATnZgUMP_X_f_piC83DA836Q@mail.gmail.com>
References: <CANCZdfqcUiXtznQ2GLG1dnkiehATnZgUMP_X_f_piC83DA836Q@mail.gmail.com>
Message-ID: <20161231111339.GK576@yeono.kjorling.se>

On 30 Dec 2016 16:33 -0700, from imp at bsdimp.com (Warner Losh):
> I have a ImageMagic CD that I got back in 1994 that I found in my
> garage. It has a bunch of versions of linux that aren't on kernel.org.
> The 0.99 series, the 0.98 series and what looks like 1.0 alpha pl14
> and pl15.
> 
> Is anybody here interested in them?

I might be colored by the fact that I'm running Linux myself, but I'd
say that those are almost certainly worth preserving somehow,
somewhere. Linux and OS X are the Unix-like systems people are most
likely to come in contact with these days, and preserving their
history seems worthwhile. Linux' is probably easier than that of OS X
at least outside of Apple.

That said, at least the 0.99 series _does_ seem to be available on
kernel.org: https://www.kernel.org/pub/linux/kernel/Historic/v0.99/
has what looks like every version from 0.99 proper to 0.99.15. I'm not
finding 0.98 anywhere, though, nor anything like 1.0pl14 (but I do
notice a patchset to 1.0pl15 in the kernel/v1.0 directory). There are
also 0.0x and 0.1x versions there under kernel/Historic{,/old-versions}.
So it's definitely a mixed bag.

I would suggest contacting the kernel.org folks and ask if they are
interested in receiving the versions you have. You just might have
found a little historical treasure trove of early Linux development.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From grawity at gmail.com  Sat Dec 31 21:30:50 2016
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Sat, 31 Dec 2016 13:30:50 +0200
Subject: [TUHS] Historic Linux versions not on kernel.org
In-Reply-To: <20161231111339.GK576@yeono.kjorling.se>
References: <CANCZdfqcUiXtznQ2GLG1dnkiehATnZgUMP_X_f_piC83DA836Q@mail.gmail.com>
 <20161231111339.GK576@yeono.kjorling.se>
Message-ID: <CAPWNY8UVjJOwXNFLp3pUqc_5vW2KoHCg1ajshUr3UH7hfai0nA@mail.gmail.com>

On Sat, Dec 31, 2016 at 1:13 PM, Michael Kjörling <michael at kjorling.se>
wrote:

> On 30 Dec 2016 16:33 -0700, from imp at bsdimp.com (Warner Losh):
> > I have a ImageMagic CD that I got back in 1994 that I found in my
> > garage. It has a bunch of versions of linux that aren't on kernel.org.
> > The 0.99 series, the 0.98 series and what looks like 1.0 alpha pl14
> > and pl15.
> >
> > Is anybody here interested in them?
>
> I might be colored by the fact that I'm running Linux myself, but I'd
> say that those are almost certainly worth preserving somehow,
> somewhere. Linux and OS X are the Unix-like systems people are most
> likely to come in contact with these days, and preserving their
> history seems worthwhile. Linux' is probably easier than that of OS X
> at least outside of Apple.
>
> That said, at least the 0.99 series _does_ seem to be available on
> kernel.org: https://www.kernel.org/pub/linux/kernel/Historic/v0.99/
> has what looks like every version from 0.99 proper to 0.99.15. I'm not
> finding 0.98 anywhere, though, nor anything like 1.0pl14 (but I do
> notice a patchset to 1.0pl15 in the kernel/v1.0 directory). There are
> also 0.0x and 0.1x versions there under kernel/Historic{,/old-versions}.
> So it's definitely a mixed bag.
>

v0.98 does seem to be present in this Git repository
<https://archive.org/details/git-history-of-linux> – with Linus'
commentary, too.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161231/cf2f227b/attachment.html>

