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: 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: <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: 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 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: 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: <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr> <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl> Message-ID: 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 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: 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: References: <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr> <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl> 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: <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr> <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl> <20161201153059.GL2620@mcvoy.com> Message-ID: below... On Thu, Dec 1, 2016 at 10:30 AM, Larry McVoy 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: 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: References: <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr> <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl> Message-ID: 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: References: <05B6D110-6217-4070-A83D-AC0DA4CA90E8@planet.nl> 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> <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: References: <0f3795f4-fb98-3370-510c-347a272dddae@aueb.gr> <38CA85C9-C005-49C5-8BD5-3FC65FC170BF@planet.nl> Message-ID: below... On Thu, Dec 1, 2016 at 3:13 PM, Paul Ruizendaal 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: 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> <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl> <20161201210121.GU2620@mcvoy.com> Message-ID: > 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> <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl> Message-ID: below On Thu, Dec 1, 2016 at 3:57 PM, Paul Ruizendaal 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: 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> <0BF9ECEC-9919-4D2C-AE41-520143EFADCC@planet.nl> <20161201210121.GU2620@mcvoy.com> Message-ID: On Thu, Dec 1, 2016 at 4:01 PM, Larry McVoy 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: 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: 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: 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: References: 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: <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: References: Message-ID: 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 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" 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: ​below....​ On Wed, Dec 7, 2016 at 11:46 AM, Erik E. Fair 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: 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: 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: 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: References: <20161207201203.9E2BF18C07B@mercury.lcs.mit.edu> Message-ID: <58493876.1W9NvDfq/mBC2kze%schily@schily.net> Earl Baugh 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: On Thu, Dec 8, 2016 at 5:39 AM, Joerg Schilling 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: 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: References: 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: 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: <07a801d25171$8b473660$a1d5a320$@ronnatalie.com> Message-ID: 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: References: Message-ID: <633b4c57-b7c8-e9aa-540c-084582a38704@update.uu.se> On 2016-12-08 18:18, Paul Ruizendaal 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: <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: <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: *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: References: 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 To: The Eunuchs Hysterical Society 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: References: 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: 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: References: <07a801d25171$8b473660$a1d5a320$@ronnatalie.com> Message-ID: <584a869c.oO1JvvacT4DqiEYq%schily@schily.net> Chet Ramey 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: <07a801d25171$8b473660$a1d5a320$@ronnatalie.com> <584a869c.oO1JvvacT4DqiEYq%schily@schily.net> Message-ID: > 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: <07a801d25171$8b473660$a1d5a320$@ronnatalie.com> <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: 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" To: 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: 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" To:"TUHS main list" 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: 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: 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" > > To: > "TUHS main list" > 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: On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa 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: 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: On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa 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: 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: References: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu> Message-ID: On Mon, Dec 19, 2016 at 3:59 PM, Clem Cole wrote: > > On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa > 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: 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: References: <20161219201031.3259D18C0A1@mercury.lcs.mit.edu> Message-ID: On Mon, Dec 19, 2016 at 4:11 PM, Dan Cross 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: 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: Noel Chiappa 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 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: On Tue, Dec 20, 2016 at 8:05 AM, Noel Chiappa 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: 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: References: <20161220130553.15FDC18C098@mercury.lcs.mit.edu> 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: 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> <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> <006701d25ada$b64262a0$22c727e0$@ronnatalie.com> <20161220160941.GS11813@mcvoy.com> Message-ID: On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy 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: 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: References: <20161220130553.15FDC18C098@mercury.lcs.mit.edu> <006701d25ada$b64262a0$22c727e0$@ronnatalie.com> <20161220160941.GS11813@mcvoy.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 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: 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> <006701d25ada$b64262a0$22c727e0$@ronnatalie.com> <20161220160941.GS11813@mcvoy.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: Message-ID: 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" To: "Larry McVoy" Cc: "TUHS main list" , "Noel Chiappa" 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 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: 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: References: Message-ID: touchė On Tue, Dec 20, 2016 at 3:23 PM, Steve Johnson 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" > > To: > "Larry McVoy" > Cc: > "TUHS main list" , "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 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: 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: Noel Chiappa 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 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: 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: On Wed, Dec 21, 2016 at 2:33 PM, 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 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: References: <20161221090327.GA21190@minnie.tuhs.org> 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 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> <1482331261.612450.825968641.1F9509A8@webmail.messagingengine.com> Message-ID: 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 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 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: 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: References: <20161221090327.GA21190@minnie.tuhs.org> <1482331261.612450.825968641.1F9509A8@webmail.messagingengine.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 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 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: 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: References: 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: <20161221203720.GH20777@yeono.kjorling.se> Message-ID: 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: <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: References: <20161221090327.GA21190@minnie.tuhs.org> <1482331261.612450.825968641.1F9509A8@webmail.messagingengine.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 : > 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 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 > 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 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: 2016-12-22 10:22 GMT+01:00 Joerg Schilling : > Diomidis Spinellis 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: 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 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 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//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: On Fri, Dec 23, 2016 at 7:50 AM, Noel Chiappa 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: 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: below... On Fri, Dec 23, 2016 at 5:27 AM, Joerg Schilling wrote: > Diomidis Spinellis 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//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: 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: 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 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: 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: 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: References: 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: References: Message-ID: On Fri, Dec 23, 2016 at 3:08 PM, Dave Horsfall 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: 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: 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" 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: 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: References: <20161225031637.GF12180@mcvoy.com> Message-ID: 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. > 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; > 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: References: <20161225031637.GF12180@mcvoy.com> Message-ID: <20161228071422.GA30016@server.rulingia.com> On 2016-Dec-25 17:21:31 -0500, Steve Nickolas 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: 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> <20161228071422.GA30016@server.rulingia.com> Message-ID: 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 wrote: > On 2016-Dec-25 17:21:31 -0500, Steve Nickolas 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: (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: References: Message-ID: <20161229002105.GB94858@server.rulingia.com> On 2016-Dec-29 10:59:32 +1100, Dave Horsfall 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: 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: References: Message-ID: On 2016-12-29 03:00, Nick Downing 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 wrote: >> On 2016-Dec-25 17:21:31 -0500, Steve Nickolas 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: References: 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" 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" 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: 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: References: 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 : > 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: <019c01d26200$3c30aa30$b491fe90$@ronnatalie.com> Message-ID: 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 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: <1483142481.5866f55183651@www.paradise.net.nz> Message-ID: > 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: References: <019c01d26200$3c30aa30$b491fe90$@ronnatalie.com> Message-ID: 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: References: <019c01d26200$3c30aa30$b491fe90$@ronnatalie.com> Message-ID: 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" 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: 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: References: 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: <20161231111339.GK576@yeono.kjorling.se> Message-ID: On Sat, Dec 31, 2016 at 1:13 PM, Michael Kjörling 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 – with Linus' commentary, too. -- Mantas Mikulėnas -------------- next part -------------- An HTML attachment was scrubbed... URL: