From wkt at tuhs.org Thu Apr 2 21:54:08 2020 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 02 Apr 2020 21:54:08 +1000 Subject: [TUHS] Stdio and ABIs Message-ID: https://fingolfin.org/blog/20200327/stdio-abi.html An interesting look at the history of stdio and subsequent ABI choices. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sat Apr 4 04:33:15 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 3 Apr 2020 20:33:15 +0200 Subject: [TUHS] Research PBX legacy Message-ID: <1088CB8E-C53F-474B-9831-9890F75E5882@planet.nl> About a year ago the Research telephone switch came up on this list. Rob Pike wrote: "But the PBX story is correct. To demonstrate how message passing was a good model for a switching system, in particular to make a point to the switching systems division of Bell Labs/AT&T, Ken and Joe bought a commercial PBX and swapped out its processor for a PDP-11/23 (I think), and programmed it up. It was just before I arrived there but I was given the impression it had the desired strategic influence on Indian Hill. The feature we all loved it for was that instead of ringing the phone in the Unix room when you got a call, it would announce your name through the voice synthesizer: "Phone call for Ken." "Phone call for Joe". One rapidly stopped even hearing the announcement if it didn't end with your name.” I’ve been having an off list discussion with Bill Marshall and this PBX was influential in another way as well. First of all, Bill can confirm that it indeed was a 11/23, the same racks were used for Datakit switches. He also remembered that the software for this PDP-11 went by the nickname of “TPC” - for Tiny Phone Company. Lee McMahon was on the team writing TPC. The first software for the Datakit switch was written by Greg Chesson and was called “CMC” (for ‘Common Control’). There are still some references to CMC in the 8th Edition source code. This first software was later replaced by new code designed by Lee McMahon that was modelled after TPC. This new code was named “TDK”. This, too, can be seen in the 8th Edition source. The TDK protocols for building and releasing a Datakit virtual circuit appear to have been in use into the 1990’s. From doug at cs.dartmouth.edu Sat Apr 4 13:14:16 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 03 Apr 2020 23:14:16 -0400 Subject: [TUHS] Research PBX legacy Message-ID: <202004040314.0343EGgH068467@tahoe.cs.Dartmouth.EDU> Prologue to TPC. Bob Morris did a visiting-researcher stint at AT&T, where he became aware of infelicitous software architure proposed for ESS 5. He thought Research could do it better. Ken, Joe, and Lee bit. Lee's architecture was indeed novel: every device in the system, right down to each touch-tone button, was modeled as a process. Only after the clean model was working were some processes--notably the buttons--jammed together to cinch in the process table. The team got the switch working in a matter of months--in time to demonstrate it to Indian Hill before ESS was irrevocably set in stone. ESS architecture was indeed rethought, taking some ideas from TPC. TPC was named after "TPC, The Phone Company" in the 1967 film, "The President's Analyst". Doug From emu at e-bbes.com Sat Apr 4 22:56:14 2020 From: emu at e-bbes.com (emanuel stiebler) Date: Sat, 4 Apr 2020 08:56:14 -0400 Subject: [TUHS] 8th Edition timeline In-Reply-To: References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> Message-ID: <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com> On 2020-03-30 05:06, Rob Pike wrote: > I've looked through my notes and unfortunately there's very little > about this as the notes are mostly about graphics and physics. I wouldn't mind seeing the note baout graphics, even if not on topic for this group ... From meillo at marmaro.de Sun Apr 5 01:05:26 2020 From: meillo at marmaro.de (markus schnalke) Date: Sat, 04 Apr 2020 17:05:26 +0200 Subject: [TUHS] First book on Unix for general readership Message-ID: <1jKkMQ-2hN-00@marmaro.de> Hoi, found on Wikipedia: As well as the Bourne shell, he wrote the adb debugger and The UNIX System, the second book on the UNIX system, intended for a general readership. https://en.wikipedia.org/wiki/Stephen_R._Bourne Thus I now wonder what the first book on Unix, intended for a general readership was. Bourne's book was published 1983. (``The UNIX Programming Environment'' was published 1984.) Was it Banahan and Rutter's ``UNIX -- the Book''? It says 1982. Could anyone share some background on that one? (The authors were from Bradford University.) I only have the German translation by Axel T. Schreiner, dated 1984. Haven't read the English original, but Schreiner's version definitely is worth to read (if you speak German). He added lots of footnotes, and it becomes apparent that he knows the system better than the authors. ;-) I'd like to get an understanding of the books in relation to each other. How does the Banahan/Rutter book fit into the picture? Why didn't Bell Labs write a user's book earlier? Were Bourne's and Kernighan/Pike's books reactions to it? meillo From cym224 at gmail.com Sun Apr 5 01:48:15 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Sat, 4 Apr 2020 11:48:15 -0400 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <1jKkMQ-2hN-00@marmaro.de> References: <1jKkMQ-2hN-00@marmaro.de> Message-ID: <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com> On 04/04/20 11:05, markus schnalke wrote (in part): > Thus I now wonder what the first book on Unix, intended for a general > readership was. Not to be overly pedantic but what would be a "general readership"? For example, I understand that the patent dep't was an early Unix customer. Would they been a general readership (and how were they taught)? (I would think that many of today's grunt-and-poke UI generation would have difficulty with a cli.) N. From michael at kjorling.se Sun Apr 5 02:12:01 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 4 Apr 2020 16:12:01 +0000 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <1jKkMQ-2hN-00@marmaro.de> References: <1jKkMQ-2hN-00@marmaro.de> Message-ID: <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> On 4 Apr 2020 17:05 +0200, from meillo at marmaro.de (markus schnalke): > found on Wikipedia: > > As well as the Bourne shell, he wrote the adb debugger > and The UNIX System, the second book on the UNIX system, > intended for a general readership. > > https://en.wikipedia.org/wiki/Stephen_R._Bourne > > Thus I now wonder what the first book on Unix, intended for a > general readership was. I would be careful with that claim. First, it appears to lack a citation. (Someone here might be able to help with that.) Second, once you unpack it, the claim itself can be parsed in two ways, yielding quite different meanings. One way of parsing the claim is that Bourne wrote the book _The UNIX System_ which was the second book on the UNIX system. It was also a book which was intended for a general readership, presumably thereby setting it apart from the first book which was not intended for a general readership. The other way of parsing the claim is that he wrote the book _The UNIX System_ which was second in the set of intended-for-a-general-readership books on the UNIX system (as opposed to the set of books on the UNIX system which were intended for other than a general readership, or for _any_ readership, of which there may have been any number prior to this book), thereby setting it apart only from the first book on the UNIX system intended for a general readership. I'm not a good enough UNIX historian to know which meaning is correct. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From meillo at marmaro.de Sun Apr 5 02:45:30 2020 From: meillo at marmaro.de (markus schnalke) Date: Sat, 04 Apr 2020 18:45:30 +0200 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> Message-ID: <1jKlvG-4JB-00@marmaro.de> Hoi. [2020-04-04 16:12] Michael Kjörling > On 4 Apr 2020 17:05 +0200, from meillo at marmaro.de (markus schnalke): > > found on Wikipedia: > > > > As well as the Bourne shell, he wrote the adb debugger > > and The UNIX System, the second book on the UNIX system, > > intended for a general readership. > > > > https://en.wikipedia.org/wiki/Stephen_R._Bourne > > > > Thus I now wonder what the first book on Unix, intended for a > > general readership was. > > I would be careful with that claim. > > First, it appears to lack a citation. (Someone here might be able to help > with that.) That was my thought already. I hope to get a citation out of this mail thread, or information to remove this claim. But that was only what started my interest in the situation around the very first Unix books. Especially the Banahan/Rutter book caught my interest, as I cannot really fit it into the picture of my current understanding. (I've never read (or forgot) about the University of Bredford in the early Unix context.) > Second, once you unpack it, the claim itself can be parsed in two ways, > yielding quite different meanings. You're right. I directly assumed that ``the second book that was intended for genereal readership (besides several earlier books for special readership)'' was meant. But now that you bring this question up, I'm no longer sure about earlier books that describe the Unix system in general, not only single aspects of it. Besides, we quickly run into the question what a book is. Is Lions' Book a book? Are the manuals books? Well, as I wrote above, although this claim in the Wikipedia started it all up for me, I'm not so much interested in validating or falsifying it, but rather like to know more about the situation in general, to further improve my understanding of the time back then. :-) meillo From imp at bsdimp.com Sun Apr 5 03:32:17 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 4 Apr 2020 11:32:17 -0600 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <1jKkMQ-2hN-00@marmaro.de> References: <1jKkMQ-2hN-00@marmaro.de> Message-ID: On Sat, Apr 4, 2020, 9:19 AM markus schnalke wrote: > Hoi, > > found on Wikipedia: > > As well as the Bourne shell, he wrote the adb debugger > and The UNIX System, the second book on the UNIX system, > intended for a general readership. > > https://en.wikipedia.org/wiki/Stephen_R._Bourne > > Thus I now wonder what the first book on Unix, intended for a > general readership was. > > Bourne's book was published 1983. > > (``The UNIX Programming Environment'' was published 1984.) > > > Was it Banahan and Rutter's ``UNIX -- the Book''? It says 1982. > > Could anyone share some background on that one? (The authors were > from Bradford University.) > > I only have the German translation by Axel T. Schreiner, dated > 1984. Haven't read the English original, but Schreiner's version > definitely is worth to read (if you speak German). He added lots > of footnotes, and it becomes apparent that he knows the system > better than the authors. ;-) > > > I'd like to get an understanding of the books in relation to each > other. How does the Banahan/Rutter book fit into the picture? Why > didn't Bell Labs write a user's book earlier? Were Bourne's and > Kernighan/Pike's books reactions to it? > All good questions. I just bought both of these 9n ebay (there are several copies available for <$10 so I didn't feel bad about sniping a rarity from others in this group). But I don't know the back stories. Warner > meillo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noel.hunt at gmail.com Sun Apr 5 05:57:12 2020 From: noel.hunt at gmail.com (Noel Hunt) Date: Sun, 5 Apr 2020 05:57:12 +1000 Subject: [TUHS] 8th Edition timeline In-Reply-To: <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com> References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com> Message-ID: I would be interested too. That was a seminal time with the proliferation of graphical programs, such as jim, pads/pi, proof, the sophisticated menus of 'mhit.c' etc. It is curious that little if any of that code made the transition to Plan9 (apart from sam, nee jim). On Sun, Apr 5, 2020 at 12:19 AM emanuel stiebler wrote: > On 2020-03-30 05:06, Rob Pike wrote: > > I've looked through my notes and unfortunately there's very little > > about this as the notes are mostly about graphics and physics. > > I wouldn't mind seeing the note baout graphics, even if not on topic for > this group ... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Apr 5 07:32:22 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 5 Apr 2020 07:32:22 +1000 Subject: [TUHS] 8th Edition timeline In-Reply-To: References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com> Message-ID: Sam wasn't nee jim. Jim was a toy, sam is a serious editor. My notebooks are hundreds of pages of figuring stuff out. Perhaps valuable information to historians, but not easily compressed for this forum. -rob On Sun, Apr 5, 2020 at 5:57 AM Noel Hunt wrote: > > I would be interested too. That was a seminal time with the > proliferation of graphical programs, such as jim, pads/pi, > proof, the sophisticated menus of 'mhit.c' etc. It is curious > that little if any of that code made the transition to Plan9 > (apart from sam, nee jim). > > > On Sun, Apr 5, 2020 at 12:19 AM emanuel stiebler wrote: >> >> On 2020-03-30 05:06, Rob Pike wrote: >> > I've looked through my notes and unfortunately there's very little >> > about this as the notes are mostly about graphics and physics. >> >> I wouldn't mind seeing the note baout graphics, even if not on topic for >> this group ... From noel.hunt at gmail.com Sun Apr 5 08:39:28 2020 From: noel.hunt at gmail.com (Noel Hunt) Date: Sun, 5 Apr 2020 08:39:28 +1000 Subject: [TUHS] 8th Edition timeline In-Reply-To: References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com> Message-ID: > Sam wasn't nee jim. Jim was a toy, sam is a serious editor. I don't doubt that, as a long-time user of sam (and jim initially, 30 or so years ago), but it is interesting to see the gradual sophistication of, say, the frame library presumably in response to changes in hardware, and so on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sun Apr 5 08:41:31 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 04 Apr 2020 18:41:31 -0400 Subject: [TUHS] First book on Unix for general readership Message-ID: <202004042241.034MfVJd020049@tahoe.cs.Dartmouth.EDU> Another book from the same era--quite good--is A Unix Primer by Ann Nichols Lomuto and Nico Lomuto, copyright 1983. Before the title page appears an interesting endorsement: "Prentice-Hall Software Series, Brian Kernighan, advisor Doug From imp at bsdimp.com Sun Apr 5 10:53:52 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 4 Apr 2020 18:53:52 -0600 Subject: [TUHS] Xenix-11 Images Message-ID: Crazy longshot post, part 27 in an infinite series Are there any Xenix-11 images (boot tapes or disk images) around? My googling skillz aren't mad enough to find this. I've seen the Xenix 86 image in the archive that was copied from pce's image warehouse which is cool and the generation of code I'm looking for, but is for 8086 machines... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From aksr at t-com.me Sun Apr 5 11:38:21 2020 From: aksr at t-com.me (aksr) Date: Sun, 5 Apr 2020 03:38:21 +0200 Subject: [TUHS] 8th Edition timeline In-Reply-To: References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com> Message-ID: <20200405013821.GA716137@lap> On Sun, Apr 05, 2020 at 07:32:22AM +1000, Rob Pike wrote: > Sam wasn't nee jim. Jim was a toy, sam is a serious editor. > > My notebooks are hundreds of pages of figuring stuff out. Perhaps > valuable information to historians, but not easily compressed for this > forum. I think this info would be more than interesting. Maybe if and when you have the time, you could compress this (at least for your blog)? From nw at retrocomputingtasmania.com Sun Apr 5 12:19:54 2020 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Sun, 5 Apr 2020 12:19:54 +1000 Subject: [TUHS] Xenix-11 Images In-Reply-To: References: Message-ID: On Sun, Apr 5, 2020 at 10:55 AM Warner Losh wrote: > Crazy longshot post, part 27 in an infinite series Xenix-11 would be good to track down, for those that need a reminder here is an advert for it: http://bitsavers.org/pdf/apple/lisa/xenix/brochures/PDP-11_Xenix_Brochure_Aug84.jpg relevant text from advert: "XENIS SYSTEM FOR THE PDP-11 AND LSI-11 FAMILIES" "COMPLETE OPERATING SYSTEM PACKAGES LICENSED UNDER AT&T'S UNIX SYSTEM III" "Our XENIX system is real UNIX with such commercial enhancements as file and record locking, greater reliability, and improved system administration facilities. A unique memory overlay method enables complete UNIX performance on the LSI-11/23. The new LSI-11/73 processor is also fully supported. (For VAX users, 4.2 bsd virtual memory UNIX is available.)" and "The Santa Cruz Operation has XENIX available on many popular personal computers including the IBM Personal Computer, the Apple Lisa and the DEC Professional 350." SCO Xenix System V 2.1.3 exists for IBM PC (5160) SCO Xenix 3.0 Rel 1.0 exists for Apple Lisa Someone in the DEC Pro 350/380 collector community may have a copy of XENIX. From nw at retrocomputingtasmania.com Sun Apr 5 15:13:22 2020 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Sun, 5 Apr 2020 15:13:22 +1000 Subject: [TUHS] Xenix-11 Images In-Reply-To: References: Message-ID: LCM this weekend had a demo of their "Miss Piggy" 11/70 running Unix v7 (apparently Microsoft's original development machine?) and it occurred to me to have a quick look at the LCM archive and found this: https://opac.libraryworld.com/opac/catalog_edit.php?catalog_id=671443&from_doc=standard.php&position=68 [XENIX] Tests basic.pdp 11 util / February 14, 1982. 1 9 track tape with handwritten label. I wonder what that is? If anyone is going to have XENIX material I would expect LCM to be a potential source for it. From imp at bsdimp.com Sun Apr 5 15:38:24 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 4 Apr 2020 23:38:24 -0600 Subject: [TUHS] Xenix-11 Images In-Reply-To: References: Message-ID: On Sat, Apr 4, 2020 at 11:14 PM Nigel Williams < nw at retrocomputingtasmania.com> wrote: > LCM this weekend had a demo of their "Miss Piggy" 11/70 running Unix > v7 (apparently Microsoft's original development machine?) and it > occurred to me to have a quick look at the LCM archive and found this: > > > https://opac.libraryworld.com/opac/catalog_edit.php?catalog_id=671443&from_doc=standard.php&position=68 > > [XENIX] Tests basic.pdp 11 util / February 14, 1982. > 1 9 track tape with handwritten label. > > I wonder what that is? If anyone is going to have XENIX material I > would expect LCM to be a potential source for it. > I saw that live today... They mentioned they were looking for Xenix-11 to try to run on misspiggy :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From emu at e-bbes.com Sun Apr 5 23:17:30 2020 From: emu at e-bbes.com (emanuel stiebler) Date: Sun, 5 Apr 2020 09:17:30 -0400 Subject: [TUHS] 8th Edition timeline In-Reply-To: References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> <684e36a8-4ed7-bec2-674b-c9bf3cce04c4@e-bbes.com> Message-ID: <89080e46-0c50-9ff3-ed2c-43beefd8cd96@e-bbes.com> On 2020-04-04 17:32, Rob Pike wrote: > Sam wasn't nee jim. Jim was a toy, sam is a serious editor. > > My notebooks are hundreds of pages of figuring stuff out. Perhaps > valuable information to historians, but not easily compressed for this > forum. If you need anybody with a scanner an patience, please tell me ;-) > -rob > > On Sun, Apr 5, 2020 at 5:57 AM Noel Hunt wrote: >> >> I would be interested too. That was a seminal time with the >> proliferation of graphical programs, such as jim, pads/pi, >> proof, the sophisticated menus of 'mhit.c' etc. It is curious >> that little if any of that code made the transition to Plan9 >> (apart from sam, nee jim). >> >> >> On Sun, Apr 5, 2020 at 12:19 AM emanuel stiebler wrote: >>> >>> On 2020-03-30 05:06, Rob Pike wrote: >>>> I've looked through my notes and unfortunately there's very little >>>> about this as the notes are mostly about graphics and physics. >>> >>> I wouldn't mind seeing the note baout graphics, even if not on topic for >>> this group ... From ron at ronnatalie.com Mon Apr 6 09:57:55 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Sun, 5 Apr 2020 19:57:55 -0400 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <1jKlvG-4JB-00@marmaro.de> References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> Message-ID: <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> The Lions book wasn’t really published back in the day. It was only targetted at his students in Australia (though copies leaked out). The manuals aren’t really a book (and again, they weren’t really published as a book) and most of the prose on UNIX was more in the form of articles than an entire book. From lm at mcvoy.com Mon Apr 6 10:08:14 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 5 Apr 2020 17:08:14 -0700 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> Message-ID: <20200406000814.GH25105@mcvoy.com> Do the Bell Labs technical journals count? I have a collection of Unix papers that were puled out and published together in two volumes. That stuff was a gold mine of information in the 80's. On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote: > The Lions book wasn???t really published back in the day. It was only targetted at his students in Australia (though copies leaked out). > > The manuals aren???t really a book (and again, they weren???t really published as a book) and most of the prose on UNIX was more in the form of articles than an entire book. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From dave at horsfall.org Mon Apr 6 10:17:39 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 6 Apr 2020 10:17:39 +1000 (EST) Subject: [TUHS] First book on Unix for general readership In-Reply-To: <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> Message-ID: On Sun, 5 Apr 2020, Ronald Natalie wrote: > The Lions book wasn’t really published back in the day. It was only > targetted at his students in Australia (though copies leaked out). Leaked out? Apparently it's the most photocopied book in the world! I had the originals but sadly lost them in a house move (along with all issues of AUUGN). > The manuals aren’t really a book (and again, they weren’t really > published as a book) and most of the prose on UNIX was more in the form > of articles than an entire book. I still reckon that the manpage format is perfect at what it does: telling you what you need to know right away without going through various menu levels (and that's not a dig at "info" but just an observation in general). -- Dave From clemc at ccc.com Mon Apr 6 10:27:40 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 5 Apr 2020 20:27:40 -0400 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <20200406000814.GH25105@mcvoy.com> References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> <20200406000814.GH25105@mcvoy.com> Message-ID: Two thoughts ... 1.) Lion's was not a general book. It really was more of a kernel 'here-is-how-the-magic-happens.' It's still the best I know for that. BTW: it did not leak. It was purchasable from WE. But the cost was high and it was hard to get (you had a price you had a license and could not buy/order it at any book store - I don't think it had an ISBN or a library congress number originally). I know a couple of the schools (like CMU) wanted to use it for the OS course, but there was some hang-up associated with it in the mid-70s, which I don't remember - we did have a couple of sections passed out for a few lecture. But because of how it was bound (and short), it was photocopied s others have pointed out. I think Michigan managed to use the whole thing for their OS course, as I seem to remember that both Ted Kowalski and Bill Joy got copies there (although my memory is that they both had photocopies not the original Orange and Red bindings). Ted brought it to CMU, which is how I first saw it (and I think my original copy was a duplicate of his). And I remember seeing a photocopy in wnj's office at UCB. The first time I saw the official Red/Orange bound version was when I ordered it at Tektronix from WE a few years later, but I had to leave it there when I went back to grad school. 2.) The question asked about general 'Unix' text -- my favorite is still Rob and Brian's and I still recommend it (particularly to learn how to >>use<< UNIX/Linux today by doing the exercises), but it was not first. Steve's certainly was early and I thought it was a good explanation and until Rob and Brian became available was what I suggested when people asked. In fact, early Masscomp system's shipped Bourne's text, until Tim wrote the original 'UNIX In a Nutshell' that started his empire. That said, I do seem to remember there was another book around the same time (79-80 ish) that had a light blue cover that came from one 'PC-press' publishers. I wish I could remember the author and the name. I remember looking at a copy in Powell's in Portland when it came out and not being impressed. On Sun, Apr 5, 2020 at 8:08 PM Larry McVoy wrote: > Do the Bell Labs technical journals count? I have a collection of Unix > papers that were puled out and published together in two volumes. That > stuff was a gold mine of information in the 80's. > > On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote: > > The Lions book wasn???t really published back in the day. It was only > targetted at his students in Australia (though copies leaked out). > > > > The manuals aren???t really a book (and again, they weren???t really > published as a book) and most of the prose on UNIX was more in the form of > articles than an entire book. > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From musher at ucsc.edu Mon Apr 6 10:46:33 2020 From: musher at ucsc.edu (Michael Usher) Date: Sun, 5 Apr 2020 17:46:33 -0700 Subject: [TUHS] First book on Unix for general readership In-Reply-To: References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> <20200406000814.GH25105@mcvoy.com> Message-ID: I tried an ngram search on google, and came up with the following: Richard L. Gauthier. October 1981. Using the Unix System, Reston Publishing Co. ISBN 978-0835981644. That seems to precede the Bourne book. Available at amazon: https://www.amazon.com/Using-Unix-System-Richard-Gauthier/dp/0835981649 Michael On Sun, Apr 5, 2020 at 5:28 PM Clem Cole wrote: > Two thoughts ... > > 1.) Lion's was not a general book. It really was more of a kernel > 'here-is-how-the-magic-happens.' It's still the best I know for that. > BTW: it did not leak. It was purchasable from WE. But the cost was high > and it was hard to get (you had a price you had a license and could not > buy/order it at any book store - I don't think it had an ISBN or a library > congress number originally). > > I know a couple of the schools (like CMU) wanted to use it for the OS > course, but there was some hang-up associated with it in the mid-70s, which > I don't remember - we did have a couple of sections passed out for a few > lecture. But because of how it was bound (and short), it was photocopied s > others have pointed out. > > I think Michigan managed to use the whole thing for their OS course, as I > seem to remember that both Ted Kowalski and Bill Joy got copies there > (although my memory is that they both had photocopies not the original > Orange and Red bindings). Ted brought it to CMU, which is how I first saw > it (and I think my original copy was a duplicate of his). And I remember > seeing a photocopy in wnj's office at UCB. The first time I saw > the official Red/Orange bound version was when I ordered it at Tektronix > from WE a few years later, but I had to leave it there when I went back to > grad school. > > > 2.) The question asked about general 'Unix' text -- my favorite is still > Rob and Brian's and I still recommend it (particularly to learn how to > >>use<< UNIX/Linux today by doing the exercises), but it was not first. > Steve's certainly was early and I thought it was a good explanation and > until Rob and Brian became available was what I suggested when people > asked. In fact, early Masscomp system's shipped Bourne's text, until Tim > wrote the original 'UNIX In a Nutshell' that started his empire. That > said, I do seem to remember there was another book around the same time > (79-80 ish) that had a light blue cover that came from one 'PC-press' > publishers. I wish I could remember the author and the name. I remember > looking at a copy in Powell's in Portland when it came out and not being > impressed. > > On Sun, Apr 5, 2020 at 8:08 PM Larry McVoy wrote: > >> Do the Bell Labs technical journals count? I have a collection of Unix >> papers that were puled out and published together in two volumes. That >> stuff was a gold mine of information in the 80's. >> >> On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote: >> > The Lions book wasn???t really published back in the day. It was only >> targetted at his students in Australia (though copies leaked out). >> > >> > The manuals aren???t really a book (and again, they weren???t really >> published as a book) and most of the prose on UNIX was more in the form of >> articles than an entire book. >> >> -- >> --- >> Larry McVoy lm at mcvoy.com >> http://www.mcvoy.com/lm >> > -- Michael Usher Senior Wireless Network Engineer University of California, Santa Cruz musher at ucsc.edu 831-459-3697 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Apr 6 11:41:28 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 5 Apr 2020 21:41:28 -0400 Subject: [TUHS] First book on Unix for general readership In-Reply-To: References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> <20200406000814.GH25105@mcvoy.com> Message-ID: That’s it. On Sun, Apr 5, 2020 at 8:46 PM Michael Usher wrote: > I tried an ngram search on google, and came up with the following: > > Richard L. Gauthier. October 1981. Using the Unix System, Reston > Publishing Co. ISBN 978-0835981644. > > That seems to precede the Bourne book. > > Available at amazon: > https://www.amazon.com/Using-Unix-System-Richard-Gauthier/dp/0835981649 > > Michael > > > On Sun, Apr 5, 2020 at 5:28 PM Clem Cole wrote: > >> Two thoughts ... >> >> 1.) Lion's was not a general book. It really was more of a kernel >> 'here-is-how-the-magic-happens.' It's still the best I know for that. >> BTW: it did not leak. It was purchasable from WE. But the cost was high >> and it was hard to get (you had a price you had a license and could not >> buy/order it at any book store - I don't think it had an ISBN or a library >> congress number originally). >> >> I know a couple of the schools (like CMU) wanted to use it for the OS >> course, but there was some hang-up associated with it in the mid-70s, which >> I don't remember - we did have a couple of sections passed out for a few >> lecture. But because of how it was bound (and short), it was photocopied s >> others have pointed out. >> >> I think Michigan managed to use the whole thing for their OS course, as I >> seem to remember that both Ted Kowalski and Bill Joy got copies there >> (although my memory is that they both had photocopies not the original >> Orange and Red bindings). Ted brought it to CMU, which is how I first saw >> it (and I think my original copy was a duplicate of his). And I remember >> seeing a photocopy in wnj's office at UCB. The first time I saw >> the official Red/Orange bound version was when I ordered it at Tektronix >> from WE a few years later, but I had to leave it there when I went back to >> grad school. >> >> >> 2.) The question asked about general 'Unix' text -- my favorite is still >> Rob and Brian's and I still recommend it (particularly to learn how to >> >>use<< UNIX/Linux today by doing the exercises), but it was not first. >> Steve's certainly was early and I thought it was a good explanation and >> until Rob and Brian became available was what I suggested when people >> asked. In fact, early Masscomp system's shipped Bourne's text, until Tim >> wrote the original 'UNIX In a Nutshell' that started his empire. That >> said, I do seem to remember there was another book around the same time >> (79-80 ish) that had a light blue cover that came from one 'PC-press' >> publishers. I wish I could remember the author and the name. I remember >> looking at a copy in Powell's in Portland when it came out and not being >> impressed. >> >> On Sun, Apr 5, 2020 at 8:08 PM Larry McVoy wrote: >> >>> Do the Bell Labs technical journals count? I have a collection of Unix >>> papers that were puled out and published together in two volumes. That >>> stuff was a gold mine of information in the 80's. >>> >>> On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote: >>> > The Lions book wasn???t really published back in the day. It was >>> only targetted at his students in Australia (though copies leaked out). >>> > >>> > The manuals aren???t really a book (and again, they weren???t really >>> published as a book) and most of the prose on UNIX was more in the form of >>> articles than an entire book. >>> >>> -- >>> --- >>> Larry McVoy lm at mcvoy.com >>> http://www.mcvoy.com/lm >>> >> > > -- > Michael Usher > Senior Wireless Network Engineer > University of California, Santa Cruz > musher at ucsc.edu 831-459-3697 > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From musher at ucsc.edu Mon Apr 6 11:46:25 2020 From: musher at ucsc.edu (Michael Usher) Date: Sun, 5 Apr 2020 18:46:25 -0700 Subject: [TUHS] First book on Unix for general readership In-Reply-To: References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> <20200406000814.GH25105@mcvoy.com> Message-ID: Now that I think about it -- I suspect I did actually read that book in the late 80s from the Fisher Library collection at Sydney Uni. The cover looks familiar to me. On Sun, Apr 5, 2020 at 6:41 PM Clem Cole wrote: > That’s it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Apr 7 00:51:05 2020 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 6 Apr 2020 10:51:05 -0400 Subject: [TUHS] First book on Unix for general readership In-Reply-To: References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> <20200406000814.GH25105@mcvoy.com> Message-ID: <33f635bb3ea67f5cf14b46316ca3b6a6.squirrel@squirrelmail.tuffmail.net> > I tried an ngram search on google, and came up with the following: > > Richard L. Gauthier. October 1981. Using the Unix System, Reston > Publishing > Co. ISBN 978-0835981644. > Gosh, I'd forgotten about Gauthier, perhaps the worst UNIX book ever written. From ron at ronnatalie.com Tue Apr 7 00:54:09 2020 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 6 Apr 2020 10:54:09 -0400 Subject: [TUHS] First book on Unix for general readership In-Reply-To: References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> Message-ID: <9e623ba84057c27e067f9c43a8b78d29.squirrel@squirrelmail.tuffmail.net> > On Sun, 5 Apr 2020, Ronald Natalie wrote: > >> The Lions book wasn’t really published back in the day. It was only >> targetted at his students in Australia (though copies leaked out). > > Leaked out? Apparently it's the most photocopied book in the world! I > had the originals but sadly lost them in a house move (along with all > issues of AUUGN). I have one of the Xeroxes. It's a second generation copy. I remember when I got a hold of someone else's copy me and five of my coworkers split up and went to different copiers around the company and each made six copies of their section and then we collated it together. We didn't dare take it to the company copy center. > >> The manuals aren’t really a book (and again, they weren’t really >> published as a book) and most of the prose on UNIX was more in the form >> of articles than an entire book. > > I still reckon that the manpage format is perfect at what it does: telling Agreed, but neither the manpages nor the BSTJ articles or the few non-manpage UNIX documents were "books." From ron at ronnatalie.com Tue Apr 7 00:54:08 2020 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 6 Apr 2020 10:54:08 -0400 Subject: [TUHS] First book on Unix for general readership In-Reply-To: References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> Message-ID: <99b6fa9e3fb3396864916117033c2799.squirrel@squirrelmail.tuffmail.net> > On Sun, 5 Apr 2020, Ronald Natalie wrote: > >> The Lions book wasn’t really published back in the day. It was only >> targetted at his students in Australia (though copies leaked out). > > Leaked out? Apparently it's the most photocopied book in the world! I > had the originals but sadly lost them in a house move (along with all > issues of AUUGN). I have one of the Xeroxes. It's a second generation copy. I remember when I got a hold of someone else's copy me and five of my coworkers split up and went to different copiers around the company and each made six copies of their section and then we collated it together. We didn't dare take it to the company copy center. > >> The manuals aren’t really a book (and again, they weren’t really >> published as a book) and most of the prose on UNIX was more in the form >> of articles than an entire book. > > I still reckon that the manpage format is perfect at what it does: telling Agreed, but neither the manpages nor the BSTJ articles or the few non-manpage UNIX documents were "books." From pnr at planet.nl Tue Apr 7 04:12:09 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 6 Apr 2020 20:12:09 +0200 Subject: [TUHS] PK protocol Message-ID: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl> I ran a search for ‘Datakit’ on the archive of this maling list and came across the below message from Norman Wilson (Sep 2017). Having spent quite a bit of time recently on figuring out Datakit details and 8th Edition source, I now much better understand what he was saying — or at least I think I do. It made me take another look at the /dev/pk[0123].c files in the V7 source code. I’d seen it before, but always thought it was UUCP code. Now I’m wondering. It looks like UUCP packet "protocol g” is maybe much the same as the original (“Chesson”) packet algorithm for Datakit, and if so it would be “dual use”. It would seem that in V7 line discipline ‘0’ was normal tty handling, discipline ‘1’ was PK protocol over serial and line discipline ‘2’ was PK protocol over something with CRC in the driver - whatever that was. If the above thought is correct, then it shines a light on network buffering in V7: it uses buffer space in blocks of n*32 bytes, carved out from a pool of disk buffers (see pk3.c); it pre-allocates space for one full receive window. I have not fully figured it out, but at first glance it seems that the PK line discipline was only integrated with the DH-11 driver in the public V7 source. That would make sense in a networking context, as that board offered input buffering / DMA output to reduce the interrupt load. In 1979 Datakit seems to have connected over a DR-11C board, but there is no driver for that in the V7 source tree. Am I on the right track? ===== The point of the stream I/O setup with stackable line disciplines, rather than the old single line-discipline switch, was specifically to support networking as well as tty processing. Serial-device drivers in V7 used a single line-discipline driver, used variously for canonical-tty handling and for network protocols. The standard system as used outside the labs had only one line discipline configured, with standard tty handling (see usr/sys/conf/c.c). There were driver source files for what I think were internal-use-only networks (dev/pk[12].c, perhaps), but I don't think they were used outside AT&T. The problem Dennis wanted to solve was that tty handling and network protocol handling interfered with one another; you couldn't ask the kernel to do both, because there was only one line discipline at a time. Hence the stackable modules. It was possible to duplicate tty handling (probably by placing calls to the regular tty line discipline's innards) within the network-protocol code, but that was messy. It also ran into trouble when people wanted to use the C shell, which expected its own special `new tty' line discipline, so the network code would have to know which tty driver to call. It made more sense to stack the modules instead, so the tty code was there only if it was needed, and different tty drivers could exist without the network code knowing or caring. When I arrived at the Labs in 1984, the streams code was in use daily by most of us in 1127. The terminals on our desks were plugged into serial ports on Datakit (like what we call a terminal server now). I would turn on my terminal in the morning, tell the prompt which system I wanted to connect to, and so far as I could tell I had a direct serial connection. But in the remote host, my shell talked to an instance of the tty line module, which exchanged data with a Datakit protocol module, which exchanged data with the low-level Datakit driver. If I switched to the C shell (I didn't but some did), csh would pop off the tty module and push on the newtty module, and the network code was none the wiser. Later there was a TCP/IP that used the stream mechanism. The first version was shoehorned in by Robert T Morris, who worked as a summer intern for us; it was later cleaned up considerably by Paul Glick. It's more complicated because of all the multiplexers involved (Ethernet packets split up by protocol number; IP packets divided by their own protocol number; TCP packets into sessions), but it worked. I still use it at home. Its major flaw is that details of the original stream implementation make it messy to handle windows of more than 4096 bytes; there are also some quirks involving data left in the pipe when a connection closes, something Dennis's code doesn't handle well. The much-messier STREAMS that came out of the official System V people had fixes for some of that, but at the cost of quite a bit more complexity; it could probably be done rather better. At one point I wanted to have a go at it, but I've never had the time, and now I doubt I ever will. One demonstration of virtue, though: although Datakit was the workhorse network in Research when I was there (and despite the common bias against virtual circuits it worked pretty well; the major drawback was that although the underlying Datakit fabric could run at multiple megabits per second, we never had a host interface that could reliably run at even a single megabit), we did once arrange to run TCP/IP over a Datakit connection. It was very simple in concept: make a Datakit connection (so the Datakit protocol module is present); push an IP instance onto that stream; and off you go. I did something similar in my home V10 world when quickly writing my own implementation of PPP from the specs many years ago. The core of that code is still in use in my home-written PPPoE code. PPP and PPPoE are all outside the kernel; the user-mode program reads and writes the serial device (PPP) or an Ethernet instance that returns just the desired protocol types (PPPoE), does the PPP processing, and reads and writes IP packets to a (full-duplex stream) pipe on the other end of which is pushed the IP module. All this is very different from the socket(2) way of thinking, and it has its vices, but it also has its virtues. Norman Wilson Toronto ON From wkt at tuhs.org Tue Apr 7 08:11:38 2020 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 7 Apr 2020 08:11:38 +1000 Subject: [TUHS] Software Archaeology Challenge? Message-ID: <20200406221138.GA10092@minnie.tuhs.org> Anybody feel up for a bit of an archaeology challenge? Warner Losh is currently poking through a bunch of bits but not having much luck decoding them correctly. I've put a copy here: https://minnie.tuhs.org/Y5/Challenge/ If you can help, I'd suggest report major findings here, and we can use the #TUHS channel in the ClassicCmp Discord server for chat. Here's what Warner has found out so far: It's quite interesting, but in a format I've so far not been able to decode more than with emacs. However, there's all kinds of wonderful here. This looks like it was a dump from a VMS (or maybe similar DEC OS) ANSI tape. There's 4 datasets of 2.5MB each. The first one appears to be a V5 tree of some sort (at least it matches the V5 sources in places I can spot check in Dennis_v5. The second block looks v6ish or maybe pwbish, but no kernel sources. I don't think it's a continuation of the v5 stuff from the first dataset. The third dataset is all binaries, as far as I can tell so far, but things like mv and passwd. The 4th dataset appears to be the dump of a VENIX-11 system, complete with source. The 3rd dataset appears to be a Venix system. At least it has venix and venix.old in what looks like the root directory. Still trying to sort out extracting files from these datasets. v7fs hates them, but I'm almost positive that's what they are. Cheers, Warren From henry.r.bent at gmail.com Tue Apr 7 08:48:47 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 6 Apr 2020 18:48:47 -0400 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: <20200406221138.GA10092@minnie.tuhs.org> References: <20200406221138.GA10092@minnie.tuhs.org> Message-ID: On Mon, 6 Apr 2020 at 18:12, Warren Toomey wrote: > Anybody feel up for a bit of an archaeology challenge? Warner Losh is > currently poking through a bunch of bits but not having much luck decoding > them correctly. I've put a copy here: > https://minnie.tuhs.org/Y5/Challenge/ > > If you can help, I'd suggest report major findings here, and we can use > the #TUHS channel in the ClassicCmp Discord server for chat. > > Here's what Warner has found out so far: > > It's quite interesting, but in a > format I've so far not been able to decode more than with emacs. > However, there's all kinds of wonderful here. This looks like it was a > dump from a VMS (or maybe similar DEC OS) ANSI tape. There's 4 datasets > of 2.5MB each. The first one appears to be a V5 tree of some sort (at > least it matches the V5 sources in places I can spot check in > Dennis_v5. The second block looks v6ish or maybe pwbish, but no kernel > sources. I don't think it's a continuation of the v5 stuff from the > first dataset. The third dataset is all binaries, as far as I can tell > so far, but things like mv and passwd. The 4th dataset appears to be > the dump of a VENIX-11 system, complete with source. > > The 3rd dataset appears to be a Venix system. At least it has venix and > venix.old in what looks like the root directory. Still trying to sort > out extracting files from these datasets. v7fs hates them, but I'm > almost positive that's what they are. > Looking at the first file as well as the later 512 byte files, this appears to have been made on an RT-11 system. There are entries for HDR1ZEROED.ZZZ which shows up in the RT-11 5.07 sources: http://www.kpxx.ru/DEC/PDP-11/Software/OS/RT-11/05.07/05.07.abl/Unpacked/DUPZMC.MAC . Unfortunately I have absolutely no experience with magtapes under RT-11 so I'm not currently sure how to proceed. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From drb at msu.edu Tue Apr 7 08:59:49 2020 From: drb at msu.edu (Dennis Boone) Date: Mon, 06 Apr 2020 18:59:49 -0400 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: (Your message of Tue, 07 Apr 2020 08:11:38 +1000.) <20200406221138.GA10092@minnie.tuhs.org> References: <20200406221138.GA10092@minnie.tuhs.org> Message-ID: <20200406225949.88C792BB520@yagi.h-net.msu.edu> The tape was made by a PDP-11 system running RT-11. This manual may help a little: http://bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PD6PA-TC_RT-11_Volume_and_File_Formats_Manual_Aug91.pdf TL;DR - This tape was written by just copying disk files to it, so the files which contain actual data are just images of the disk files. File 5 - this looks like a file system image. File 8 - appears to be some sort of archiver output, but while the .ARC extension might lead you to suspect the old CP/M - MSDOS ARC program was responsible, that doesn't appear to be the case. File 11 - this is an older format tarball. De From wkt at tuhs.org Tue Apr 7 09:47:58 2020 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 7 Apr 2020 09:47:58 +1000 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: <20200406221138.GA10092@minnie.tuhs.org> References: <20200406221138.GA10092@minnie.tuhs.org> Message-ID: <20200406234758.GA27062@minnie.tuhs.org> On Tue, Apr 07, 2020 at 08:11:38AM +1000, Warren Toomey wrote: > Anybody feel up for a bit of an archaeology challenge? Warner Losh is > currently poking through a bunch of bits but not having much luck decoding > them correctly. I've put a copy here: https://minnie.tuhs.org/Y5/Challenge/ Warner has more to report: set cpu 11/45 [on SimH] was the missing magic. The first two data sets are V6 system. Lots of dates around May 13, 1975 for sure. I can also mount the venix disks (I thought it was V7/sys III which had a different filesystem layout). It seems to be compiled for the 11/34. I'll give that a shot. That almost worked. I think I need to figure out how to enable DL as the console since the config file has DL as the console. Warner Cheers, Warren From henry.r.bent at gmail.com Tue Apr 7 10:04:57 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 6 Apr 2020 20:04:57 -0400 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: <20200406234758.GA27062@minnie.tuhs.org> References: <20200406221138.GA10092@minnie.tuhs.org> <20200406234758.GA27062@minnie.tuhs.org> Message-ID: On Mon, 6 Apr 2020 at 19:48, Warren Toomey wrote: > On Tue, Apr 07, 2020 at 08:11:38AM +1000, Warren Toomey wrote: > > Anybody feel up for a bit of an archaeology challenge? Warner Losh is > > currently poking through a bunch of bits but not having much luck > decoding > > them correctly. I've put a copy here: > https://minnie.tuhs.org/Y5/Challenge/ > > Warner has more to report: > > The first two data sets are V6 system. Lots of dates around May 13, > 1975 for sure. > The first tape looks like a virgin distribution with the exception of one file in the root directory, nlsq.f, which is a version of https://people.sc.fsu.edu/~jburkardt/f77_src/nl2sol/nl2sol.html . It boots to a date of October 6, 1983. . total 540 -rw-rw-rw- 1 root 9092 Oct 6 15:36 a.out drwxrwxr-x 2 bin 1104 May 14 1975 bin drwxrwxr-x 2 bin 1824 May 13 1975 dev drwxrwxr-x 2 bin 496 Oct 6 15:39 etc -rwxrwxrwx 1 root 28402 Jun 22 1975 hpunix drwxrwxr-x 2 bin 464 May 13 1975 lib drwxrwxr-x 2 bin 32 May 13 1975 mnt -rw-rw-rw- 1 root 168561 Oct 6 15:35 nlsq.f -rwxrwxrwx 1 root 28156 Jun 22 1975 rkunix -rwxrwxrwx 1 root 28340 Jun 22 1975 rpunix -rw-rw-r-- 1 bin 3316 May 14 1975 run drwxrwxrwx 2 bin 272 Oct 6 15:39 tmp drwxrwxr-x 14 bin 224 May 13 1975 usr bin/. total 392 -rwxrwxr-x 1 bin 1514 May 9 1975 ar -rwxrwxr-x 1 bin 5748 May 9 1975 as -rwxrwxr-x 1 bin 8780 May 9 1975 bas -rwxrwxr-x 1 bin 152 May 9 1975 cat -rwxrwxr-x 1 bin 7186 May 18 1975 cc -rwxrwxr-x 1 bin 12358 May 14 1975 cdb -rwxrwxr-x 1 bin 502 May 9 1975 chgrp -rwxrwxr-x 1 bin 1734 May 9 1975 chmod -rwxrwxr-x 1 bin 500 May 9 1975 chown -rwxrwxr-x 1 bin 190 May 9 1975 clri -rwxrwxr-x 1 bin 1554 May 9 1975 cmp -rwxrwxr-x 1 bin 838 May 9 1975 cp -rwxrwxr-x 1 bin 2062 May 9 1975 date -rwxrwxr-x 1 bin 4690 May 14 1975 db -rwxrwxr-x 1 bin 10254 May 9 1975 dc -rwxrwxr-x 1 bin 2202 May 9 1975 dcheck -rwxrwxr-x 1 bin 4360 May 9 1975 dd -rwxrwxr-x 1 bin 1440 May 9 1975 df -rwxrwxr-x 1 bin 262 May 9 1975 dsw -rwxrwxr-x 1 bin 654 May 9 1975 du -rwxrwxr-x 1 bin 4688 May 9 1975 dump -rwxrwxr-x 1 bin 758 May 9 1975 echo -rwxrwxr-x 1 bin 6308 May 9 1975 ed -rwxrwxr-x 1 bin 156 May 9 1975 exit -rwxrwxr-x 1 bin 4886 May 9 1975 fc -rwxrwxr-x 1 bin 3036 May 9 1975 file -rwxrwxr-x 1 bin 788 May 9 1975 goto -rwxrwxr-x 1 bin 3118 May 9 1975 icheck -rwxrwxr-x 1 bin 1532 May 9 1975 if -rwxrwxr-x 1 bin 192 May 9 1975 kill -rwxrwxr-x 1 bin 6192 May 9 1975 ld -rwxrwxr-x 1 bin 474 May 9 1975 ln -rwsr-xr-x 1 root 2628 May 9 1975 login -rwxrwxr-x 1 bin 4920 May 9 1975 ls -rwxrwxr-x 1 bin 4370 May 9 1975 mail -rwsr-xr-x 1 root 240 May 9 1975 mkdir -rwsr-xr-x 1 root 2360 May 9 1975 mv -rwxrwxr-x 1 bin 2438 May 9 1975 ncheck -rwsr-xr-x 1 root 3086 May 9 1975 newgrp -rwxrwxr-x 1 bin 2476 May 9 1975 nm -rwxrwxr-x 1 bin 4476 May 9 1975 od -rwxrwxr-x 1 bin 394 May 9 1975 opr -rwsr-xr-x 1 bin 2254 May 14 1975 passwd -rwxrwxr-x 1 bin 4150 May 9 1975 pr -rwxrwxr-x 1 bin 3220 May 9 1975 ps -rwxrwxr-x 1 bin 5598 May 9 1975 restor -rwxrwxr-x 1 bin 114 May 9 1975 rew -rwxrwxr-x 1 bin 1778 May 9 1975 rm -rwsr-xr-x 1 root 292 May 9 1975 rmdir -rwxrwxr-x 1 bin 5888 May 14 1975 sh -rwxrwxr-x 1 bin 1086 May 9 1975 size -rwxrwxr-x 1 bin 5032 May 9 1975 sort -rwxrwxr-x 1 bin 520 May 9 1975 strip -rwxrwxr-x 1 bin 2312 May 9 1975 stty -rwsr-xr-x 1 root 1934 May 9 1975 su -rwxrwxr-x 1 bin 202 May 9 1975 sum -rwxrwxr-x 1 bin 100 May 9 1975 sync -rwxrwxr-x 1 bin 610 May 9 1975 time -rwxrwxr-x 1 bin 6798 May 9 1975 tp -rwxrwxr-x 1 bin 158 May 9 1975 tty -rwxrwxr-x 1 bin 1746 May 9 1975 uniq -rwxrwxr-x 1 bin 1916 May 9 1975 who -rwxrwxr-x 1 bin 680 May 9 1975 write dev/. total 0 crw-rw-r-- 1 bin 8, 1 May 13 1975 kmem c-w--w--w- 1 bin 2, 0 May 18 1975 lp crw-rw-r-- 1 bin 8, 0 May 13 1975 mem brw-rw-rw- 1 bin 3, 0 Oct 6 14:10 mt0 crw-rw-rw- 1 bin 8, 2 May 13 1975 null crw-rw-rw- 1 bin 1, 0 May 13 1975 ppt brw-rw-r-- 1 bin 2, 0 May 18 1975 rf0 brw-rw-r-- 1 bin 0, 0 May 20 1975 rk0 brw-rw-r-- 1 bin 0, 1 May 27 1975 rk1 crw-rw-rw- 1 bin 12, 0 May 13 1975 rmt0 brw-rw-r-- 1 bin 1, 0 May 13 1975 rp0 crw-rw-r-- 1 bin 10, 0 May 13 1975 rrf0 crw-rw-r-- 1 bin 9, 0 May 13 1975 rrk0 crw-rw-r-- 1 bin 9, 1 May 13 1975 rrk1 crw-rw-r-- 1 bin 11, 0 May 13 1975 rrp0 brw-rw-rw- 1 bin 4, 0 May 18 1975 tap0 brw-rw-rw- 1 bin 4, 1 May 13 1975 tap1 brw-rw-rw- 1 bin 4, 2 May 13 1975 tap2 brw-rw-rw- 1 bin 4, 3 May 13 1975 tap3 brw-rw-rw- 1 bin 4, 4 May 13 1975 tap4 brw-rw-rw- 1 bin 4, 5 May 13 1975 tap5 brw-rw-rw- 1 bin 4, 6 May 13 1975 tap6 brw-rw-rw- 1 bin 4, 7 May 13 1975 tap7 crw--w--w- 1 root 0, 0 Oct 6 15:41 tty8 etc/. total 51 -rwsrwsr-- 1 daemon 3246 May 13 1975 cron -rw-rw-rw- 1 bin 0 May 13 1975 dtab -rwxrwxr-- 1 bin 922 May 13 1975 getty -rwxrwxr-x 1 bin 1378 May 13 1975 glob -rw-r--r-- 1 bin 26 May 13 1975 group -rwxrwxr-- 1 root 2054 May 13 1975 init -rwsrwsr-x 1 daemon 814 May 13 1975 lpd -rwxrwxr-x 1 bin 4368 May 13 1975 mkfs -rwxrwxr-x 1 bin 1850 May 13 1975 mknod -rwsrwxr-x 1 bin 2100 May 13 1975 mount -rw-r--r-- 1 bin 66 May 27 1975 passwd -rw-rw-r-- 1 bin 28 May 13 1975 rc -rw-rw-r-- 1 bin 112 May 13 1975 ttys -rwsrwxr-x 1 bin 2010 May 13 1975 umount -rwxrwxr-x 1 bin 48 May 13 1975 update -rw-rw-r-- 1 bin 144 Oct 6 15:39 utmp -rwxrwxr-x 1 bin 1310 May 13 1975 wall lib/. total 418 -rwxrwxr-x 1 bin 5064 May 13 1975 as2 -rwxrwxr-x 1 bin 14688 May 16 1975 c0 -rwxrwxr-x 1 bin 19186 May 16 1975 c1 -rwxrwxr-x 1 bin 8020 May 16 1975 c2 -rw-rw-r-- 1 bin 112 May 13 1975 crt0.o -rwxrwxr-x 1 bin 16760 May 16 1975 fc0 -rwxrwxr-x 1 bin 21194 May 16 1975 fc1 -rw-rw-r-- 1 bin 136 May 14 1975 fcrt0.o -rw-rw-r-- 1 bin 13810 May 27 1975 filib.a -rw-rw-r-- 1 bin 340 May 13 1975 fr0.o -rw-rw-r-- 1 bin 14118 May 27 1975 liba.a -rw-rw-r-- 1 bin 22042 May 27 1975 libc.a -rw-rw-r-- 1 bin 13958 May 27 1975 libf.a -rw-rw-r-- 1 bin 27606 May 27 1975 libp.a -rw-rw-r-- 1 bin 9982 May 27 1975 libs.a -rw-rw-r-- 1 bin 3530 May 27 1975 liby.a -rwxrwxr-x 1 bin 3144 May 13 1975 lpr -rw-rw-r-- 1 bin 436 May 16 1975 mcrt0.o -rw-rw-rw- 1 root 8794 May 27 1975 tmgb mnt/. total 0 tmp/. total 0 usr/. total 15 drwxrwxr-x 2 bin 48 May 13 1975 adm drwxrwxr-x 2 bin 1984 Jun 22 1975 bin drwxrwxr-x 2 bin 64 May 13 1975 fort drwxrwxr-x 2 bin 192 May 28 1975 games drwxrwxrwx 2 ken 128 May 28 1975 ken drwxrwxr-x 3 bin 432 May 13 1975 lib drwxrwxrwx 2 bin 288 May 18 1975 lpd drwxrwxr-x 2 bin 352 Jun 26 1975 mdec drwxrwxr-x 2 bin 256 May 13 1975 pub drwxrwxr-x 2 bin 32 May 13 1975 source drwxrwxr-x 5 bin 512 Jun 22 1975 sys drwxrwxrwx 2 bin 144 May 27 1975 tmp usr/adm/. total 0 usr/bin/. total 467 -rwxrwxr-x 1 bin 4984 May 13 1975 ac -rwxrwxr-x 1 bin 1596 May 14 1975 banner -rwxrwxr-x 1 bin 12282 May 14 1975 bc -rwxrwxr-x 1 bin 1056 May 14 1975 bcd -rwxrwxr-x 1 bin 1862 May 13 1975 cal -rwxrwxr-x 1 bin 59 May 13 1975 chk -rwxrwxr-x 1 bin 1982 Jun 22 1975 col -rwxrwxr-x 1 bin 1938 May 13 1975 comm -rwxrwxr-x 1 bin 504 May 14 1975 cpall -rwxrwxr-x 1 bin 7782 May 13 1975 cref -rwxrwxr-x 1 bin 2286 May 13 1975 crpost -rwxrwxr-x 1 bin 1246 May 14 1975 crypt -rwxrwxr-x 1 bin 4544 May 14 1975 diff -rwxrwxr-x 1 bin 4826 May 13 1975 fed -rwxrwxr-x 1 bin 5244 May 13 1975 find -rwxrwxr-x 1 bin 4118 May 13 1975 form -rwxrwxr-x 1 bin 2190 May 13 1975 grep -rwxrwxr-x 1 bin 1998 May 14 1975 gsi -rwxrwxr-x 1 bin 5812 May 13 1975 index -rwxrwxr-x 1 bin 9798 May 13 1975 m6 -rwxrwxr-x 1 bin 576 May 13 1975 mesg -rwxrwxr-x 1 bin 20234 May 14 1975 neqn -rwxrwxr-x 1 bin 1134 May 13 1975 nice -rwxrwxr-x 1 bin 1298 May 13 1975 nohup -rwxrwxr-x 1 bin 16542 May 13 1975 nroff -rwxrwxr-x 1 bin 240 May 13 1975 pfe -rwxrwxr-x 1 bin 6916 May 13 1975 prof -rwxrwxr-x 1 bin 3156 May 13 1975 ptx -rwxrwxr-x 1 bin 834 May 13 1975 pwd -rwxrwxr-x 1 bin 4674 May 13 1975 quiz -rwxrwxr-x 1 bin 4898 May 13 1975 rc -rwxrwxr-x 1 bin 8136 May 13 1975 roff -rwxrwxr-x 1 bin 9270 May 16 1975 sa -rwxrwxr-x 1 bin 836 May 13 1975 sleep -rwxrwxr-x 1 bin 8624 May 13 1975 sno -rwxrwxr-x 1 bin 1104 May 13 1975 split -rwxrwxr-x 1 bin 8230 May 14 1975 tbl -rwxrwxr-x 1 bin 648 May 13 1975 tee -rwxrwxr-x 1 bin 88 May 13 1975 tmg -rwxrwxr-x 1 bin 1632 May 13 1975 tr -rwxrwxr-x 1 bin 7802 May 13 1975 typo -rwxrwxr-x 1 bin 6248 May 16 1975 units -rwxrwxr-x 1 bin 1952 May 13 1975 upost -rwxrwxr-x 1 bin 4458 May 13 1975 usort -rwxrwxr-x 1 bin 1664 May 13 1975 wc -rwxrwxr-x 1 bin 16964 May 13 1975 yacc usr/fort/. total 32 -rw-rw-r-- 1 bin 1420 May 13 1975 errors -rwxrwxr-x 1 bin 14102 May 13 1975 fc1 usr/games/. total 62 -rwxrwxr-x 1 bin 1562 May 13 1975 bj -rwxrwxr-x 1 bin 16088 May 13 1975 chess -rwxrwxr-x 1 bin 2468 May 13 1975 cubic -rwxrwxr-x 1 bin 624 May 13 1975 moo -rwxrwxr-x 1 bin 2192 May 13 1975 ttt -rw-rw-rw- 1 bin 304 May 28 1975 ttt.k -rwxrwxr-x 1 bin 5184 May 13 1975 wump usr/lib/. total 386 -rw-rw-r-- 1 bin 658 May 13 1975 aign -rw-rw-r-- 1 bin 768 May 13 1975 atab -rw-rw-r-- 1 bin 57704 May 20 1975 book -rw-rw-r-- 1 bin 142 May 13 1975 cign -rw-rw-r-- 1 bin 768 May 13 1975 ctab -rw-rw-r-- 1 bin 706 May 13 1975 eign -rw-rw-r-- 1 bin 768 May 13 1975 etab -rw-rw-r-- 1 bin 1609 May 20 1975 lib.b drwxrwxr-x 2 bin 352 May 13 1975 quiz -rwxrwxr-x 1 bin 12106 May 14 1975 ratfor -rw-rw-r-- 1 bin 21200 May 13 1975 salt -rw-rw-r-- 1 bin 2168 May 13 1975 suftab -rw-rw-r-- 1 bin 1112 May 13 1975 tmac.r -rw-rw-r-- 1 bin 12347 May 20 1975 tmac.s -rwxrwxr-x 1 bin 11156 May 14 1975 tmg -rw-rw-r-- 1 bin 2612 May 13 1975 tmga -rw-rw-r-- 1 bin 8794 May 13 1975 tmgb -rw-rw-r-- 1 bin 388 May 13 1975 tmgc -rw-rw-r-- 1 bin 7608 May 20 1975 units -rw-rw-r-- 1 bin 44816 May 13 1975 w2006 usr/lib/quiz/. total 62 -rw-rw-r-- 1 bin 904 May 13 1975 africa -rw-rw-r-- 1 bin 542 May 13 1975 america -rw-rw-r-- 1 bin 6704 May 13 1975 bard -rw-rw-r-- 1 bin 1403 May 13 1975 collectives -rw-rw-r-- 1 bin 745 May 13 1975 europe -rw-rw-r-- 1 bin 301 May 13 1975 inca -rw-rw-r-- 1 bin 811 May 13 1975 index -rw-rw-r-- 1 bin 274 May 13 1975 midearth -rw-rw-r-- 1 bin 553 May 13 1975 misspell -rw-rw-r-- 1 bin 889 May 20 1975 murders -rw-rw-r-- 1 bin 5588 May 13 1975 poetry -rw-rw-r-- 1 bin 814 May 13 1975 posneg -rw-rw-r-- 1 bin 2351 May 13 1975 pres -rw-rw-r-- 1 bin 722 May 13 1975 seq-easy -rw-rw-r-- 1 bin 872 May 13 1975 seq-hard -rw-rw-r-- 1 bin 1652 May 13 1975 sov -rw-rw-r-- 1 bin 1370 May 13 1975 state usr/lpd/. total 0 usr/mdec/. total 39 -rw-rw-r-- 1 bin 228 Jun 26 1975 dldr -rw-rw-r-- 1 bin 2406 Jun 26 1975 dtf -rw-rw-r-- 1 bin 460 Jun 26 1975 hboot -rw-rw-r-- 1 bin 504 Jun 26 1975 hpuboot -rw-rw-r-- 1 bin 396 Jun 26 1975 hthp -rw-rw-r-- 1 bin 356 Jun 26 1975 htrk -rw-rw-r-- 1 bin 366 Jun 26 1975 htrp -rw-rw-r-- 1 bin 442 Jun 26 1975 mboot -rw-rw-r-- 1 bin 432 Jun 26 1975 mcopy -rw-rw-r-- 1 bin 5614 Jun 26 1975 mem -rw-rw-r-- 1 bin 20 Jun 26 1975 reset -rw-rw-r-- 1 bin 128 Jun 26 1975 rkf -rw-rw-r-- 1 bin 464 Jun 26 1975 rkuboot -rw-rw-r-- 1 bin 474 Jun 26 1975 rpuboot -rw-rw-r-- 1 bin 406 Jun 26 1975 tboot -rw-rw-r-- 1 bin 2382 Jun 26 1975 tcf -rw-rw-r-- 1 bin 378 Jun 26 1975 tmhp -rw-rw-r-- 1 bin 338 Jun 26 1975 tmrk -rw-rw-r-- 1 bin 348 Jun 26 1975 tmrp -rw-rw-r-- 1 bin 512 Jun 26 1975 uboot usr/pub/. total 12 -rw-rw-r-- 1 bin 1056 May 13 1975 ascii -rw-rw-r-- 1 bin 1561 May 13 1975 deverr -rw-rw-r-- 1 bin 477 May 13 1975 greek -rw-rw-r-- 1 bin 729 May 13 1975 hanoi -rw-rw-r-- 1 bin 244 May 13 1975 kbd -rw-rw-r-- 1 bin 232 May 13 1975 tabs usr/source/. total 0 usr/sys/. total 253 -rw-rw-r-- 1 bin 2886 May 13 1975 buf.h drwxrwxr-x 2 bin 320 Jun 22 1975 conf -rw-rw-r-- 1 bin 916 May 13 1975 conf.h drwxrwxr-x 2 bin 848 May 27 1975 dmr -rw-rw-r-- 1 bin 407 May 13 1975 file.h -rw-rw-r-- 1 bin 949 May 13 1975 filsys.h -rw-rw-r-- 1 bin 533 May 13 1975 ino.h -rw-rw-r-- 1 bin 1694 May 13 1975 inode.h drwxrwxr-x 2 bin 688 Jun 22 1975 ken -rw-rw-r-- 1 bin 59018 Jun 22 1975 lib1 -rw-rw-r-- 1 bin 43066 May 27 1975 lib2 -rw-rw-r-- 1 bin 2147 May 13 1975 param.h -rw-rw-r-- 1 bin 1395 May 13 1975 proc.h -rw-rw-r-- 1 bin 274 May 13 1975 reg.h -rw-rw-r-- 1 bin 849 May 18 1975 run -rw-rw-r-- 1 bin 465 May 13 1975 seg.h -rw-rw-r-- 1 bin 1749 May 13 1975 systm.h -rw-rw-r-- 1 bin 380 May 13 1975 text.h -rw-rw-r-- 1 bin 2320 May 13 1975 tty.h -rw-rw-r-- 1 bin 2911 May 13 1975 user.h usr/sys/conf/. total 67 -rw-rw-r-- 1 bin 70 May 13 1975 data.s -rw-rw-r-- 1 bin 10007 May 13 1975 m40.s -rw-rw-r-- 1 bin 10526 May 13 1975 m45.s -rw-rw-r-- 1 bin 8603 May 14 1975 mkconf.c -rw-rw-r-- 1 bin 2252 May 13 1975 sysfix.c usr/sys/dmr/. total 166 -rw-rw-r-- 1 bin 12091 May 13 1975 bio.c -rw-rw-r-- 1 bin 941 May 13 1975 cat.c -rw-rw-r-- 1 bin 4380 May 13 1975 dc.c -rw-rw-r-- 1 bin 5388 May 13 1975 dh.c -rw-rw-r-- 1 bin 1569 May 13 1975 dhdm.c -rw-rw-r-- 1 bin 262 May 13 1975 dhfdm.c -rw-rw-r-- 1 bin 1313 May 13 1975 dn.c -rw-rw-r-- 1 bin 4774 May 13 1975 dp.c -rw-rw-r-- 1 bin 4355 May 13 1975 hp.c -rw-rw-r-- 1 bin 1862 May 13 1975 hs.c -rw-rw-r-- 1 bin 3898 May 13 1975 ht.c -rw-rw-r-- 1 bin 1965 May 13 1975 kl.c -rw-rw-r-- 1 bin 2310 May 13 1975 lp.c -rw-rw-r-- 1 bin 1146 May 13 1975 mem.c -rw-rw-r-- 1 bin 748 May 13 1975 partab.c -rw-rw-r-- 1 bin 2309 May 13 1975 pc.c -rw-rw-r-- 1 bin 1457 May 13 1975 rf.c -rw-rw-r-- 1 bin 1849 May 13 1975 rk.c -rw-rw-r-- 1 bin 2871 May 13 1975 rp.c -rw-rw-r-- 1 bin 748 May 13 1975 sys.c -rw-rw-r-- 1 bin 2572 May 13 1975 tc.c -rw-rw-r-- 1 bin 3764 May 13 1975 tm.c -rw-rw-r-- 1 bin 10492 May 13 1975 tty.c -rw-rw-r-- 1 bin 1593 May 13 1975 vs.c -rw-rw-r-- 1 bin 884 May 13 1975 vt.c usr/sys/ken/. total 182 -rw-rw-r-- 1 bin 6132 Jun 18 1975 alloc.c -rw-rw-r-- 1 bin 2711 May 13 1975 clock.c -rw-rw-r-- 1 bin 4268 May 13 1975 fio.c -rw-rw-r-- 1 bin 4258 May 13 1975 iget.c -rw-rw-r-- 1 bin 4374 May 13 1975 main.c -rw-rw-r-- 1 bin 1699 May 13 1975 malloc.c -rw-rw-r-- 1 bin 3490 May 13 1975 nami.c -rw-rw-r-- 1 bin 3268 May 13 1975 pipe.c -rw-rw-r-- 1 bin 2351 May 13 1975 prf.c -rw-rw-r-- 1 bin 3776 May 13 1975 rdwri.c -rw-rw-r-- 1 bin 6100 May 20 1975 sig.c -rw-rw-r-- 1 bin 9531 Jun 22 1975 slp.c -rw-rw-r-- 1 bin 3495 May 13 1975 subr.c -rw-rw-r-- 1 bin 6937 May 20 1975 sys1.c -rw-rw-r-- 1 bin 4136 May 13 1975 sys2.c -rw-rw-r-- 1 bin 3098 May 13 1975 sys3.c -rw-rw-r-- 1 bin 3716 May 13 1975 sys4.c -rw-rw-r-- 1 bin 2181 May 13 1975 sysent.c -rw-rw-r-- 1 bin 3254 May 13 1975 text.c -rw-rw-r-- 1 bin 4386 May 20 1975 trap.c usr/tmp/. total 0 -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Apr 7 10:18:14 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 6 Apr 2020 20:18:14 -0400 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: <20200406234758.GA27062@minnie.tuhs.org> References: <20200406221138.GA10092@minnie.tuhs.org> <20200406234758.GA27062@minnie.tuhs.org> Message-ID: On Mon, 6 Apr 2020 at 19:48, Warren Toomey wrote: > On Tue, Apr 07, 2020 at 08:11:38AM +1000, Warren Toomey wrote: > > Anybody feel up for a bit of an archaeology challenge? Warner Losh is > > currently poking through a bunch of bits but not having much luck > decoding > > them correctly. I've put a copy here: > https://minnie.tuhs.org/Y5/Challenge/ > > Warner has more to report: > > set cpu 11/45 [on SimH] was the missing magic. > The first two data sets are V6 system. Lots of dates around May 13, > 1975 for sure. > The second file from the tape is /usr/source from v6: usr/source/. total 36 drwxrwxr-x 2 bin 368 May 27 1975 as drwxrwxr-x 2 bin 928 May 27 1975 c drwxrwxr-x 5 bin 128 May 13 1975 cref drwxrwxr-x 11 bin 288 May 28 1975 fort drwxrwxr-x 2 bin 1248 May 27 1975 iolib drwxrwxr-x 2 bin 320 May 27 1975 m6 drwxrwxr-x 2 bin 448 Jun 26 1975 mdec drwxrwxr-x 2 bin 256 May 27 1975 rat -rw-rw-r-- 1 bin 753 May 18 1975 run drwxrwxr-x 2 bin 1696 Jun 22 1975 s1 drwxrwxr-x 2 bin 1280 May 27 1975 s2 drwxrwxr-x 2 bin 816 May 27 1975 s3 drwxrwxr-x 2 bin 2544 May 27 1975 s4 drwxrwxr-x 2 bin 1264 May 27 1975 s5 drwxrwxr-x 2 bin 800 May 27 1975 s7 drwxrwxr-x 2 bin 384 May 27 1975 salloc drwxrwxr-x 2 bin 224 May 27 1975 sno drwxrwxr-x 3 bin 176 May 27 1975 tmg drwxrwxr-x 4 bin 80 May 13 1975 yacc usr/source/as/. total 97 -rw-rw-r-- 1 bin 1175 May 13 1975 as11.s -rw-rw-r-- 1 bin 789 May 13 1975 as12.s -rw-rw-r-- 1 bin 1473 May 13 1975 as13.s -rw-rw-r-- 1 bin 2593 May 13 1975 as14.s -rw-rw-r-- 1 bin 1615 May 13 1975 as15.s -rw-rw-r-- 1 bin 2917 May 13 1975 as16.s -rw-rw-r-- 1 bin 2238 May 13 1975 as17.s -rw-rw-r-- 1 bin 1273 May 13 1975 as18.s -rw-rw-r-- 1 bin 6755 May 13 1975 as19.s -rw-rw-r-- 1 bin 3170 May 13 1975 as21.s -rw-rw-r-- 1 bin 1725 May 13 1975 as22.s -rw-rw-r-- 1 bin 1805 May 13 1975 as23.s -rw-rw-r-- 1 bin 1390 May 13 1975 as24.s -rw-rw-r-- 1 bin 71 May 13 1975 as25.s -rw-rw-r-- 1 bin 6056 May 13 1975 as26.s -rw-rw-r-- 1 bin 3178 May 13 1975 as27.s -rw-rw-r-- 1 bin 918 May 13 1975 as28.s -rw-rw-r-- 1 bin 3953 May 13 1975 as29.s -rw-rw-r-- 1 bin 96 May 17 1975 run usr/source/c/. total 261 -rw-rw-r-- 1 bin 12150 May 13 1975 c00.c -rw-rw-r-- 1 bin 6477 May 13 1975 c01.c -rw-rw-r-- 1 bin 13353 May 15 1975 c02.c -rw-rw-r-- 1 bin 2520 May 13 1975 c03.c -rw-rw-r-- 1 bin 4255 May 13 1975 c04.c -rw-rw-r-- 1 bin 4452 May 13 1975 c0h.c -rw-rw-r-- 1 bin 1704 May 27 1975 c0t.s -rw-rw-r-- 1 bin 14545 May 13 1975 c10.c -rw-rw-r-- 1 bin 8931 May 13 1975 c11.c -rw-rw-r-- 1 bin 10425 May 15 1975 c12.c -rw-rw-r-- 1 bin 3036 May 13 1975 c13.c -rw-rw-r-- 1 bin 3165 May 13 1975 c1h.c -rw-rw-r-- 1 bin 1679 May 13 1975 c1t.s -rw-rw-r-- 1 bin 11086 May 13 1975 c20.c -rw-rw-r-- 1 bin 9745 May 13 1975 c21.c -rw-rw-r-- 1 bin 1735 May 13 1975 c2h.c -rw-rw-r-- 1 bin 4335 May 13 1975 cvopt.c -rw-rw-r-- 1 bin 468 May 16 1975 run -rw-rw-r-- 1 bin 8581 May 13 1975 table.s usr/source/cref/. total 7 -rw-rw-r-- 1 bin 861 May 13 1975 ccmn.h drwxrwxr-x 2 bin 192 May 27 1975 index -rw-rw-r-- 1 bin 489 May 13 1975 mcons.h -rw-rw-r-- 1 bin 401 May 17 1975 run drwxrwxr-x 2 bin 208 May 27 1975 src drwxrwxr-x 2 bin 224 May 27 1975 tab usr/source/cref/index/. total 25 -rw-rw-r-- 1 bin 744 May 13 1975 ecmn.h -rw-rw-r-- 1 bin 362 May 13 1975 econs.h -rw-rw-r-- 1 bin 5532 May 13 1975 ind0.c -rw-rw-r-- 1 bin 3725 May 13 1975 ind1.c -rw-rw-r-- 1 bin 548 May 13 1975 ind2.c usr/source/cref/src/. total 44 -rw-rw-r-- 1 bin 6570 May 13 1975 acts.c -rw-rw-r-- 1 bin 3409 May 13 1975 crpost.c -rw-rw-r-- 1 bin 7166 May 13 1975 dr.c -rw-rw-r-- 1 bin 800 May 13 1975 put.c -rw-rw-r-- 1 bin 2577 May 13 1975 upost.c usr/source/cref/tab/. total 24 -rw-rw-r-- 1 bin 3032 May 13 1975 atable -rw-rw-r-- 1 bin 3073 May 13 1975 ctable -rw-rw-r-- 1 bin 2371 May 13 1975 etable -rw-rw-r-- 1 bin 3023 May 13 1975 mtab.c usr/source/fort/. total 24 drwxrwxr-x 2 bin 320 May 27 1975 f1 drwxrwxr-x 2 bin 224 May 27 1975 f2 drwxrwxr-x 2 bin 384 May 27 1975 f3 drwxrwxr-x 2 bin 320 May 27 1975 f4 drwxrwxr-x 2 bin 720 May 27 1975 fx drwxrwxr-x 2 bin 192 May 27 1975 io drwxrwxr-x 2 bin 640 May 27 1975 rt drwxrwxr-x 2 bin 1440 May 27 1975 rt1 drwxrwxr-x 2 bin 288 May 27 1975 rt2 -rw-rw-r-- 1 bin 3744 May 13 1975 run -rw-rw-r-- 1 bin 1198 May 13 1975 sum.s usr/source/fort/f1/. total 18 -rw-rw-r-- 1 bin 1897 May 13 1975 f11.s -rw-rw-r-- 1 bin 1220 May 13 1975 f12.s -rw-rw-r-- 1 bin 1355 May 13 1975 f13.s -rw-rw-r-- 1 bin 1195 May 13 1975 f14.s -rw-rw-r-- 1 bin 945 May 13 1975 f15.s -rw-rw-r-- 1 bin 425 May 13 1975 f16.s -rw-rw-r-- 1 bin 799 May 13 1975 f17.s usr/source/fort/f2/. total 14 -rw-rw-r-- 1 bin 303 May 13 1975 f21.s -rw-rw-r-- 1 bin 1512 May 13 1975 f22.s -rw-rw-r-- 1 bin 2019 May 13 1975 f23.s -rw-rw-r-- 1 bin 2722 May 13 1975 f24.s usr/source/fort/f3/. total 44 -rw-rw-r-- 1 bin 2001 May 13 1975 f31.s -rw-rw-r-- 1 bin 2583 May 13 1975 f32.s -rw-rw-r-- 1 bin 1666 May 13 1975 f33.s -rw-rw-r-- 1 bin 752 May 13 1975 f34.s -rw-rw-r-- 1 bin 1095 May 13 1975 f35.s -rw-rw-r-- 1 bin 5655 May 13 1975 f36.s -rw-rw-r-- 1 bin 1151 May 13 1975 f37.s -rw-rw-r-- 1 bin 1051 May 13 1975 f38.s -rw-rw-r-- 1 bin 3004 May 13 1975 f39.s usr/source/fort/f4/. total 26 -rw-rw-r-- 1 bin 528 May 13 1975 f41.s -rw-rw-r-- 1 bin 1216 May 13 1975 f42.s -rw-rw-r-- 1 bin 946 May 13 1975 f43.s -rw-rw-r-- 1 bin 1194 May 13 1975 f44.s -rw-rw-r-- 1 bin 1652 May 13 1975 f45.s -rw-rw-r-- 1 bin 1676 May 13 1975 f46.s -rw-rw-r-- 1 bin 3967 May 13 1975 f47.s usr/source/fort/fx/. total 54 -rw-rw-r-- 1 bin 783 May 13 1975 fhd.s -rw-rw-r-- 1 bin 513 May 13 1975 fx1.s -rw-rw-r-- 1 bin 1450 May 13 1975 fx2.s -rw-rw-r-- 1 bin 589 May 13 1975 fx3.s -rw-rw-r-- 1 bin 4158 May 13 1975 fx4.s -rw-rw-r-- 1 bin 564 May 13 1975 fx5.s -rw-rw-r-- 1 bin 323 May 13 1975 fx6.s -rw-rw-r-- 1 bin 293 May 13 1975 fx7.s -rw-rw-r-- 1 bin 2774 May 13 1975 fx8.s -rw-rw-r-- 1 bin 1365 May 13 1975 fx9.s -rw-rw-r-- 1 bin 397 May 13 1975 fxa.s -rw-rw-r-- 1 bin 366 May 13 1975 fxb.s -rw-rw-r-- 1 bin 414 May 13 1975 fxc.s -rw-rw-r-- 1 bin 555 May 13 1975 fxd.s -rw-rw-r-- 1 bin 299 May 13 1975 fxe.s -rw-rw-r-- 1 bin 287 May 13 1975 fxf.s -rw-rw-r-- 1 bin 2869 May 13 1975 fxg.s -rw-rw-r-- 1 bin 1101 May 13 1975 fxh.s -rw-rw-r-- 1 bin 1510 May 13 1975 fxi.s -rw-rw-r-- 1 bin 1282 May 13 1975 fxx.s usr/source/fort/io/. total 31 -rw-rw-r-- 1 bin 742 May 13 1975 io1.s -rw-rw-r-- 1 bin 2753 May 13 1975 io2.s -rw-rw-r-- 1 bin 3161 May 13 1975 io3.s -rw-rw-r-- 1 bin 2276 May 13 1975 io4.s -rw-rw-r-- 1 bin 961 May 13 1975 io5.s -rw-rw-r-- 1 bin 2268 May 13 1975 io6.s -rw-rw-r-- 1 bin 721 May 13 1975 io7.s -rw-rw-r-- 1 bin 603 May 13 1975 iox.s usr/source/fort/rt/. total 41 -rw-rw-r-- 1 bin 557 May 13 1975 r0.s -rw-rw-r-- 1 bin 1478 May 13 1975 r1.s -rw-rw-r-- 1 bin 1305 May 13 1975 r2.s -rw-rw-r-- 1 bin 437 May 13 1975 r3.s -rw-rw-r-- 1 bin 641 May 13 1975 r4.s -rw-rw-r-- 1 bin 491 May 13 1975 r5.s -rw-rw-r-- 1 bin 1107 May 13 1975 r6.s -rw-rw-r-- 1 bin 1368 May 13 1975 r7.s -rw-rw-r-- 1 bin 339 May 13 1975 r8.s -rw-rw-r-- 1 bin 617 May 13 1975 r9.s -rw-rw-r-- 1 bin 417 May 13 1975 ra.s -rw-rw-r-- 1 bin 579 May 13 1975 rb.s -rw-rw-r-- 1 bin 2934 May 13 1975 rc.s -rw-rw-r-- 1 bin 423 May 13 1975 rd.s -rw-rw-r-- 1 bin 547 May 13 1975 re.s -rw-rw-r-- 1 bin 531 May 13 1975 rf.s -rw-rw-r-- 1 bin 959 May 13 1975 rg.s -rw-rw-r-- 1 bin 1428 May 13 1975 rh.s -rw-rw-r-- 1 bin 106 May 13 1975 rx.s usr/source/fort/rt1/. total 46 -rw-rw-r-- 1 bin 245 May 13 1975 abs.s -rw-rw-r-- 1 bin 223 May 13 1975 aimag.s -rw-rw-r-- 1 bin 211 May 13 1975 aint.s -rw-rw-r-- 1 bin 307 May 13 1975 alog.s -rw-rw-r-- 1 bin 360 May 13 1975 alog10.s -rw-rw-r-- 1 bin 450 May 13 1975 amax0.s -rw-rw-r-- 1 bin 542 May 13 1975 amax1.s -rw-rw-r-- 1 bin 450 May 13 1975 amin0.s -rw-rw-r-- 1 bin 510 May 13 1975 amin1.s -rw-rw-r-- 1 bin 384 May 13 1975 amod.s -rw-rw-r-- 1 bin 267 May 13 1975 atan.s -rw-rw-r-- 1 bin 345 May 13 1975 atan2.s -rw-rw-r-- 1 bin 595 May 13 1975 cabs.s -rw-rw-r-- 1 bin 205 May 13 1975 ccos.f -rw-rw-r-- 1 bin 405 May 13 1975 cexp.s -rw-rw-r-- 1 bin 182 May 13 1975 clog.f -rw-rw-r-- 1 bin 361 May 13 1975 cmplx.s -rw-rw-r-- 1 bin 251 May 13 1975 conjg.s -rw-rw-r-- 1 bin 259 May 13 1975 cos.s -rw-rw-r-- 1 bin 205 May 13 1975 csin.f -rw-rw-r-- 1 bin 217 May 13 1975 csqrt.f -rw-rw-r-- 1 bin 224 May 13 1975 dble.s -rw-rw-r-- 1 bin 243 May 13 1975 dccos.f -rw-rw-r-- 1 bin 214 May 13 1975 dclog.f -rw-rw-r-- 1 bin 243 May 13 1975 dcsin.f -rw-rw-r-- 1 bin 250 May 13 1975 dcsqrt.f -rw-rw-r-- 1 bin 280 May 13 1975 dim.s -rw-rw-r-- 1 bin 225 May 13 1975 dimag.s -rw-rw-r-- 1 bin 306 May 13 1975 exp.s -rw-rw-r-- 1 bin 227 May 13 1975 float.s -rw-rw-r-- 1 bin 201 May 13 1975 iabs.s -rw-rw-r-- 1 bin 303 May 13 1975 idim.s -rw-rw-r-- 1 bin 194 May 13 1975 idint.s -rw-rw-r-- 1 bin 785 May 13 1975 ierr.s -rw-rw-r-- 1 bin 249 May 13 1975 ifix.s -rw-rw-r-- 1 bin 304 May 13 1975 isign.s -rw-rw-r-- 1 bin 337 May 13 1975 mod.s -rw-rw-r-- 1 bin 241 May 13 1975 real.s -rw-rw-r-- 1 bin 347 May 13 1975 sign.s -rw-rw-r-- 1 bin 259 May 13 1975 sin.s -rw-rw-r-- 1 bin 224 May 13 1975 sngl.s -rw-rw-r-- 1 bin 308 May 13 1975 sqrt.s -rw-rw-r-- 1 bin 75 May 13 1975 tanh.f usr/source/fort/rt2/. total 19 -rw-rw-r-- 1 bin 196 May 13 1975 ctime.s -rw-rw-r-- 1 bin 917 May 13 1975 getarg.s -rw-rw-r-- 1 bin 219 May 13 1975 nice.s -rw-rw-r-- 1 bin 647 May 13 1975 openrw.s -rw-rw-r-- 1 bin 1772 May 13 1975 plot.s -rw-rw-r-- 1 bin 467 May 13 1975 rand.s -rw-rw-r-- 1 bin 664 May 13 1975 rio.s -rw-rw-r-- 1 bin 405 May 13 1975 setfil.s -rw-rw-r-- 1 bin 2222 May 14 1975 uio.s usr/source/iolib/. total 65 -rw-rw-r-- 1 bin 1148 May 13 1975 alloc.c -rw-rw-r-- 1 bin 37 May 13 1975 calloc.c -rw-rw-r-- 1 bin 508 May 13 1975 cclose.c -rw-rw-r-- 1 bin 314 May 13 1975 ceof.c -rw-rw-r-- 1 bin 166 May 13 1975 cerror.c -rw-rw-r-- 1 bin 136 May 13 1975 cexit.c -rw-rw-r-- 1 bin 341 May 13 1975 cflush.c -rw-rw-r-- 1 bin 27 May 13 1975 cfree.c -rw-rw-r-- 1 bin 692 May 13 1975 cgetc.c -rw-rw-r-- 1 bin 118 May 13 1975 ciodec.c -rw-rw-r-- 1 bin 102 May 13 1975 clenf.c -rw-rw-r-- 1 bin 446 May 13 1975 copen.c -rw-rw-r-- 1 bin 601 May 13 1975 cputc.c -rw-rw-r-- 1 bin 359 May 13 1975 cwrd.c -rw-rw-r-- 1 bin 60 May 13 1975 dummy.s -rw-rw-r-- 1 bin 1766 May 13 1975 ftoa.c -rw-rw-r-- 1 bin 47 May 13 1975 getch.c -rw-rw-r-- 1 bin 251 May 13 1975 gets.c -rw-rw-r-- 1 bin 34 May 13 1975 getvec.c -rw-rw-r-- 1 bin 111 May 13 1975 iehzap.c -rw-rw-r-- 1 bin 735 May 13 1975 makbuf.c -rw-rw-r-- 1 bin 385 May 13 1975 maktab.c -rw-rw-r-- 1 bin 200 May 13 1975 nexch.c -rw-rw-r-- 1 bin 154 May 13 1975 nodig.c -rw-rw-r-- 1 bin 2276 May 13 1975 printf.c -rw-rw-r-- 1 bin 52 May 13 1975 putch.c -rw-rw-r-- 1 bin 190 May 13 1975 puts.c -rw-rw-r-- 1 bin 28 May 13 1975 relvec.c -rw-rw-r-- 1 bin 210 May 13 1975 revput.c -rw-rw-r-- 1 bin 696 May 16 1975 run -rw-rw-r-- 1 bin 2951 May 13 1975 scan1.c -rw-rw-r-- 1 bin 1675 May 13 1975 scan2.c -rw-rw-r-- 1 bin 1035 May 13 1975 scan3.c -rw-rw-r-- 1 bin 119 May 13 1975 system.c -rw-rw-r-- 1 bin 98 May 13 1975 tmpnam.c -rw-rw-r-- 1 bin 299 May 13 1975 unget.c -rw-rw-r-- 1 bin 2173 May 13 1975 unprnt.s -rw-rw-r-- 1 bin 187 May 13 1975 wdleng.c usr/source/m6/. total 26 -rw-rw-r-- 1 bin 1753 May 13 1975 m6.h -rw-rw-r-- 1 bin 426 May 13 1975 m61.c -rw-rw-r-- 1 bin 1432 May 13 1975 m62.c -rw-rw-r-- 1 bin 1188 May 13 1975 m63.c -rw-rw-r-- 1 bin 1167 May 13 1975 m64.c -rw-rw-r-- 1 bin 1130 May 13 1975 m65.c -rw-rw-r-- 1 bin 2436 May 13 1975 m66.c -rw-rw-r-- 1 bin 1351 May 13 1975 m67.c -rw-rw-r-- 1 bin 50 May 13 1975 run usr/source/mdec/. total 67 -rw-rw-r-- 1 bin 740 Jun 26 1975 dldr.s -rw-rw-r-- 1 bin 3794 Jun 26 1975 dtf.s -rw-rw-r-- 1 bin 2294 Jun 26 1975 fsboot.s -rw-rw-r-- 1 bin 485 Jun 26 1975 hp.s -rw-rw-r-- 1 bin 680 Jun 26 1975 ht.s -rw-rw-r-- 1 bin 645 Jun 26 1975 mak -rw-rw-r-- 1 bin 2646 Jun 26 1975 mboot.s -rw-rw-r-- 1 bin 634 Jun 26 1975 mcopy.s -rw-rw-r-- 1 bin 19 Jun 26 1975 reset.s -rw-rw-r-- 1 bin 28 Jun 26 1975 rhp.s -rw-rw-r-- 1 bin 194 Jun 26 1975 rk.s -rw-rw-r-- 1 bin 437 Jun 26 1975 rkf.s -rw-rw-r-- 1 bin 249 Jun 26 1975 rp.s -rw-rw-r-- 1 bin 27 Jun 26 1975 rrk.s -rw-rw-r-- 1 bin 27 Jun 26 1975 rrp.s -rw-rw-r-- 1 bin 1027 Jun 26 1975 run -rw-rw-r-- 1 bin 2646 Jun 26 1975 tboot.s -rw-rw-r-- 1 bin 451 Jun 26 1975 tc.s -rw-rw-r-- 1 bin 3764 Jun 26 1975 tcf.s -rw-rw-r-- 1 bin 532 Jun 26 1975 tm.s -rw-rw-r-- 1 bin 1016 Jun 26 1975 tpboot.s -rw-rw-r-- 1 bin 738 Jun 26 1975 tty.s -rw-rw-r-- 1 bin 2447 Jun 26 1975 uboot.s -rw-rw-r-- 1 bin 29 Jun 26 1975 whp.s -rw-rw-r-- 1 bin 28 Jun 26 1975 wrk.s -rw-rw-r-- 1 bin 28 Jun 26 1975 wrp.s usr/source/rat/. total 30 -rw-rw-r-- 1 bin 5164 May 13 1975 lex.c -rw-rw-r-- 1 bin 864 May 13 1975 r.g -rw-rw-r-- 1 bin 132 May 13 1975 r.h -rw-rw-r-- 1 bin 4476 May 13 1975 r1.c -rw-rw-r-- 1 bin 1612 May 13 1975 r2.c -rw-rw-r-- 1 bin 89 May 14 1975 run usr/source/s1/. total 746 -rw-rw-r-- 1 bin 4159 May 13 1975 ac.c -rw-rw-r-- 1 bin 5782 May 13 1975 ar.s -rw-rw-r-- 1 bin 2995 May 14 1975 banner.c -rw-rw-r-- 1 bin 23474 May 13 1975 bas.s -rw-rw-r-- 1 bin 11348 May 14 1975 bc.y -rw-rw-r-- 1 bin 1773 May 13 1975 bcd.c -rw-rw-r-- 1 bin 2606 May 13 1975 cal.c -rw-rw-r-- 1 bin 647 May 13 1975 cat.s -rw-rw-r-- 1 bin 12902 May 17 1975 cc.c -rw-rw-r-- 1 bin 14561 May 13 1975 cdb1.c -rw-rw-r-- 1 bin 6854 May 13 1975 cdb2.c -rw-rw-r-- 1 bin 1169 May 13 1975 chgrp.s -rw-rw-r-- 1 bin 381 May 13 1975 chmod.c -rw-rw-r-- 1 bin 1161 May 13 1975 chown.s -rw-rw-r-- 1 bin 737 May 13 1975 clri.s -rw-rw-r-- 1 bin 1287 May 13 1975 cmp.c -rw-rw-r-- 1 bin 1862 Jun 22 1975 col.c -rw-rw-r-- 1 bin 2122 May 13 1975 comm.c -rw-rw-r-- 1 bin 1063 May 13 1975 cp.c -rw-rw-r-- 1 bin 364 May 13 1975 cpall.c -rw-rw-r-- 1 bin 3202 May 13 1975 cron.c -rw-rw-r-- 1 bin 3020 May 13 1975 crypt.c -rw-rw-r-- 1 bin 2203 May 13 1975 date.c -rw-rw-r-- 1 bin 8758 May 13 1975 db1.s -rw-rw-r-- 1 bin 3595 May 13 1975 db2.s -rw-rw-r-- 1 bin 6575 May 13 1975 db3.s -rw-rw-r-- 1 bin 647 May 13 1975 db4.s -rw-rw-r-- 1 bin 29076 May 13 1975 dc1.s -rw-rw-r-- 1 bin 6009 May 13 1975 dc2.s -rw-rw-r-- 1 bin 5885 May 13 1975 dc3.s -rw-rw-r-- 1 bin 5396 May 13 1975 dc4.s -rw-rw-r-- 1 bin 7432 May 13 1975 dc5.s -rw-rw-r-- 1 bin 3332 May 13 1975 dcheck.c -rw-rw-r-- 1 bin 7702 May 13 1975 dd.c -rw-rw-r-- 1 bin 1282 May 13 1975 df.c -rw-rw-r-- 1 bin 9373 May 13 1975 diff1.c -rw-rw-r-- 1 bin 736 May 13 1975 diff2.s -rw-rw-r-- 1 bin 1037 May 13 1975 dsw.s -rw-rw-r-- 1 bin 2113 May 13 1975 du.s -rw-rw-r-- 1 bin 6751 May 13 1975 dump.c -rw-rw-r-- 1 bin 134 May 13 1975 echo.c -rw-rw-r-- 1 bin 17889 May 13 1975 ed.c -rw-rw-r-- 1 bin 53 May 13 1975 exit.c -rw-rw-r-- 1 bin 6864 May 13 1975 fc.c -rw-rw-r-- 1 bin 1201 May 13 1975 fed1.s -rw-rw-r-- 1 bin 5766 May 13 1975 fed2.s -rw-rw-r-- 1 bin 4192 May 13 1975 fed3.s -rw-rw-r-- 1 bin 4181 May 13 1975 file.c -rw-rw-r-- 1 bin 9159 May 13 1975 find.c -rw-rw-r-- 1 bin 2116 May 13 1975 form1.s -rw-rw-r-- 1 bin 1019 May 13 1975 form2.s -rw-rw-r-- 1 bin 1685 May 13 1975 form3.s -rw-rw-r-- 1 bin 2820 May 13 1975 form4.s -rw-rw-r-- 1 bin 9729 May 13 1975 form5.s -rw-rw-r-- 1 bin 6478 May 13 1975 form6.s -rw-rw-r-- 1 bin 3291 May 13 1975 getty.c -rw-rw-r-- 1 bin 3698 May 13 1975 glob.c -rw-rw-r-- 1 bin 844 May 13 1975 goto.c -rw-rw-r-- 1 bin 4618 May 13 1975 grep.c -rw-rw-r-- 1 bin 3951 May 13 1975 gsi.c -rw-rw-r-- 1 bin 5050 May 13 1975 icheck.c -rw-rw-r-- 1 bin 1971 May 13 1975 if.c -rw-rw-r-- 1 bin 3058 May 13 1975 init.c -rw-rw-r-- 1 bin 730 May 13 1975 kill.s -rw-rw-r-- 1 bin 15577 May 13 1975 ld.c -rw-rw-r-- 1 bin 686 May 13 1975 ln.c -rw-rw-r-- 1 bin 3017 May 13 1975 login.c -rw-rw-r-- 1 bin 2421 May 13 1975 lpd.s -rw-rw-r-- 1 bin 3366 May 13 1975 lpr.c -rw-rw-r-- 1 bin 7663 May 13 1975 ls.c -rw-rw-r-- 1 bin 2231 Jun 22 1975 run usr/source/s2/. total 393 -rw-rw-r-- 1 bin 4155 May 13 1975 mail.c -rw-rw-r-- 1 bin 662 May 13 1975 mesg.c -rw-rw-r-- 1 bin 1088 May 13 1975 mkdir.s -rw-rw-r-- 1 bin 7581 May 13 1975 mkfs.c -rw-rw-r-- 1 bin 563 May 13 1975 mknod.c -rw-rw-r-- 1 bin 1155 May 13 1975 mount.c -rw-rw-r-- 1 bin 2996 May 13 1975 mv.c -rw-rw-r-- 1 bin 4398 May 13 1975 ncheck.c -rw-rw-r-- 1 bin 2123 May 13 1975 newgrp.c -rw-rw-r-- 1 bin 640 May 13 1975 nice.c -rw-rw-r-- 1 bin 2100 May 13 1975 nm.c -rw-rw-r-- 1 bin 530 May 13 1975 nohup.c -rw-rw-r-- 1 bin 7157 May 13 1975 od.c -rw-rw-r-- 1 bin 464 May 13 1975 opr.c -rw-rw-r-- 1 bin 2295 May 13 1975 passwd.c -rw-rw-r-- 1 bin 492 May 13 1975 pfe.s -rw-rw-r-- 1 bin 5895 May 13 1975 pr.c -rw-rw-r-- 1 bin 5486 May 13 1975 prof.c -rw-rw-r-- 1 bin 4570 May 13 1975 ps.c -rw-rw-r-- 1 bin 3260 May 13 1975 ptx.c -rw-rw-r-- 1 bin 1199 May 13 1975 pwd.c -rw-rw-r-- 1 bin 6062 May 13 1975 quiz.c -rw-rw-r-- 1 bin 5969 May 13 1975 rc.c -rw-rw-r-- 1 bin 7810 May 13 1975 restor.c -rw-rw-r-- 1 bin 451 May 13 1975 rew.s -rw-rw-r-- 1 bin 1483 May 13 1975 rm.c -rw-rw-r-- 1 bin 1197 May 13 1975 rmdir.s -rw-rw-r-- 1 bin 2153 May 14 1975 run -rw-rw-r-- 1 bin 6921 May 13 1975 sa.c -rw-rw-r-- 1 bin 11645 May 13 1975 sh.c -rw-rw-r-- 1 bin 580 May 13 1975 size.c -rw-rw-r-- 1 bin 255 May 13 1975 sleep.c -rw-rw-r-- 1 bin 8973 May 13 1975 sort.c -rw-rw-r-- 1 bin 1242 May 13 1975 split.c -rw-rw-r-- 1 bin 1725 May 13 1975 strip.s -rw-rw-r-- 1 bin 3678 May 13 1975 stty.c -rw-rw-r-- 1 bin 741 May 13 1975 su.c -rw-rw-r-- 1 bin 836 May 13 1975 sum.s -rw-rw-r-- 1 bin 21 May 13 1975 sync.c -rw-rw-r-- 1 bin 6282 May 13 1975 tbl.c -rw-rw-r-- 1 bin 696 May 13 1975 tee.c -rw-rw-r-- 1 bin 2342 May 13 1975 time.s -rw-rw-r-- 1 bin 2763 May 13 1975 tp1.s -rw-rw-r-- 1 bin 4828 May 13 1975 tp2.s -rw-rw-r-- 1 bin 5844 May 13 1975 tp3.s -rw-rw-r-- 1 bin 603 May 13 1975 tp4.s -rw-rw-r-- 1 bin 2395 May 13 1975 tr.c -rw-rw-r-- 1 bin 151 May 13 1975 tty.s -rw-rw-r-- 1 bin 6533 May 13 1975 typo.c -rw-rw-r-- 1 bin 940 May 13 1975 umount.c -rw-rw-r-- 1 bin 1955 May 13 1975 uniq.c -rw-rw-r-- 1 bin 6075 May 13 1975 units.c -rw-rw-r-- 1 bin 161 May 13 1975 update.s -rw-rw-r-- 1 bin 8936 May 13 1975 usort.c -rw-rw-r-- 1 bin 949 May 13 1975 wall.c -rw-rw-r-- 1 bin 1229 May 13 1975 wc.c -rw-rw-r-- 1 bin 954 May 13 1975 who.c -rw-rw-r-- 1 bin 2174 May 13 1975 write.s usr/source/s3/. total 82 -rw-rw-r-- 1 bin 2587 May 13 1975 atan.s -rw-rw-r-- 1 bin 2082 May 13 1975 crypt.s -rw-rw-r-- 1 bin 211 May 13 1975 dpadd.s -rw-rw-r-- 1 bin 1958 May 13 1975 ecvt.s -rw-rw-r-- 1 bin 1917 May 13 1975 exp.s -rw-rw-r-- 1 bin 134 May 13 1975 fakfp.s -rw-rw-r-- 1 bin 385 May 13 1975 floor.s -rw-rw-r-- 1 bin 265 May 13 1975 fmod.s -rw-rw-r-- 1 bin 4506 May 13 1975 fp1.s -rw-rw-r-- 1 bin 1945 May 13 1975 fp2.s -rw-rw-r-- 1 bin 3385 May 13 1975 fp3.s -rw-rw-r-- 1 bin 332 May 13 1975 fpx.s -rw-rw-r-- 1 bin 4230 May 13 1975 gamma.s -rw-rw-r-- 1 bin 1267 May 13 1975 get.s -rw-rw-r-- 1 bin 233 May 13 1975 ldiv.s -rw-rw-r-- 1 bin 1802 May 13 1975 log.s -rw-rw-r-- 1 bin 318 May 13 1975 mesg.s -rw-rw-r-- 1 bin 552 May 13 1975 pow.s -rw-rw-r-- 1 bin 1246 May 13 1975 put.s -rw-rw-r-- 1 bin 290 May 13 1975 rand.s -rw-rw-r-- 1 bin 618 May 14 1975 run -rw-rw-r-- 1 bin 84 May 13 1975 savr5.s -rw-rw-r-- 1 bin 2012 May 13 1975 sin.s -rw-rw-r-- 1 bin 719 May 13 1975 sqrt.s -rw-rw-r-- 1 bin 508 May 13 1975 switch.s -rw-rw-r-- 1 bin 583 May 13 1975 ttyn.s usr/source/s4/. total 63 -rw-rw-r-- 1 bin 105 May 13 1975 abort.s -rw-rw-r-- 1 bin 165 May 13 1975 abs.s -rw-rw-r-- 1 bin 2464 May 13 1975 alloc.s -rw-rw-r-- 1 bin 1232 May 13 1975 atof.s -rw-rw-r-- 1 bin 268 May 13 1975 atoi.c -rw-rw-r-- 1 bin 151 May 13 1975 cerror.s -rw-rw-r-- 1 bin 208 May 13 1975 chdir.s -rw-rw-r-- 1 bin 234 May 13 1975 chmod.s -rw-rw-r-- 1 bin 235 May 13 1975 chown.s -rw-rw-r-- 1 bin 181 May 13 1975 close.s -rw-rw-r-- 1 bin 249 May 13 1975 creat.s -rw-rw-r-- 1 bin 200 May 13 1975 crt0.s -rw-rw-r-- 1 bin 255 May 13 1975 csv.s -rw-rw-r-- 1 bin 4367 May 13 1975 ctime.c -rw-rw-r-- 1 bin 186 May 13 1975 dup.s -rw-rw-r-- 1 bin 772 May 13 1975 errlst.c -rw-rw-r-- 1 bin 218 May 13 1975 execl.s -rw-rw-r-- 1 bin 531 May 13 1975 execv.s -rw-rw-r-- 1 bin 139 May 13 1975 exit.s -rw-rw-r-- 1 bin 271 May 13 1975 fcrt0.s -rw-rw-r-- 1 bin 116 May 13 1975 ffltpr.s -rw-rw-r-- 1 bin 924 May 13 1975 fltpr.s -rw-rw-r-- 1 bin 321 May 13 1975 fork.s -rw-rw-r-- 1 bin 287 May 13 1975 fstat.s -rw-rw-r-- 1 bin 957 May 13 1975 getc.s -rw-rw-r-- 1 bin 395 May 13 1975 getchr.s -rw-rw-r-- 1 bin 122 May 13 1975 getcsw.s -rw-rw-r-- 1 bin 141 May 13 1975 getgid.s -rw-rw-r-- 1 bin 127 May 13 1975 getpid.s -rw-rw-r-- 1 bin 605 May 13 1975 getpw.c -rw-rw-r-- 1 bin 128 May 13 1975 getuid.s -rw-rw-r-- 1 bin 304 May 13 1975 gtty.s -rw-rw-r-- 1 bin 57 May 13 1975 hmul.s -rw-rw-r-- 1 bin 218 May 13 1975 kill.s -rw-rw-r-- 1 bin 480 May 13 1975 ladd.s -rw-rw-r-- 1 bin 121 May 13 1975 ldfps.s -rw-rw-r-- 1 bin 237 May 13 1975 link.s -rw-rw-r-- 1 bin 559 May 13 1975 locv.s -rw-rw-r-- 1 bin 332 May 13 1975 ltod.s -rw-rw-r-- 1 bin 1040 May 16 1975 run usr/source/s5/. total 59 -rw-rw-r-- 1 bin 213 May 13 1975 makdir.s -rw-rw-r-- 1 bin 222 May 13 1975 mcount.s -rw-rw-r-- 1 bin 770 May 13 1975 mcrt0.s -rw-rw-r-- 1 bin 222 May 13 1975 mdate.s -rw-rw-r-- 1 bin 279 May 13 1975 mknod.s -rw-rw-r-- 1 bin 579 May 13 1975 mon.c -rw-rw-r-- 1 bin 256 May 13 1975 mount.s -rw-rw-r-- 1 bin 780 May 13 1975 nargs.s -rw-rw-r-- 1 bin 176 May 13 1975 nice.s -rw-rw-r-- 1 bin 1146 May 13 1975 nlist.s -rw-rw-r-- 1 bin 246 May 13 1975 open.s -rw-rw-r-- 1 bin 487 May 13 1975 perror.c -rw-rw-r-- 1 bin 214 May 13 1975 pipe.s -rw-rw-r-- 1 bin 2298 May 13 1975 printf.s -rw-rw-r-- 1 bin 192 May 13 1975 prof.s -rw-rw-r-- 1 bin 332 May 13 1975 ptrace.s -rw-rw-r-- 1 bin 1037 May 13 1975 putc.s -rw-rw-r-- 1 bin 585 May 13 1975 putchr.s -rw-rw-r-- 1 bin 1324 May 13 1975 qsort.c -rw-rw-r-- 1 bin 291 May 13 1975 read.s -rw-rw-r-- 1 bin 423 May 13 1975 reset.s -rw-rw-r-- 1 bin 335 May 13 1975 rin.c -rw-rw-r-- 1 bin 1059 May 16 1975 run -rw-rw-r-- 1 bin 531 May 13 1975 sbrk.s -rw-rw-r-- 1 bin 248 May 13 1975 seek.s -rw-rw-r-- 1 bin 197 May 13 1975 setgid.s -rw-rw-r-- 1 bin 184 May 13 1975 setuid.s -rw-rw-r-- 1 bin 1990 May 13 1975 signal.s -rw-rw-r-- 1 bin 107 May 13 1975 sleep.s -rw-rw-r-- 1 bin 290 May 13 1975 stat.s -rw-rw-r-- 1 bin 161 May 13 1975 stime.s -rw-rw-r-- 1 bin 304 May 13 1975 stty.s -rw-rw-r-- 1 bin 89 May 13 1975 sync.s -rw-rw-r-- 1 bin 229 May 13 1975 time.s -rw-rw-r-- 1 bin 155 May 13 1975 times.s -rw-rw-r-- 1 bin 223 May 13 1975 umount.s -rw-rw-r-- 1 bin 215 May 13 1975 unlink.s -rw-rw-r-- 1 bin 347 May 13 1975 wait.s -rw-rw-r-- 1 bin 281 May 13 1975 write.s usr/source/s7/. total 275 -rw-rw-r-- 1 bin 3476 May 13 1975 ne.g -rw-rw-r-- 1 bin 614 May 13 1975 ne.h -rw-rw-r-- 1 bin 4856 May 13 1975 ne1.c -rw-rw-r-- 1 bin 3125 May 13 1975 ne2.c -rw-rw-r-- 1 bin 2312 May 13 1975 ne3.c -rw-rw-r-- 1 bin 3539 May 13 1975 ne4.c -rw-rw-r-- 1 bin 595 May 13 1975 ne5.c -rw-rw-r-- 1 bin 1412 May 13 1975 ne6.c -rw-rw-r-- 1 bin 5039 May 13 1975 nelex.c -rw-rw-r-- 1 bin 14884 May 13 1975 nroff1.s -rw-rw-r-- 1 bin 12516 May 13 1975 nroff2.s -rw-rw-r-- 1 bin 12693 May 13 1975 nroff3.s -rw-rw-r-- 1 bin 9504 May 13 1975 nroff4.s -rw-rw-r-- 1 bin 4520 May 13 1975 nroff5.s -rw-rw-r-- 1 bin 3071 May 13 1975 nroff8.s -rw-rw-r-- 1 bin 6518 May 13 1975 roff1.s -rw-rw-r-- 1 bin 3990 May 13 1975 roff2.s -rw-rw-r-- 1 bin 4813 May 13 1975 roff3.s -rw-rw-r-- 1 bin 5149 May 13 1975 roff4.s -rw-rw-r-- 1 bin 3036 May 13 1975 roff5.s -rw-rw-r-- 1 bin 6207 May 13 1975 roff7.s -rw-rw-r-- 1 bin 1447 May 13 1975 roff8.s -rw-rw-r-- 1 bin 254 May 13 1975 run -rw-rw-r-- 1 bin 15373 May 13 1975 suftab.s usr/source/salloc/. total 36 -rw-rw-r-- 1 bin 2406 May 13 1975 alloc1.s -rw-rw-r-- 1 bin 3289 May 13 1975 alloc2.s -rw-rw-r-- 1 bin 6056 May 13 1975 alloc3.s -rw-rw-r-- 1 bin 936 May 13 1975 altch.s -rw-rw-r-- 1 bin 291 May 13 1975 bsp.s -rw-rw-r-- 1 bin 370 May 13 1975 bword.s -rw-rw-r-- 1 bin 300 May 13 1975 getch.s -rw-rw-r-- 1 bin 747 May 13 1975 getwd.s -rw-rw-r-- 1 bin 329 May 13 1975 length.s -rw-rw-r-- 1 bin 468 May 13 1975 rewind.s -rw-rw-r-- 1 bin 288 May 13 1975 run -rw-rw-r-- 1 bin 245 May 13 1975 zero.s usr/source/sno/. total 51 -rw-rw-r-- 1 bin 52 May 13 1975 run -rw-rw-r-- 1 bin 338 May 13 1975 sno.h -rw-rw-r-- 1 bin 6305 May 13 1975 sno1.c -rw-rw-r-- 1 bin 7723 May 13 1975 sno2.c -rw-rw-r-- 1 bin 3644 May 13 1975 sno3.c -rw-rw-r-- 1 bin 4176 May 13 1975 sno4.c usr/source/tmg/. total 72 -rw-rw-r-- 1 bin 1321 May 14 1975 run -rw-rw-r-- 1 bin 7577 May 13 1975 tmga.s drwxrwxr-x 2 bin 1280 May 27 1975 tmgb -rw-rw-r-- 1 bin 1989 May 13 1975 tmgc.s -rw-rw-r-- 1 bin 14863 May 13 1975 tmgl.s -rw-rw-r-- 1 bin 6751 May 13 1975 tmgl.t usr/source/tmg/tmgb/. total 47 -rw-rw-r-- 1 bin 178 May 13 1975 any.s -rw-rw-r-- 1 bin 165 May 13 1975 append.s -rw-rw-r-- 1 bin 787 May 13 1975 arith.s -rw-rw-r-- 1 bin 246 May 13 1975 bundle.s -rw-rw-r-- 1 bin 183 May 13 1975 char.s -rw-rw-r-- 1 bin 446 May 13 1975 copy.s -rw-rw-r-- 1 bin 1116 May 13 1975 cstr.s -rw-rw-r-- 1 bin 237 May 13 1975 ctest.s -rw-rw-r-- 1 bin 208 May 13 1975 decmal.s -rw-rw-r-- 1 bin 109 May 13 1975 discd.s -rw-rw-r-- 1 bin 592 May 13 1975 emit.s -rw-rw-r-- 1 bin 60 May 13 1975 end.s -rw-rw-r-- 1 bin 163 May 13 1975 f.s -rw-rw-r-- 1 bin 1328 May 13 1975 find.s -rw-rw-r-- 1 bin 612 May 13 1975 getnam.s -rw-rw-r-- 1 bin 94 May 13 1975 ignore.s -rw-rw-r-- 1 bin 238 May 13 1975 inc.s -rw-rw-r-- 1 bin 300 May 13 1975 infix.s -rw-rw-r-- 1 bin 470 May 13 1975 jget.s -rw-rw-r-- 1 bin 124 May 13 1975 lvrv.s -rw-rw-r-- 1 bin 249 May 13 1975 mult.s -rw-rw-r-- 1 bin 204 May 13 1975 octal.s -rw-rw-r-- 1 bin 142 May 13 1975 params.s -rw-rw-r-- 1 bin 329 May 13 1975 push.s -rw-rw-r-- 1 bin 260 May 13 1975 putcal.s -rw-rw-r-- 1 bin 309 May 13 1975 putdec.s -rw-rw-r-- 1 bin 184 May 13 1975 putoct.s -rw-rw-r-- 1 bin 393 May 13 1975 px.s -rw-rw-r-- 1 bin 431 May 13 1975 reln.s -rw-rw-r-- 1 bin 120 May 13 1975 shift.s -rw-rw-r-- 1 bin 1082 May 13 1975 stack.s -rw-rw-r-- 1 bin 194 May 13 1975 string.s -rw-rw-r-- 1 bin 231 May 13 1975 table.s -rw-rw-r-- 1 bin 353 May 13 1975 tq.s -rw-rw-r-- 1 bin 156 May 13 1975 trace.s -rw-rw-r-- 1 bin 81 May 13 1975 trans.s -rw-rw-r-- 1 bin 137 May 13 1975 tx.s -rw-rw-r-- 1 bin 168 May 13 1975 unary.s usr/source/yacc/. total 3 drwxrwxr-x 2 bin 208 May 27 1975 lib -rw-rw-r-- 1 bin 118 May 13 1975 run drwxrwxr-x 2 bin 272 May 27 1975 source usr/source/yacc/lib/. total 11 -rw-rw-r-- 1 bin 112 May 13 1975 main.c -rw-rw-r-- 1 bin 3284 May 13 1975 parser.c -rw-rw-r-- 1 bin 12 May 13 1975 zacc.c -rw-rw-r-- 1 bin 481 May 13 1975 zerr.c -rw-rw-r-- 1 bin 11 May 13 1975 zinit.c usr/source/yacc/source/. total 100 -rw-rw-r-- 1 bin 4402 May 13 1975 dextern -rw-rw-r-- 1 bin 3976 May 13 1975 y0.c -rw-rw-r-- 1 bin 6597 May 13 1975 y1.c -rw-rw-r-- 1 bin 12020 May 13 1975 y2.c -rw-rw-r-- 1 bin 9654 May 13 1975 y3.c -rw-rw-r-- 1 bin 9996 May 13 1975 y4.c -rw-rw-r-- 1 bin 572 May 13 1975 y5.c -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Apr 7 10:59:53 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Apr 2020 20:59:53 -0400 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: References: <20200406221138.GA10092@minnie.tuhs.org> <20200406234758.GA27062@minnie.tuhs.org> Message-ID: Henry/Warren -- each is an RK05 diskpack image. UNIX .SYS UNIX .SRC XENIX1.ARC XENIX2.ARC He used RT-11 to copy each disk pack sequentially. That's an ANSI VOL1 record. Sadly it's not a full ANSI tape (long story -- it needs HDR1 records VMS would have been able to mount it as a foreign tape. Take of the 4 big files, and use simh/PDP-11 and mount each of the files as a separate RK05 Clem On Mon, Apr 6, 2020 at 8:21 PM Henry Bent wrote: > On Mon, 6 Apr 2020 at 19:48, Warren Toomey wrote: > >> On Tue, Apr 07, 2020 at 08:11:38AM +1000, Warren Toomey wrote: >> > Anybody feel up for a bit of an archaeology challenge? Warner Losh is >> > currently poking through a bunch of bits but not having much luck >> decoding >> > them correctly. I've put a copy here: >> https://minnie.tuhs.org/Y5/Challenge/ >> >> Warner has more to report: >> >> set cpu 11/45 [on SimH] was the missing magic. >> The first two data sets are V6 system. Lots of dates around May 13, >> 1975 for sure. >> > > The second file from the tape is /usr/source from v6: > > usr/source/. > total 36 > drwxrwxr-x 2 bin 368 May 27 1975 as > drwxrwxr-x 2 bin 928 May 27 1975 c > drwxrwxr-x 5 bin 128 May 13 1975 cref > drwxrwxr-x 11 bin 288 May 28 1975 fort > drwxrwxr-x 2 bin 1248 May 27 1975 iolib > drwxrwxr-x 2 bin 320 May 27 1975 m6 > drwxrwxr-x 2 bin 448 Jun 26 1975 mdec > drwxrwxr-x 2 bin 256 May 27 1975 rat > -rw-rw-r-- 1 bin 753 May 18 1975 run > drwxrwxr-x 2 bin 1696 Jun 22 1975 s1 > drwxrwxr-x 2 bin 1280 May 27 1975 s2 > drwxrwxr-x 2 bin 816 May 27 1975 s3 > drwxrwxr-x 2 bin 2544 May 27 1975 s4 > drwxrwxr-x 2 bin 1264 May 27 1975 s5 > drwxrwxr-x 2 bin 800 May 27 1975 s7 > drwxrwxr-x 2 bin 384 May 27 1975 salloc > drwxrwxr-x 2 bin 224 May 27 1975 sno > drwxrwxr-x 3 bin 176 May 27 1975 tmg > drwxrwxr-x 4 bin 80 May 13 1975 yacc > > usr/source/as/. > total 97 > -rw-rw-r-- 1 bin 1175 May 13 1975 as11.s > -rw-rw-r-- 1 bin 789 May 13 1975 as12.s > -rw-rw-r-- 1 bin 1473 May 13 1975 as13.s > -rw-rw-r-- 1 bin 2593 May 13 1975 as14.s > -rw-rw-r-- 1 bin 1615 May 13 1975 as15.s > -rw-rw-r-- 1 bin 2917 May 13 1975 as16.s > -rw-rw-r-- 1 bin 2238 May 13 1975 as17.s > -rw-rw-r-- 1 bin 1273 May 13 1975 as18.s > -rw-rw-r-- 1 bin 6755 May 13 1975 as19.s > -rw-rw-r-- 1 bin 3170 May 13 1975 as21.s > -rw-rw-r-- 1 bin 1725 May 13 1975 as22.s > -rw-rw-r-- 1 bin 1805 May 13 1975 as23.s > -rw-rw-r-- 1 bin 1390 May 13 1975 as24.s > -rw-rw-r-- 1 bin 71 May 13 1975 as25.s > -rw-rw-r-- 1 bin 6056 May 13 1975 as26.s > -rw-rw-r-- 1 bin 3178 May 13 1975 as27.s > -rw-rw-r-- 1 bin 918 May 13 1975 as28.s > -rw-rw-r-- 1 bin 3953 May 13 1975 as29.s > -rw-rw-r-- 1 bin 96 May 17 1975 run > > usr/source/c/. > total 261 > -rw-rw-r-- 1 bin 12150 May 13 1975 c00.c > -rw-rw-r-- 1 bin 6477 May 13 1975 c01.c > -rw-rw-r-- 1 bin 13353 May 15 1975 c02.c > -rw-rw-r-- 1 bin 2520 May 13 1975 c03.c > -rw-rw-r-- 1 bin 4255 May 13 1975 c04.c > -rw-rw-r-- 1 bin 4452 May 13 1975 c0h.c > -rw-rw-r-- 1 bin 1704 May 27 1975 c0t.s > -rw-rw-r-- 1 bin 14545 May 13 1975 c10.c > -rw-rw-r-- 1 bin 8931 May 13 1975 c11.c > -rw-rw-r-- 1 bin 10425 May 15 1975 c12.c > -rw-rw-r-- 1 bin 3036 May 13 1975 c13.c > -rw-rw-r-- 1 bin 3165 May 13 1975 c1h.c > -rw-rw-r-- 1 bin 1679 May 13 1975 c1t.s > -rw-rw-r-- 1 bin 11086 May 13 1975 c20.c > -rw-rw-r-- 1 bin 9745 May 13 1975 c21.c > -rw-rw-r-- 1 bin 1735 May 13 1975 c2h.c > -rw-rw-r-- 1 bin 4335 May 13 1975 cvopt.c > -rw-rw-r-- 1 bin 468 May 16 1975 run > -rw-rw-r-- 1 bin 8581 May 13 1975 table.s > > usr/source/cref/. > total 7 > -rw-rw-r-- 1 bin 861 May 13 1975 ccmn.h > drwxrwxr-x 2 bin 192 May 27 1975 index > -rw-rw-r-- 1 bin 489 May 13 1975 mcons.h > -rw-rw-r-- 1 bin 401 May 17 1975 run > drwxrwxr-x 2 bin 208 May 27 1975 src > drwxrwxr-x 2 bin 224 May 27 1975 tab > > usr/source/cref/index/. > total 25 > -rw-rw-r-- 1 bin 744 May 13 1975 ecmn.h > -rw-rw-r-- 1 bin 362 May 13 1975 econs.h > -rw-rw-r-- 1 bin 5532 May 13 1975 ind0.c > -rw-rw-r-- 1 bin 3725 May 13 1975 ind1.c > -rw-rw-r-- 1 bin 548 May 13 1975 ind2.c > > usr/source/cref/src/. > total 44 > -rw-rw-r-- 1 bin 6570 May 13 1975 acts.c > -rw-rw-r-- 1 bin 3409 May 13 1975 crpost.c > -rw-rw-r-- 1 bin 7166 May 13 1975 dr.c > -rw-rw-r-- 1 bin 800 May 13 1975 put.c > -rw-rw-r-- 1 bin 2577 May 13 1975 upost.c > > usr/source/cref/tab/. > total 24 > -rw-rw-r-- 1 bin 3032 May 13 1975 atable > -rw-rw-r-- 1 bin 3073 May 13 1975 ctable > -rw-rw-r-- 1 bin 2371 May 13 1975 etable > -rw-rw-r-- 1 bin 3023 May 13 1975 mtab.c > > usr/source/fort/. > total 24 > drwxrwxr-x 2 bin 320 May 27 1975 f1 > drwxrwxr-x 2 bin 224 May 27 1975 f2 > drwxrwxr-x 2 bin 384 May 27 1975 f3 > drwxrwxr-x 2 bin 320 May 27 1975 f4 > drwxrwxr-x 2 bin 720 May 27 1975 fx > drwxrwxr-x 2 bin 192 May 27 1975 io > drwxrwxr-x 2 bin 640 May 27 1975 rt > drwxrwxr-x 2 bin 1440 May 27 1975 rt1 > drwxrwxr-x 2 bin 288 May 27 1975 rt2 > -rw-rw-r-- 1 bin 3744 May 13 1975 run > -rw-rw-r-- 1 bin 1198 May 13 1975 sum.s > > usr/source/fort/f1/. > total 18 > -rw-rw-r-- 1 bin 1897 May 13 1975 f11.s > -rw-rw-r-- 1 bin 1220 May 13 1975 f12.s > -rw-rw-r-- 1 bin 1355 May 13 1975 f13.s > -rw-rw-r-- 1 bin 1195 May 13 1975 f14.s > -rw-rw-r-- 1 bin 945 May 13 1975 f15.s > -rw-rw-r-- 1 bin 425 May 13 1975 f16.s > -rw-rw-r-- 1 bin 799 May 13 1975 f17.s > > usr/source/fort/f2/. > total 14 > -rw-rw-r-- 1 bin 303 May 13 1975 f21.s > -rw-rw-r-- 1 bin 1512 May 13 1975 f22.s > -rw-rw-r-- 1 bin 2019 May 13 1975 f23.s > -rw-rw-r-- 1 bin 2722 May 13 1975 f24.s > > usr/source/fort/f3/. > total 44 > -rw-rw-r-- 1 bin 2001 May 13 1975 f31.s > -rw-rw-r-- 1 bin 2583 May 13 1975 f32.s > -rw-rw-r-- 1 bin 1666 May 13 1975 f33.s > -rw-rw-r-- 1 bin 752 May 13 1975 f34.s > -rw-rw-r-- 1 bin 1095 May 13 1975 f35.s > -rw-rw-r-- 1 bin 5655 May 13 1975 f36.s > -rw-rw-r-- 1 bin 1151 May 13 1975 f37.s > -rw-rw-r-- 1 bin 1051 May 13 1975 f38.s > -rw-rw-r-- 1 bin 3004 May 13 1975 f39.s > > usr/source/fort/f4/. > total 26 > -rw-rw-r-- 1 bin 528 May 13 1975 f41.s > -rw-rw-r-- 1 bin 1216 May 13 1975 f42.s > -rw-rw-r-- 1 bin 946 May 13 1975 f43.s > -rw-rw-r-- 1 bin 1194 May 13 1975 f44.s > -rw-rw-r-- 1 bin 1652 May 13 1975 f45.s > -rw-rw-r-- 1 bin 1676 May 13 1975 f46.s > -rw-rw-r-- 1 bin 3967 May 13 1975 f47.s > > usr/source/fort/fx/. > total 54 > -rw-rw-r-- 1 bin 783 May 13 1975 fhd.s > -rw-rw-r-- 1 bin 513 May 13 1975 fx1.s > -rw-rw-r-- 1 bin 1450 May 13 1975 fx2.s > -rw-rw-r-- 1 bin 589 May 13 1975 fx3.s > -rw-rw-r-- 1 bin 4158 May 13 1975 fx4.s > -rw-rw-r-- 1 bin 564 May 13 1975 fx5.s > -rw-rw-r-- 1 bin 323 May 13 1975 fx6.s > -rw-rw-r-- 1 bin 293 May 13 1975 fx7.s > -rw-rw-r-- 1 bin 2774 May 13 1975 fx8.s > -rw-rw-r-- 1 bin 1365 May 13 1975 fx9.s > -rw-rw-r-- 1 bin 397 May 13 1975 fxa.s > -rw-rw-r-- 1 bin 366 May 13 1975 fxb.s > -rw-rw-r-- 1 bin 414 May 13 1975 fxc.s > -rw-rw-r-- 1 bin 555 May 13 1975 fxd.s > -rw-rw-r-- 1 bin 299 May 13 1975 fxe.s > -rw-rw-r-- 1 bin 287 May 13 1975 fxf.s > -rw-rw-r-- 1 bin 2869 May 13 1975 fxg.s > -rw-rw-r-- 1 bin 1101 May 13 1975 fxh.s > -rw-rw-r-- 1 bin 1510 May 13 1975 fxi.s > -rw-rw-r-- 1 bin 1282 May 13 1975 fxx.s > > usr/source/fort/io/. > total 31 > -rw-rw-r-- 1 bin 742 May 13 1975 io1.s > -rw-rw-r-- 1 bin 2753 May 13 1975 io2.s > -rw-rw-r-- 1 bin 3161 May 13 1975 io3.s > -rw-rw-r-- 1 bin 2276 May 13 1975 io4.s > -rw-rw-r-- 1 bin 961 May 13 1975 io5.s > -rw-rw-r-- 1 bin 2268 May 13 1975 io6.s > -rw-rw-r-- 1 bin 721 May 13 1975 io7.s > -rw-rw-r-- 1 bin 603 May 13 1975 iox.s > > usr/source/fort/rt/. > total 41 > -rw-rw-r-- 1 bin 557 May 13 1975 r0.s > -rw-rw-r-- 1 bin 1478 May 13 1975 r1.s > -rw-rw-r-- 1 bin 1305 May 13 1975 r2.s > -rw-rw-r-- 1 bin 437 May 13 1975 r3.s > -rw-rw-r-- 1 bin 641 May 13 1975 r4.s > -rw-rw-r-- 1 bin 491 May 13 1975 r5.s > -rw-rw-r-- 1 bin 1107 May 13 1975 r6.s > -rw-rw-r-- 1 bin 1368 May 13 1975 r7.s > -rw-rw-r-- 1 bin 339 May 13 1975 r8.s > -rw-rw-r-- 1 bin 617 May 13 1975 r9.s > -rw-rw-r-- 1 bin 417 May 13 1975 ra.s > -rw-rw-r-- 1 bin 579 May 13 1975 rb.s > -rw-rw-r-- 1 bin 2934 May 13 1975 rc.s > -rw-rw-r-- 1 bin 423 May 13 1975 rd.s > -rw-rw-r-- 1 bin 547 May 13 1975 re.s > -rw-rw-r-- 1 bin 531 May 13 1975 rf.s > -rw-rw-r-- 1 bin 959 May 13 1975 rg.s > -rw-rw-r-- 1 bin 1428 May 13 1975 rh.s > -rw-rw-r-- 1 bin 106 May 13 1975 rx.s > > usr/source/fort/rt1/. > total 46 > -rw-rw-r-- 1 bin 245 May 13 1975 abs.s > -rw-rw-r-- 1 bin 223 May 13 1975 aimag.s > -rw-rw-r-- 1 bin 211 May 13 1975 aint.s > -rw-rw-r-- 1 bin 307 May 13 1975 alog.s > -rw-rw-r-- 1 bin 360 May 13 1975 alog10.s > -rw-rw-r-- 1 bin 450 May 13 1975 amax0.s > -rw-rw-r-- 1 bin 542 May 13 1975 amax1.s > -rw-rw-r-- 1 bin 450 May 13 1975 amin0.s > -rw-rw-r-- 1 bin 510 May 13 1975 amin1.s > -rw-rw-r-- 1 bin 384 May 13 1975 amod.s > -rw-rw-r-- 1 bin 267 May 13 1975 atan.s > -rw-rw-r-- 1 bin 345 May 13 1975 atan2.s > -rw-rw-r-- 1 bin 595 May 13 1975 cabs.s > -rw-rw-r-- 1 bin 205 May 13 1975 ccos.f > -rw-rw-r-- 1 bin 405 May 13 1975 cexp.s > -rw-rw-r-- 1 bin 182 May 13 1975 clog.f > -rw-rw-r-- 1 bin 361 May 13 1975 cmplx.s > -rw-rw-r-- 1 bin 251 May 13 1975 conjg.s > -rw-rw-r-- 1 bin 259 May 13 1975 cos.s > -rw-rw-r-- 1 bin 205 May 13 1975 csin.f > -rw-rw-r-- 1 bin 217 May 13 1975 csqrt.f > -rw-rw-r-- 1 bin 224 May 13 1975 dble.s > -rw-rw-r-- 1 bin 243 May 13 1975 dccos.f > -rw-rw-r-- 1 bin 214 May 13 1975 dclog.f > -rw-rw-r-- 1 bin 243 May 13 1975 dcsin.f > -rw-rw-r-- 1 bin 250 May 13 1975 dcsqrt.f > -rw-rw-r-- 1 bin 280 May 13 1975 dim.s > -rw-rw-r-- 1 bin 225 May 13 1975 dimag.s > -rw-rw-r-- 1 bin 306 May 13 1975 exp.s > -rw-rw-r-- 1 bin 227 May 13 1975 float.s > -rw-rw-r-- 1 bin 201 May 13 1975 iabs.s > -rw-rw-r-- 1 bin 303 May 13 1975 idim.s > -rw-rw-r-- 1 bin 194 May 13 1975 idint.s > -rw-rw-r-- 1 bin 785 May 13 1975 ierr.s > -rw-rw-r-- 1 bin 249 May 13 1975 ifix.s > -rw-rw-r-- 1 bin 304 May 13 1975 isign.s > -rw-rw-r-- 1 bin 337 May 13 1975 mod.s > -rw-rw-r-- 1 bin 241 May 13 1975 real.s > -rw-rw-r-- 1 bin 347 May 13 1975 sign.s > -rw-rw-r-- 1 bin 259 May 13 1975 sin.s > -rw-rw-r-- 1 bin 224 May 13 1975 sngl.s > -rw-rw-r-- 1 bin 308 May 13 1975 sqrt.s > -rw-rw-r-- 1 bin 75 May 13 1975 tanh.f > > usr/source/fort/rt2/. > total 19 > -rw-rw-r-- 1 bin 196 May 13 1975 ctime.s > -rw-rw-r-- 1 bin 917 May 13 1975 getarg.s > -rw-rw-r-- 1 bin 219 May 13 1975 nice.s > -rw-rw-r-- 1 bin 647 May 13 1975 openrw.s > -rw-rw-r-- 1 bin 1772 May 13 1975 plot.s > -rw-rw-r-- 1 bin 467 May 13 1975 rand.s > -rw-rw-r-- 1 bin 664 May 13 1975 rio.s > -rw-rw-r-- 1 bin 405 May 13 1975 setfil.s > -rw-rw-r-- 1 bin 2222 May 14 1975 uio.s > > usr/source/iolib/. > total 65 > -rw-rw-r-- 1 bin 1148 May 13 1975 alloc.c > -rw-rw-r-- 1 bin 37 May 13 1975 calloc.c > -rw-rw-r-- 1 bin 508 May 13 1975 cclose.c > -rw-rw-r-- 1 bin 314 May 13 1975 ceof.c > -rw-rw-r-- 1 bin 166 May 13 1975 cerror.c > -rw-rw-r-- 1 bin 136 May 13 1975 cexit.c > -rw-rw-r-- 1 bin 341 May 13 1975 cflush.c > -rw-rw-r-- 1 bin 27 May 13 1975 cfree.c > -rw-rw-r-- 1 bin 692 May 13 1975 cgetc.c > -rw-rw-r-- 1 bin 118 May 13 1975 ciodec.c > -rw-rw-r-- 1 bin 102 May 13 1975 clenf.c > -rw-rw-r-- 1 bin 446 May 13 1975 copen.c > -rw-rw-r-- 1 bin 601 May 13 1975 cputc.c > -rw-rw-r-- 1 bin 359 May 13 1975 cwrd.c > -rw-rw-r-- 1 bin 60 May 13 1975 dummy.s > -rw-rw-r-- 1 bin 1766 May 13 1975 ftoa.c > -rw-rw-r-- 1 bin 47 May 13 1975 getch.c > -rw-rw-r-- 1 bin 251 May 13 1975 gets.c > -rw-rw-r-- 1 bin 34 May 13 1975 getvec.c > -rw-rw-r-- 1 bin 111 May 13 1975 iehzap.c > -rw-rw-r-- 1 bin 735 May 13 1975 makbuf.c > -rw-rw-r-- 1 bin 385 May 13 1975 maktab.c > -rw-rw-r-- 1 bin 200 May 13 1975 nexch.c > -rw-rw-r-- 1 bin 154 May 13 1975 nodig.c > -rw-rw-r-- 1 bin 2276 May 13 1975 printf.c > -rw-rw-r-- 1 bin 52 May 13 1975 putch.c > -rw-rw-r-- 1 bin 190 May 13 1975 puts.c > -rw-rw-r-- 1 bin 28 May 13 1975 relvec.c > -rw-rw-r-- 1 bin 210 May 13 1975 revput.c > -rw-rw-r-- 1 bin 696 May 16 1975 run > -rw-rw-r-- 1 bin 2951 May 13 1975 scan1.c > -rw-rw-r-- 1 bin 1675 May 13 1975 scan2.c > -rw-rw-r-- 1 bin 1035 May 13 1975 scan3.c > -rw-rw-r-- 1 bin 119 May 13 1975 system.c > -rw-rw-r-- 1 bin 98 May 13 1975 tmpnam.c > -rw-rw-r-- 1 bin 299 May 13 1975 unget.c > -rw-rw-r-- 1 bin 2173 May 13 1975 unprnt.s > -rw-rw-r-- 1 bin 187 May 13 1975 wdleng.c > > usr/source/m6/. > total 26 > -rw-rw-r-- 1 bin 1753 May 13 1975 m6.h > -rw-rw-r-- 1 bin 426 May 13 1975 m61.c > -rw-rw-r-- 1 bin 1432 May 13 1975 m62.c > -rw-rw-r-- 1 bin 1188 May 13 1975 m63.c > -rw-rw-r-- 1 bin 1167 May 13 1975 m64.c > -rw-rw-r-- 1 bin 1130 May 13 1975 m65.c > -rw-rw-r-- 1 bin 2436 May 13 1975 m66.c > -rw-rw-r-- 1 bin 1351 May 13 1975 m67.c > -rw-rw-r-- 1 bin 50 May 13 1975 run > > usr/source/mdec/. > total 67 > -rw-rw-r-- 1 bin 740 Jun 26 1975 dldr.s > -rw-rw-r-- 1 bin 3794 Jun 26 1975 dtf.s > -rw-rw-r-- 1 bin 2294 Jun 26 1975 fsboot.s > -rw-rw-r-- 1 bin 485 Jun 26 1975 hp.s > -rw-rw-r-- 1 bin 680 Jun 26 1975 ht.s > -rw-rw-r-- 1 bin 645 Jun 26 1975 mak > -rw-rw-r-- 1 bin 2646 Jun 26 1975 mboot.s > -rw-rw-r-- 1 bin 634 Jun 26 1975 mcopy.s > -rw-rw-r-- 1 bin 19 Jun 26 1975 reset.s > -rw-rw-r-- 1 bin 28 Jun 26 1975 rhp.s > -rw-rw-r-- 1 bin 194 Jun 26 1975 rk.s > -rw-rw-r-- 1 bin 437 Jun 26 1975 rkf.s > -rw-rw-r-- 1 bin 249 Jun 26 1975 rp.s > -rw-rw-r-- 1 bin 27 Jun 26 1975 rrk.s > -rw-rw-r-- 1 bin 27 Jun 26 1975 rrp.s > -rw-rw-r-- 1 bin 1027 Jun 26 1975 run > -rw-rw-r-- 1 bin 2646 Jun 26 1975 tboot.s > -rw-rw-r-- 1 bin 451 Jun 26 1975 tc.s > -rw-rw-r-- 1 bin 3764 Jun 26 1975 tcf.s > -rw-rw-r-- 1 bin 532 Jun 26 1975 tm.s > -rw-rw-r-- 1 bin 1016 Jun 26 1975 tpboot.s > -rw-rw-r-- 1 bin 738 Jun 26 1975 tty.s > -rw-rw-r-- 1 bin 2447 Jun 26 1975 uboot.s > -rw-rw-r-- 1 bin 29 Jun 26 1975 whp.s > -rw-rw-r-- 1 bin 28 Jun 26 1975 wrk.s > -rw-rw-r-- 1 bin 28 Jun 26 1975 wrp.s > > usr/source/rat/. > total 30 > -rw-rw-r-- 1 bin 5164 May 13 1975 lex.c > -rw-rw-r-- 1 bin 864 May 13 1975 r.g > -rw-rw-r-- 1 bin 132 May 13 1975 r.h > -rw-rw-r-- 1 bin 4476 May 13 1975 r1.c > -rw-rw-r-- 1 bin 1612 May 13 1975 r2.c > -rw-rw-r-- 1 bin 89 May 14 1975 run > > usr/source/s1/. > total 746 > -rw-rw-r-- 1 bin 4159 May 13 1975 ac.c > -rw-rw-r-- 1 bin 5782 May 13 1975 ar.s > -rw-rw-r-- 1 bin 2995 May 14 1975 banner.c > -rw-rw-r-- 1 bin 23474 May 13 1975 bas.s > -rw-rw-r-- 1 bin 11348 May 14 1975 bc.y > -rw-rw-r-- 1 bin 1773 May 13 1975 bcd.c > -rw-rw-r-- 1 bin 2606 May 13 1975 cal.c > -rw-rw-r-- 1 bin 647 May 13 1975 cat.s > -rw-rw-r-- 1 bin 12902 May 17 1975 cc.c > -rw-rw-r-- 1 bin 14561 May 13 1975 cdb1.c > -rw-rw-r-- 1 bin 6854 May 13 1975 cdb2.c > -rw-rw-r-- 1 bin 1169 May 13 1975 chgrp.s > -rw-rw-r-- 1 bin 381 May 13 1975 chmod.c > -rw-rw-r-- 1 bin 1161 May 13 1975 chown.s > -rw-rw-r-- 1 bin 737 May 13 1975 clri.s > -rw-rw-r-- 1 bin 1287 May 13 1975 cmp.c > -rw-rw-r-- 1 bin 1862 Jun 22 1975 col.c > -rw-rw-r-- 1 bin 2122 May 13 1975 comm.c > -rw-rw-r-- 1 bin 1063 May 13 1975 cp.c > -rw-rw-r-- 1 bin 364 May 13 1975 cpall.c > -rw-rw-r-- 1 bin 3202 May 13 1975 cron.c > -rw-rw-r-- 1 bin 3020 May 13 1975 crypt.c > -rw-rw-r-- 1 bin 2203 May 13 1975 date.c > -rw-rw-r-- 1 bin 8758 May 13 1975 db1.s > -rw-rw-r-- 1 bin 3595 May 13 1975 db2.s > -rw-rw-r-- 1 bin 6575 May 13 1975 db3.s > -rw-rw-r-- 1 bin 647 May 13 1975 db4.s > -rw-rw-r-- 1 bin 29076 May 13 1975 dc1.s > -rw-rw-r-- 1 bin 6009 May 13 1975 dc2.s > -rw-rw-r-- 1 bin 5885 May 13 1975 dc3.s > -rw-rw-r-- 1 bin 5396 May 13 1975 dc4.s > -rw-rw-r-- 1 bin 7432 May 13 1975 dc5.s > -rw-rw-r-- 1 bin 3332 May 13 1975 dcheck.c > -rw-rw-r-- 1 bin 7702 May 13 1975 dd.c > -rw-rw-r-- 1 bin 1282 May 13 1975 df.c > -rw-rw-r-- 1 bin 9373 May 13 1975 diff1.c > -rw-rw-r-- 1 bin 736 May 13 1975 diff2.s > -rw-rw-r-- 1 bin 1037 May 13 1975 dsw.s > -rw-rw-r-- 1 bin 2113 May 13 1975 du.s > -rw-rw-r-- 1 bin 6751 May 13 1975 dump.c > -rw-rw-r-- 1 bin 134 May 13 1975 echo.c > -rw-rw-r-- 1 bin 17889 May 13 1975 ed.c > -rw-rw-r-- 1 bin 53 May 13 1975 exit.c > -rw-rw-r-- 1 bin 6864 May 13 1975 fc.c > -rw-rw-r-- 1 bin 1201 May 13 1975 fed1.s > -rw-rw-r-- 1 bin 5766 May 13 1975 fed2.s > -rw-rw-r-- 1 bin 4192 May 13 1975 fed3.s > -rw-rw-r-- 1 bin 4181 May 13 1975 file.c > -rw-rw-r-- 1 bin 9159 May 13 1975 find.c > -rw-rw-r-- 1 bin 2116 May 13 1975 form1.s > -rw-rw-r-- 1 bin 1019 May 13 1975 form2.s > -rw-rw-r-- 1 bin 1685 May 13 1975 form3.s > -rw-rw-r-- 1 bin 2820 May 13 1975 form4.s > -rw-rw-r-- 1 bin 9729 May 13 1975 form5.s > -rw-rw-r-- 1 bin 6478 May 13 1975 form6.s > -rw-rw-r-- 1 bin 3291 May 13 1975 getty.c > -rw-rw-r-- 1 bin 3698 May 13 1975 glob.c > -rw-rw-r-- 1 bin 844 May 13 1975 goto.c > -rw-rw-r-- 1 bin 4618 May 13 1975 grep.c > -rw-rw-r-- 1 bin 3951 May 13 1975 gsi.c > -rw-rw-r-- 1 bin 5050 May 13 1975 icheck.c > -rw-rw-r-- 1 bin 1971 May 13 1975 if.c > -rw-rw-r-- 1 bin 3058 May 13 1975 init.c > -rw-rw-r-- 1 bin 730 May 13 1975 kill.s > -rw-rw-r-- 1 bin 15577 May 13 1975 ld.c > -rw-rw-r-- 1 bin 686 May 13 1975 ln.c > -rw-rw-r-- 1 bin 3017 May 13 1975 login.c > -rw-rw-r-- 1 bin 2421 May 13 1975 lpd.s > -rw-rw-r-- 1 bin 3366 May 13 1975 lpr.c > -rw-rw-r-- 1 bin 7663 May 13 1975 ls.c > -rw-rw-r-- 1 bin 2231 Jun 22 1975 run > > usr/source/s2/. > total 393 > -rw-rw-r-- 1 bin 4155 May 13 1975 mail.c > -rw-rw-r-- 1 bin 662 May 13 1975 mesg.c > -rw-rw-r-- 1 bin 1088 May 13 1975 mkdir.s > -rw-rw-r-- 1 bin 7581 May 13 1975 mkfs.c > -rw-rw-r-- 1 bin 563 May 13 1975 mknod.c > -rw-rw-r-- 1 bin 1155 May 13 1975 mount.c > -rw-rw-r-- 1 bin 2996 May 13 1975 mv.c > -rw-rw-r-- 1 bin 4398 May 13 1975 ncheck.c > -rw-rw-r-- 1 bin 2123 May 13 1975 newgrp.c > -rw-rw-r-- 1 bin 640 May 13 1975 nice.c > -rw-rw-r-- 1 bin 2100 May 13 1975 nm.c > -rw-rw-r-- 1 bin 530 May 13 1975 nohup.c > -rw-rw-r-- 1 bin 7157 May 13 1975 od.c > -rw-rw-r-- 1 bin 464 May 13 1975 opr.c > -rw-rw-r-- 1 bin 2295 May 13 1975 passwd.c > -rw-rw-r-- 1 bin 492 May 13 1975 pfe.s > -rw-rw-r-- 1 bin 5895 May 13 1975 pr.c > -rw-rw-r-- 1 bin 5486 May 13 1975 prof.c > -rw-rw-r-- 1 bin 4570 May 13 1975 ps.c > -rw-rw-r-- 1 bin 3260 May 13 1975 ptx.c > -rw-rw-r-- 1 bin 1199 May 13 1975 pwd.c > -rw-rw-r-- 1 bin 6062 May 13 1975 quiz.c > -rw-rw-r-- 1 bin 5969 May 13 1975 rc.c > -rw-rw-r-- 1 bin 7810 May 13 1975 restor.c > -rw-rw-r-- 1 bin 451 May 13 1975 rew.s > -rw-rw-r-- 1 bin 1483 May 13 1975 rm.c > -rw-rw-r-- 1 bin 1197 May 13 1975 rmdir.s > -rw-rw-r-- 1 bin 2153 May 14 1975 run > -rw-rw-r-- 1 bin 6921 May 13 1975 sa.c > -rw-rw-r-- 1 bin 11645 May 13 1975 sh.c > -rw-rw-r-- 1 bin 580 May 13 1975 size.c > -rw-rw-r-- 1 bin 255 May 13 1975 sleep.c > -rw-rw-r-- 1 bin 8973 May 13 1975 sort.c > -rw-rw-r-- 1 bin 1242 May 13 1975 split.c > -rw-rw-r-- 1 bin 1725 May 13 1975 strip.s > -rw-rw-r-- 1 bin 3678 May 13 1975 stty.c > -rw-rw-r-- 1 bin 741 May 13 1975 su.c > -rw-rw-r-- 1 bin 836 May 13 1975 sum.s > -rw-rw-r-- 1 bin 21 May 13 1975 sync.c > -rw-rw-r-- 1 bin 6282 May 13 1975 tbl.c > -rw-rw-r-- 1 bin 696 May 13 1975 tee.c > -rw-rw-r-- 1 bin 2342 May 13 1975 time.s > -rw-rw-r-- 1 bin 2763 May 13 1975 tp1.s > -rw-rw-r-- 1 bin 4828 May 13 1975 tp2.s > -rw-rw-r-- 1 bin 5844 May 13 1975 tp3.s > -rw-rw-r-- 1 bin 603 May 13 1975 tp4.s > -rw-rw-r-- 1 bin 2395 May 13 1975 tr.c > -rw-rw-r-- 1 bin 151 May 13 1975 tty.s > -rw-rw-r-- 1 bin 6533 May 13 1975 typo.c > -rw-rw-r-- 1 bin 940 May 13 1975 umount.c > -rw-rw-r-- 1 bin 1955 May 13 1975 uniq.c > -rw-rw-r-- 1 bin 6075 May 13 1975 units.c > -rw-rw-r-- 1 bin 161 May 13 1975 update.s > -rw-rw-r-- 1 bin 8936 May 13 1975 usort.c > -rw-rw-r-- 1 bin 949 May 13 1975 wall.c > -rw-rw-r-- 1 bin 1229 May 13 1975 wc.c > -rw-rw-r-- 1 bin 954 May 13 1975 who.c > -rw-rw-r-- 1 bin 2174 May 13 1975 write.s > > usr/source/s3/. > total 82 > -rw-rw-r-- 1 bin 2587 May 13 1975 atan.s > -rw-rw-r-- 1 bin 2082 May 13 1975 crypt.s > -rw-rw-r-- 1 bin 211 May 13 1975 dpadd.s > -rw-rw-r-- 1 bin 1958 May 13 1975 ecvt.s > -rw-rw-r-- 1 bin 1917 May 13 1975 exp.s > -rw-rw-r-- 1 bin 134 May 13 1975 fakfp.s > -rw-rw-r-- 1 bin 385 May 13 1975 floor.s > -rw-rw-r-- 1 bin 265 May 13 1975 fmod.s > -rw-rw-r-- 1 bin 4506 May 13 1975 fp1.s > -rw-rw-r-- 1 bin 1945 May 13 1975 fp2.s > -rw-rw-r-- 1 bin 3385 May 13 1975 fp3.s > -rw-rw-r-- 1 bin 332 May 13 1975 fpx.s > -rw-rw-r-- 1 bin 4230 May 13 1975 gamma.s > -rw-rw-r-- 1 bin 1267 May 13 1975 get.s > -rw-rw-r-- 1 bin 233 May 13 1975 ldiv.s > -rw-rw-r-- 1 bin 1802 May 13 1975 log.s > -rw-rw-r-- 1 bin 318 May 13 1975 mesg.s > -rw-rw-r-- 1 bin 552 May 13 1975 pow.s > -rw-rw-r-- 1 bin 1246 May 13 1975 put.s > -rw-rw-r-- 1 bin 290 May 13 1975 rand.s > -rw-rw-r-- 1 bin 618 May 14 1975 run > -rw-rw-r-- 1 bin 84 May 13 1975 savr5.s > -rw-rw-r-- 1 bin 2012 May 13 1975 sin.s > -rw-rw-r-- 1 bin 719 May 13 1975 sqrt.s > -rw-rw-r-- 1 bin 508 May 13 1975 switch.s > -rw-rw-r-- 1 bin 583 May 13 1975 ttyn.s > > usr/source/s4/. > total 63 > -rw-rw-r-- 1 bin 105 May 13 1975 abort.s > -rw-rw-r-- 1 bin 165 May 13 1975 abs.s > -rw-rw-r-- 1 bin 2464 May 13 1975 alloc.s > -rw-rw-r-- 1 bin 1232 May 13 1975 atof.s > -rw-rw-r-- 1 bin 268 May 13 1975 atoi.c > -rw-rw-r-- 1 bin 151 May 13 1975 cerror.s > -rw-rw-r-- 1 bin 208 May 13 1975 chdir.s > -rw-rw-r-- 1 bin 234 May 13 1975 chmod.s > -rw-rw-r-- 1 bin 235 May 13 1975 chown.s > -rw-rw-r-- 1 bin 181 May 13 1975 close.s > -rw-rw-r-- 1 bin 249 May 13 1975 creat.s > -rw-rw-r-- 1 bin 200 May 13 1975 crt0.s > -rw-rw-r-- 1 bin 255 May 13 1975 csv.s > -rw-rw-r-- 1 bin 4367 May 13 1975 ctime.c > -rw-rw-r-- 1 bin 186 May 13 1975 dup.s > -rw-rw-r-- 1 bin 772 May 13 1975 errlst.c > -rw-rw-r-- 1 bin 218 May 13 1975 execl.s > -rw-rw-r-- 1 bin 531 May 13 1975 execv.s > -rw-rw-r-- 1 bin 139 May 13 1975 exit.s > -rw-rw-r-- 1 bin 271 May 13 1975 fcrt0.s > -rw-rw-r-- 1 bin 116 May 13 1975 ffltpr.s > -rw-rw-r-- 1 bin 924 May 13 1975 fltpr.s > -rw-rw-r-- 1 bin 321 May 13 1975 fork.s > -rw-rw-r-- 1 bin 287 May 13 1975 fstat.s > -rw-rw-r-- 1 bin 957 May 13 1975 getc.s > -rw-rw-r-- 1 bin 395 May 13 1975 getchr.s > -rw-rw-r-- 1 bin 122 May 13 1975 getcsw.s > -rw-rw-r-- 1 bin 141 May 13 1975 getgid.s > -rw-rw-r-- 1 bin 127 May 13 1975 getpid.s > -rw-rw-r-- 1 bin 605 May 13 1975 getpw.c > -rw-rw-r-- 1 bin 128 May 13 1975 getuid.s > -rw-rw-r-- 1 bin 304 May 13 1975 gtty.s > -rw-rw-r-- 1 bin 57 May 13 1975 hmul.s > -rw-rw-r-- 1 bin 218 May 13 1975 kill.s > -rw-rw-r-- 1 bin 480 May 13 1975 ladd.s > -rw-rw-r-- 1 bin 121 May 13 1975 ldfps.s > -rw-rw-r-- 1 bin 237 May 13 1975 link.s > -rw-rw-r-- 1 bin 559 May 13 1975 locv.s > -rw-rw-r-- 1 bin 332 May 13 1975 ltod.s > -rw-rw-r-- 1 bin 1040 May 16 1975 run > > usr/source/s5/. > total 59 > -rw-rw-r-- 1 bin 213 May 13 1975 makdir.s > -rw-rw-r-- 1 bin 222 May 13 1975 mcount.s > -rw-rw-r-- 1 bin 770 May 13 1975 mcrt0.s > -rw-rw-r-- 1 bin 222 May 13 1975 mdate.s > -rw-rw-r-- 1 bin 279 May 13 1975 mknod.s > -rw-rw-r-- 1 bin 579 May 13 1975 mon.c > -rw-rw-r-- 1 bin 256 May 13 1975 mount.s > -rw-rw-r-- 1 bin 780 May 13 1975 nargs.s > -rw-rw-r-- 1 bin 176 May 13 1975 nice.s > -rw-rw-r-- 1 bin 1146 May 13 1975 nlist.s > -rw-rw-r-- 1 bin 246 May 13 1975 open.s > -rw-rw-r-- 1 bin 487 May 13 1975 perror.c > -rw-rw-r-- 1 bin 214 May 13 1975 pipe.s > -rw-rw-r-- 1 bin 2298 May 13 1975 printf.s > -rw-rw-r-- 1 bin 192 May 13 1975 prof.s > -rw-rw-r-- 1 bin 332 May 13 1975 ptrace.s > -rw-rw-r-- 1 bin 1037 May 13 1975 putc.s > -rw-rw-r-- 1 bin 585 May 13 1975 putchr.s > -rw-rw-r-- 1 bin 1324 May 13 1975 qsort.c > -rw-rw-r-- 1 bin 291 May 13 1975 read.s > -rw-rw-r-- 1 bin 423 May 13 1975 reset.s > -rw-rw-r-- 1 bin 335 May 13 1975 rin.c > -rw-rw-r-- 1 bin 1059 May 16 1975 run > -rw-rw-r-- 1 bin 531 May 13 1975 sbrk.s > -rw-rw-r-- 1 bin 248 May 13 1975 seek.s > -rw-rw-r-- 1 bin 197 May 13 1975 setgid.s > -rw-rw-r-- 1 bin 184 May 13 1975 setuid.s > -rw-rw-r-- 1 bin 1990 May 13 1975 signal.s > -rw-rw-r-- 1 bin 107 May 13 1975 sleep.s > -rw-rw-r-- 1 bin 290 May 13 1975 stat.s > -rw-rw-r-- 1 bin 161 May 13 1975 stime.s > -rw-rw-r-- 1 bin 304 May 13 1975 stty.s > -rw-rw-r-- 1 bin 89 May 13 1975 sync.s > -rw-rw-r-- 1 bin 229 May 13 1975 time.s > -rw-rw-r-- 1 bin 155 May 13 1975 times.s > -rw-rw-r-- 1 bin 223 May 13 1975 umount.s > -rw-rw-r-- 1 bin 215 May 13 1975 unlink.s > -rw-rw-r-- 1 bin 347 May 13 1975 wait.s > -rw-rw-r-- 1 bin 281 May 13 1975 write.s > > usr/source/s7/. > total 275 > -rw-rw-r-- 1 bin 3476 May 13 1975 ne.g > -rw-rw-r-- 1 bin 614 May 13 1975 ne.h > -rw-rw-r-- 1 bin 4856 May 13 1975 ne1.c > -rw-rw-r-- 1 bin 3125 May 13 1975 ne2.c > -rw-rw-r-- 1 bin 2312 May 13 1975 ne3.c > -rw-rw-r-- 1 bin 3539 May 13 1975 ne4.c > -rw-rw-r-- 1 bin 595 May 13 1975 ne5.c > -rw-rw-r-- 1 bin 1412 May 13 1975 ne6.c > -rw-rw-r-- 1 bin 5039 May 13 1975 nelex.c > -rw-rw-r-- 1 bin 14884 May 13 1975 nroff1.s > -rw-rw-r-- 1 bin 12516 May 13 1975 nroff2.s > -rw-rw-r-- 1 bin 12693 May 13 1975 nroff3.s > -rw-rw-r-- 1 bin 9504 May 13 1975 nroff4.s > -rw-rw-r-- 1 bin 4520 May 13 1975 nroff5.s > -rw-rw-r-- 1 bin 3071 May 13 1975 nroff8.s > -rw-rw-r-- 1 bin 6518 May 13 1975 roff1.s > -rw-rw-r-- 1 bin 3990 May 13 1975 roff2.s > -rw-rw-r-- 1 bin 4813 May 13 1975 roff3.s > -rw-rw-r-- 1 bin 5149 May 13 1975 roff4.s > -rw-rw-r-- 1 bin 3036 May 13 1975 roff5.s > -rw-rw-r-- 1 bin 6207 May 13 1975 roff7.s > -rw-rw-r-- 1 bin 1447 May 13 1975 roff8.s > -rw-rw-r-- 1 bin 254 May 13 1975 run > -rw-rw-r-- 1 bin 15373 May 13 1975 suftab.s > > usr/source/salloc/. > total 36 > -rw-rw-r-- 1 bin 2406 May 13 1975 alloc1.s > -rw-rw-r-- 1 bin 3289 May 13 1975 alloc2.s > -rw-rw-r-- 1 bin 6056 May 13 1975 alloc3.s > -rw-rw-r-- 1 bin 936 May 13 1975 altch.s > -rw-rw-r-- 1 bin 291 May 13 1975 bsp.s > -rw-rw-r-- 1 bin 370 May 13 1975 bword.s > -rw-rw-r-- 1 bin 300 May 13 1975 getch.s > -rw-rw-r-- 1 bin 747 May 13 1975 getwd.s > -rw-rw-r-- 1 bin 329 May 13 1975 length.s > -rw-rw-r-- 1 bin 468 May 13 1975 rewind.s > -rw-rw-r-- 1 bin 288 May 13 1975 run > -rw-rw-r-- 1 bin 245 May 13 1975 zero.s > > usr/source/sno/. > total 51 > -rw-rw-r-- 1 bin 52 May 13 1975 run > -rw-rw-r-- 1 bin 338 May 13 1975 sno.h > -rw-rw-r-- 1 bin 6305 May 13 1975 sno1.c > -rw-rw-r-- 1 bin 7723 May 13 1975 sno2.c > -rw-rw-r-- 1 bin 3644 May 13 1975 sno3.c > -rw-rw-r-- 1 bin 4176 May 13 1975 sno4.c > > usr/source/tmg/. > total 72 > -rw-rw-r-- 1 bin 1321 May 14 1975 run > -rw-rw-r-- 1 bin 7577 May 13 1975 tmga.s > drwxrwxr-x 2 bin 1280 May 27 1975 tmgb > -rw-rw-r-- 1 bin 1989 May 13 1975 tmgc.s > -rw-rw-r-- 1 bin 14863 May 13 1975 tmgl.s > -rw-rw-r-- 1 bin 6751 May 13 1975 tmgl.t > > usr/source/tmg/tmgb/. > total 47 > -rw-rw-r-- 1 bin 178 May 13 1975 any.s > -rw-rw-r-- 1 bin 165 May 13 1975 append.s > -rw-rw-r-- 1 bin 787 May 13 1975 arith.s > -rw-rw-r-- 1 bin 246 May 13 1975 bundle.s > -rw-rw-r-- 1 bin 183 May 13 1975 char.s > -rw-rw-r-- 1 bin 446 May 13 1975 copy.s > -rw-rw-r-- 1 bin 1116 May 13 1975 cstr.s > -rw-rw-r-- 1 bin 237 May 13 1975 ctest.s > -rw-rw-r-- 1 bin 208 May 13 1975 decmal.s > -rw-rw-r-- 1 bin 109 May 13 1975 discd.s > -rw-rw-r-- 1 bin 592 May 13 1975 emit.s > -rw-rw-r-- 1 bin 60 May 13 1975 end.s > -rw-rw-r-- 1 bin 163 May 13 1975 f.s > -rw-rw-r-- 1 bin 1328 May 13 1975 find.s > -rw-rw-r-- 1 bin 612 May 13 1975 getnam.s > -rw-rw-r-- 1 bin 94 May 13 1975 ignore.s > -rw-rw-r-- 1 bin 238 May 13 1975 inc.s > -rw-rw-r-- 1 bin 300 May 13 1975 infix.s > -rw-rw-r-- 1 bin 470 May 13 1975 jget.s > -rw-rw-r-- 1 bin 124 May 13 1975 lvrv.s > -rw-rw-r-- 1 bin 249 May 13 1975 mult.s > -rw-rw-r-- 1 bin 204 May 13 1975 octal.s > -rw-rw-r-- 1 bin 142 May 13 1975 params.s > -rw-rw-r-- 1 bin 329 May 13 1975 push.s > -rw-rw-r-- 1 bin 260 May 13 1975 putcal.s > -rw-rw-r-- 1 bin 309 May 13 1975 putdec.s > -rw-rw-r-- 1 bin 184 May 13 1975 putoct.s > -rw-rw-r-- 1 bin 393 May 13 1975 px.s > -rw-rw-r-- 1 bin 431 May 13 1975 reln.s > -rw-rw-r-- 1 bin 120 May 13 1975 shift.s > -rw-rw-r-- 1 bin 1082 May 13 1975 stack.s > -rw-rw-r-- 1 bin 194 May 13 1975 string.s > -rw-rw-r-- 1 bin 231 May 13 1975 table.s > -rw-rw-r-- 1 bin 353 May 13 1975 tq.s > -rw-rw-r-- 1 bin 156 May 13 1975 trace.s > -rw-rw-r-- 1 bin 81 May 13 1975 trans.s > -rw-rw-r-- 1 bin 137 May 13 1975 tx.s > -rw-rw-r-- 1 bin 168 May 13 1975 unary.s > > usr/source/yacc/. > total 3 > drwxrwxr-x 2 bin 208 May 27 1975 lib > -rw-rw-r-- 1 bin 118 May 13 1975 run > drwxrwxr-x 2 bin 272 May 27 1975 source > > usr/source/yacc/lib/. > total 11 > -rw-rw-r-- 1 bin 112 May 13 1975 main.c > -rw-rw-r-- 1 bin 3284 May 13 1975 parser.c > -rw-rw-r-- 1 bin 12 May 13 1975 zacc.c > -rw-rw-r-- 1 bin 481 May 13 1975 zerr.c > -rw-rw-r-- 1 bin 11 May 13 1975 zinit.c > > usr/source/yacc/source/. > total 100 > -rw-rw-r-- 1 bin 4402 May 13 1975 dextern > -rw-rw-r-- 1 bin 3976 May 13 1975 y0.c > -rw-rw-r-- 1 bin 6597 May 13 1975 y1.c > -rw-rw-r-- 1 bin 12020 May 13 1975 y2.c > -rw-rw-r-- 1 bin 9654 May 13 1975 y3.c > -rw-rw-r-- 1 bin 9996 May 13 1975 y4.c > -rw-rw-r-- 1 bin 572 May 13 1975 y5.c > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Apr 7 11:59:57 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Apr 2020 19:59:57 -0600 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: <20200406225949.88C792BB520@yagi.h-net.msu.edu> References: <20200406221138.GA10092@minnie.tuhs.org> <20200406225949.88C792BB520@yagi.h-net.msu.edu> Message-ID: On Mon, Apr 6, 2020 at 5:00 PM Dennis Boone wrote: > The tape was made by a PDP-11 system running RT-11. This manual may > help a little: > > > http://bitsavers.org/pdf/dec/pdp11/rt11/v5.6_Aug91/AA-PD6PA-TC_RT-11_Volume_and_File_Formats_Manual_Aug91.pdf > > TL;DR - This tape was written by just copying disk files to it, so the > files which contain actual data are just images of the disk files. > > File 2 is a V6 image that's bootable like so %pdp11 sim> set cpu 11/45 sim> att rk0 2.tape sim> boot rk0 @rkunnix login: File 5 - this looks like a file system image. > It's the rest of the sources from the last disk. You can mount it like so if you add a 'att rk1 5.tape' to the above # mkdir /rk1 # /etc/mount /dev/rk1 /rk1 > File 8 - appears to be some sort of archiver output, but while the .ARC > extension might lead you to suspect the old CP/M - MSDOS ARC program was > responsible, that doesn't appear to be the case. > You'd think that from the name, but you can mount it also like the above. With the 'att rk2 8.tape' and 'att rk3 11.tape' # chdir /dev # /etc/mknod rk2 b 0 2 # /etc/mknod rk3 b 0 3 # mkdir /rk2 /rk3 # /etc/mount /dev/rk2 /rk2 # /etc/mount /deev/rk3 /rk3 > File 11 - this is an older format tarball. > Nah, somebody else used the disk before for TAR, and then this was overwritten with a unix filesystem. What's weird is that this is a VENIX system, which should be V7 which should have a different filesystem layout from V6. I'd think I wouldn't be able to see some directories. I'll have to create a V7 system and mount it there... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Apr 7 12:03:01 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Apr 2020 12:03:01 +1000 (EST) Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: References: <20200406221138.GA10092@minnie.tuhs.org> <20200406234758.GA27062@minnie.tuhs.org> Message-ID: On Mon, 6 Apr 2020, Clem Cole wrote: > He used RT-11 to copy each disk pack sequentially.   That's an ANSI VOL1 > record.   Sadly it's not a full ANSI tape (long story -- it needs HDR1 > records  VMS would have been able to mount it as a foreign tape.    [ Probably getting COFF-ish now ] Blimey, but that takes me back to my OS/360 days... I once wrote a little utility (in assembly, of course) that dumped all the HDR/VOL/etc records. It was a swine to debug (overnight processing because I was a student); I had to leave instructions to the operator to "ABEND with core dump" if the tape merely oscillated back and forth (which it did early on). The first time, I got a snotty note from the operator saying that after watching the tape for half an hour he had to kill it; ah, the joys of overnight remote debugging... Later on I became a volunteer operator on the graveyard shift and was able to sneak in the occasional "foreign order". -- Dave From jsteve at superglobalmegacorp.com Tue Apr 7 12:40:02 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 7 Apr 2020 10:40:02 +0800 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: <20200406221138.GA10092@minnie.tuhs.org> References: <20200406221138.GA10092@minnie.tuhs.org> Message-ID: Strings tells me it’s from Venturcom “VENTURCOM INC. 1981, 1982” Maybe these guys? https://www.businesswire.com/news/home/20041111005095/en/VenturCom-Launches-Enhanced-RTX-Version-6.0 “IntervalZero’s experience and expertise in embedded technology extends back to 1980 with the founding of its predecessor company, VenturCom, which developed the technology that led to Microsoft’s first embedded operating system.” -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Apr 7 13:39:17 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Apr 2020 21:39:17 -0600 Subject: [TUHS] Software Archaeology Challenge? In-Reply-To: References: <20200406221138.GA10092@minnie.tuhs.org> Message-ID: On Mon, Apr 6, 2020 at 8:40 PM Jason Stevens wrote: > Strings tells me it’s from Venturcom > > > > “VENTURCOM INC. 1981, 1982” > > > > Maybe these guys? > > > > > https://www.businesswire.com/news/home/20041111005095/en/VenturCom-Launches-Enhanced-RTX-Version-6.0 > > > > “IntervalZero’s experience and expertise in embedded technology extends > back to 1980 with the founding of its predecessor company, VenturCom, which > developed the technology that led to Microsoft’s first embedded operating > system.” > This is either Venix 1.0 or 2.0. I've not decided. I think 1.0, but maybe 2.0. I'll know more after I look at it some more. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Tue Apr 7 20:42:51 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 7 Apr 2020 11:42:51 +0100 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> Message-ID: <20200407104251.GA89097@clarinet.employees.org> On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote: > > The manuals aren’t really a book (and again, they weren’t really published as a book) A bit later on but... I'm prettry sure I managed to read the man pages published as a book while at Uni, so between '86 and '90. I found it in the University Library. It was published by Western Electric, and had either a dark blue or black cover. It also didn't appear to be a particularly recent book, but could just have been well worn. Possibly about System III, I don't think it was about System V. However, there were books of System V man pages published, since I bought some of them. DF From jpl.jpl at gmail.com Wed Apr 8 04:10:08 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 7 Apr 2020 14:10:08 -0400 Subject: [TUHS] Manuals Message-ID: Andrew Hume (andrew at humeweb.com) has had trouble posting this, and asked me to try. Reply directly to Andrew, not to me. ============================ I have the following manuals available: 3 Eight Edition Unix manuals (2 shrink-wrapped, one not (but still good condition)) Unix programmers manual, Release 3.0 (Dolotta et al, 1980) Sixth Edition programmers manual (Bell Labs cardboard cover) Sixth Edition Documents manual (Bell Labs cardboard cover) Seventh Edition programmers manual Volume 2a, Jan 1979. (actually documents such as make, lint, troff etc) Documents for UNIX, Volume 2 (Dolotta et al, 1981) sections E and F (make, lex, security etc) All the above are in pretty good condition, given they are bound in cardboard covers and are 40ish years old. I’d prefer to give them to someone archival, but otherwise, first come, first served. Andrew Hume -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Apr 8 08:21:49 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Apr 2020 08:21:49 +1000 (EST) Subject: [TUHS] Manuals In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020, John P. Linderman wrote: > Andrew Hume (andrew at humeweb.com) has had trouble posting this, and asked > me to try. Reply directly to Andrew, not to me. Andrew Hume? He first came to UNSW when in his final school year (I think) and quickly outstripped his mentors. He damned near threw a keyboard into a screen because of Pascal's proclivity for reading ahead; doubleplus ungood on an interactive session... (And yes, I've seen that photo of him wearing a tee-shirt and shorts in the snow; that's typical of him) -- Dave From pnr at planet.nl Thu Apr 9 04:50:25 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 8 Apr 2020 20:50:25 +0200 Subject: [TUHS] 8th Edition timeline In-Reply-To: <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> Message-ID: <3FA2A5AF-F4E9-4AD8-9A06-6864DD855498@planet.nl> As was suggested on the list, I’ve reached out to Peter Weinberger to better understand the time line of the File System Switch and the 8th edition network file system. He has been very helpful, but the one line summary is that it is unfortunately too long ago to remember specific details with any certainty. In general Peter remembers that he was concerned that the project was too big for one person to do, and hence always looked for design choices that would leave the work scope manageable. Time line. Since my last post on this subject I have found that the ACM conference talk of March 1985 was also held 9 months earlier at a Usenix conference - leaving a time slot between end of 1981 and summer 1984. Peter vaguely remembers that the essential ideas were done "before 1983”. It would stand to reason that 1983 was spent on getting corner cases of the network file system right, but all this is no more than plausible conjecture. File system switch (FSS). The guiding thought for the FSS was to extend the philosophy of ‘everything is a file’ to new areas, also other than network files. Early implementations already included a simple, read-only ‘/proc’ file system for example. I asked if any experiments had been done with virtualising ‘/dev', but Peter could not recall any such work. I personally find that the FSS has an elegance that fits with other parts of Research Unix and asked Peter about its origins. He does not recall any special "a-ha” moments, but does recall that the way it was done just felt natural to him. Other options would have included to do the switch at the sys call level (which felt too complicated) or at the block device level (which felt too limited). I also asked about how his reworking of ’namei’ and centralising all namespace operations in that function came about (in my view it is key to a concise switch). Here, too, it is too long ago to remember any specifics, but Peter comments that he never liked to write much code and that spending time on finding ways to make the amount of coding as small and straightforward as possible would have been in character. Eighth edition network file system Once the FSS exists, a simplistic network file system is not hard - just do RPC to a remote server. Peter chose to do a user level file server in order to keep the work scope and complexity down to manageable levels. As highlighted in the ACM paper, the devil is in the detail of replicating all the semantics of normal local disk files. Cases like a file being kept alive if a process still has it open, the complexities of cross-mounted network files (let alone recursively mounted), handling failed connections, etc. were hard to sort out and get right. > On 29 Mar 2020, at 20:12, Paul Ruizendaal wrote: > > On 29 Mar 2020, at 16:04, arnold at skeeve.com wrote: >> >> Paul Ruizendaal wrote: >> >>> Related is the question when the "file system switch" was added. It must >>> have been later than 1981 and before 1985, but I have not been able to >>> pinpoint it further. >> >> IIRC there was a "paper" (only an abstract) on the file system >> switch published in a USENIX conference proceedings. That woud help >> trace it down. > > I have that paper (“The Unix 8th Edition Network File System”), it was presented at a March 1985 ACM conference. However, there are indications that the roots of the file system switch existed earlier, possibly much earlier. > > I think Doug McIlroy once described 1973 as a pivotal year for Unix, with many concepts devised that would blossom in the following 3-5 years. I’m increasingly tempted to think that Summer ’81 - Summer ’82 was a similarly pivotal year. > >> Peter Weinberger, who did it, is at Google; you could ask him >> directly, as well. > > That is a good idea. If someone has the email address I’d appreciate an off list message. > > Paul From thomas.paulsen at firemail.de Thu Apr 9 04:58:38 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 08 Apr 2020 20:58:38 +0200 Subject: [TUHS] 8th Edition timeline In-Reply-To: <3FA2A5AF-F4E9-4AD8-9A06-6864DD855498@planet.nl> References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> <3FA2A5AF-F4E9-4AD8-9A06-6864DD855498@planet.nl> Message-ID: >As was suggested on the list, I’ve reached out to Peter Weinberger to better >understand the time line of the File System Switch and the 8th edition network f>ile system. 'Introduced with System V Release 3.0, the File System Switch (FSS) architecture introduced a framework under which multiple different filesystem types could coexist in parallel.' https://www.oreilly.com/library/view/unix-filesystems-evolution/9780471456759/chap07-sec003.html From pnr at planet.nl Thu Apr 9 06:13:29 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 8 Apr 2020 22:13:29 +0200 Subject: [TUHS] 8th Edition timeline In-Reply-To: References: <20C3B8BE-E371-4694-8A34-EEC6A5461FAD@planet.nl> <202003291404.02TE4dAI022916@freefriends.org> <2298456D-A786-40C2-9C68-26C99E2002E1@planet.nl> <3FA2A5AF-F4E9-4AD8-9A06-6864DD855498@planet.nl> Message-ID: <0A39F8F1-C1C3-408F-9715-1D8B9C19A00C@planet.nl> On Apr 8, 2020, at 8:58 PM, Thomas Paulsen wrote: > >> As was suggested on the list, I’ve reached out to Peter Weinberger to better >> understand the time line of the File System Switch and the 8th edition network > f>ile system. > > 'Introduced with System V Release 3.0, the File System Switch (FSS) architecture introduced a framework under which multiple different filesystem types could coexist in parallel.' > https://www.oreilly.com/library/view/unix-filesystems-evolution/9780471456759/chap07-sec003.html Thanks for that link! The SysV R3 source floats around on the web. Its FSS is very different from what is in 8th edition. In 8th edition the switch has 11 entries (i.e. a file system is an object with 11 virtual methods). https://github.com/Alhadis/Research-Unix-v8/blob/master/v8/usr/sys/h/conf.h I have never really studied R3 but at quick inspection the FSS there has 27 (!) entries and seems to be more a sys call switch. In 10th edition it is still 11 entries, although some refactoring has taken place. Also later work from Research keeps it concise: the 9P protocol from Plan 9 has 14 messages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Thu Apr 9 08:16:20 2020 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 08 Apr 2020 15:16:20 -0700 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <20200407104251.GA89097@clarinet.employees.org> References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> <20200407104251.GA89097@clarinet.employees.org> Message-ID: At Tue, 7 Apr 2020 11:42:51 +0100, Derek Fawcus wrote: Subject: Re: [TUHS] First book on Unix for general readership > > On Sun, Apr 05, 2020 at 07:57:55PM -0400, Ronald Natalie wrote: > > > > The manuals aren’t really a book (and again, they weren’t really published as a book) > > A bit later on but... > > I'm prettry sure I managed to read the man pages published as a book while > at Uni, so between '86 and '90. I found it in the University Library. > > It was published by Western Electric, and had either a dark blue or black cover. Indeed the Unix manuals were available as printed books. Volume One was the manual pages and Volume Two the articles from /usr/doc. I remember seeing soft-cover bound copies of the 7th Edition manuals, first in someone's collection, then for sale, probably in the Computer Literacy bookshop on Lawrence in Sunnyvale, I think with a dark red cover on the ones I saw there. For some reason I never acquired a copy (probably because by then I already had several other sets of Unix manuals, including a complete set of boxed AT&T manuals. I think the next time this happened in the exact same way was with the "Unix Research System Tenth Edition" books published by Saunders College Publishing in 1990. (Which I probably bought at Computer Literacy.) There were also of course 4.4BSD manuals published and printed jointly by The USENIX Association and O'Reilly & Associates in 1994. > However, there were books of System V man pages published, since I bought > some of them. Yes, Prentice Hall's "UNIX System V/386" manuals from 1988 grace my shelves, along with an incomplete set of the UNIX Press "SVR4" manuals from 1992. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From woods at robohack.ca Thu Apr 9 08:23:09 2020 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 08 Apr 2020 15:23:09 -0700 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <33f635bb3ea67f5cf14b46316ca3b6a6.squirrel@squirrelmail.tuffmail.net> References: <1jKkMQ-2hN-00@marmaro.de> <854f7b58-9ba0-476f-a7e6-8579f4a8048d@localhost> <1jKlvG-4JB-00@marmaro.de> <3A36FF0A-7617-4B26-B4F3-FC183BF9A7FC@ronnatalie.com> <20200406000814.GH25105@mcvoy.com> <33f635bb3ea67f5cf14b46316ca3b6a6.squirrel@squirrelmail.tuffmail.net> Message-ID: At Mon, 6 Apr 2020 10:51:05 -0400, ron at ronnatalie.com wrote: Subject: Re: [TUHS] First book on Unix for general readership > > > I tried an ngram search on google, and came up with the following: > > > > Richard L. Gauthier. October 1981. Using the Unix System, Reston > > Publishing > > Co. ISBN 978-0835981644. > > > > Gosh, I'd forgotten about Gauthier, perhaps the worst UNIX book ever written. I was going to mention this book as one I thought might be the first book on Unix for a truly general readership. I bought a copy in 1982. Not a very good book indeed. Horribly typeset. Content reminds me of many of the early poor-quality O'Reilly books. But it was available in 1981, a few years before K&P's almost infinitely greater "TUPE" (though TUPE is targeted far more to programmers than general users). -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From pnr at planet.nl Thu Apr 9 20:22:49 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 9 Apr 2020 12:22:49 +0200 Subject: [TUHS] PK protocol In-Reply-To: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl> References: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl> Message-ID: <585EA404-7C39-46A1-BD72-E5493D62103B@planet.nl> > On 6 Apr 2020, at 20:12, Paul Ruizendaal wrote: > > Now I’m wondering. It looks like UUCP packet "protocol g” is maybe much the same as the original (“Chesson”) packet algorithm for Datakit, and if so it would be “dual use”. It would seem that in V7 line discipline ‘0’ was normal tty handling, discipline ‘1’ was PK protocol over serial and line discipline ‘2’ was PK protocol over something with CRC in the driver - whatever that was. > > Am I on the right track? It seems the story is more complicated. In a 1993 retrospective Fraser writes: "The first Datakit protocols used a packet structure that was aligned with cell boundaries. Chesson designed a file transfer protocol that transported data in variable length packets, each ending with a trailer. There was no packet header. It was argued that it is easy to generate a trailer after the body of a packet has been transmitted, and that control information in a trailer arrives at the receiver just when the receiver is ready to process that information.” Fraser uses the plural “the first protocols”: it would seem that there is not a single reference point. It also mentions that the protocols used a trailer, which does not match with the PK protocol. On the other hand this is a reference to a “file transfer protocol” which is not the same as a “link protocol”. Also, Chesson wrote a note on the PK driver a few years after the V7 release (e.g. here: https://pd.spuddy.org/fs/simtel20/uucp/uucproto.des). In this note he writes: "The resemblance between the flow control procedure in the packet driver and that defined for X.25 is no accident. The packet driver protocol began life as an attempt at cleaning up X.25. That is why, for example, control information is uniform in length (one byte), there is no RNR message (not needed), and there is but one timeout defined in the sender.” Earlier in the note Chesson also emphasised that the PK protocol was used for variation and experimentation. In the X.25 context, the reference to a CRC-based driver in the PK source may refer to a HDLC-like physical link. All in all it would seem that the PK driver is *not* what was used as an early Datakit protocol. However, it is probably the best proxy for what such a driver looked like that we have. It would seem likely to me that for instance the buffer strategy used in the PK driver would be about the same as that used for the Datakit driver(s) in V7. It is possible that a variation of the PK protocol was used for Datakit around V7 time. From wkt at tuhs.org Fri Apr 10 18:53:29 2020 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 10 Apr 2020 18:53:29 +1000 Subject: [TUHS] Discord chat in about 13 hours? Message-ID: Anybody feel like a text/voice chat on the ClassicCmp Discord server in about 13 hours, say 2200 UTC? #coff and the General voice channel. I'll pop on for an hour but start whenever you feel like. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sburjak at systech.com.au Fri Apr 10 19:11:36 2020 From: sburjak at systech.com.au (Serge Burjak) Date: Fri, 10 Apr 2020 19:11:36 +1000 Subject: [TUHS] Discord chat in about 13 hours? In-Reply-To: References: Message-ID: <4F952DD2-4942-4438-B907-6260EEA09803@systech.com.au> Hi, How do I get access to Discord server? Serge > On 10 Apr 2020, at 18:55, Warren Toomey wrote: > > Anybody feel like a text/voice chat on the ClassicCmp Discord server in about 13 hours, say 2200 UTC? > #coff and the General voice channel. > I'll pop on for an hour but start whenever you feel like. > Cheers, Warren > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From pnr at planet.nl Sat Apr 11 01:34:44 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 10 Apr 2020 17:34:44 +0200 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" Message-ID: <58126C92-CB5E-4647-ACA6-3E6B1665FF4C@planet.nl> Warren has been nice enough to put 8th, 9th and 10th edition on the TUHS “Unix Tree” web page. There is the following question on each entry web page: “Who wants to write something here?” Below my suggested draft text for Eight Edition. All suggestions for improvement welcome. === Shortly after the release of 7th Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved: Eighth Edition of Unix was released by Bell Laboratories in February 1985, six years after Seventh Edition. Key innovations in 8th Edition include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable applications built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system. Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal. Several of the new ideas from Eigth Edition found their way into the 3rd release of System V, although in a much modified way. === From robpike at gmail.com Sat Apr 11 06:50:31 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 11 Apr 2020 06:50:31 +1000 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" In-Reply-To: <58126C92-CB5E-4647-ACA6-3E6B1665FF4C@planet.nl> References: <58126C92-CB5E-4647-ACA6-3E6B1665FF4C@planet.nl> Message-ID: It wasn't that "shortly", it was several years. Maybe just drop the adverb, or put in actual dates. Otherwise this seems OK (except for a typo in "Eigth".) -rob On Sat, Apr 11, 2020 at 1:35 AM Paul Ruizendaal wrote: > > Warren has been nice enough to put 8th, 9th and 10th edition on the TUHS “Unix Tree” web page. > > There is the following question on each entry web page: “Who wants to write something here?” > > Below my suggested draft text for Eight Edition. All suggestions for improvement welcome. > > === > > Shortly after the release of 7th Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved: Eighth Edition of Unix was released by Bell Laboratories in February 1985, six years after Seventh Edition. > > Key innovations in 8th Edition include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable applications built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system. > > Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal. > > Several of the new ideas from Eigth Edition found their way into the 3rd release of System V, although in a much modified way. > > === > From wkt at tuhs.org Sat Apr 11 08:11:31 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 11 Apr 2020 08:11:31 +1000 Subject: [TUHS] [COFF] Discord chat in about 13 hours? In-Reply-To: References: Message-ID: <20200410221131.GA31654@minnie.tuhs.org> On Fri, Apr 10, 2020 at 06:53:29PM +1000, Warren Toomey wrote: > Anybody feel like a text/voice chat on the ClassicCmp Discord server in > about 13 hours, say 2200 UTC? > #coff and the General voice channel. Looks like just Charles and I chatting right now. Warren From imp at bsdimp.com Sat Apr 11 13:48:44 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 10 Apr 2020 21:48:44 -0600 Subject: [TUHS] [COFF] Discord chat in about 13 hours? In-Reply-To: <20200410221131.GA31654@minnie.tuhs.org> References: <20200410221131.GA31654@minnie.tuhs.org> Message-ID: On Fri, Apr 10, 2020, 4:12 PM Warren Toomey wrote: > On Fri, Apr 10, 2020 at 06:53:29PM +1000, Warren Toomey wrote: > > Anybody feel like a text/voice chat on the ClassicCmp Discord server > in > > about 13 hours, say 2200 UTC? > > #coff and the General voice channel. > > Looks like just Charles and I chatting right now. > Doh... missed this... was busy gardening today. Warner > Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sun Apr 12 00:47:40 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 11 Apr 2020 10:47:40 -0400 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" Message-ID: <202004111447.03BElenq005540@tahoe.cs.Dartmouth.EDU> The v8 manual was printed in 1985, but the system was not "released" in the ordinary sense until a couple of years ago. Some v8 features made it out into the world via USG; some were described in open literature or Usenix presentations, but I believe none were formally shipped out of the company. Doug From norman at oclsc.org Sun Apr 12 01:24:03 2020 From: norman at oclsc.org (Norman Wilson) Date: Sat, 11 Apr 2020 11:24:03 -0400 (EDT) Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" Message-ID: <20200411152403.5CB384422F@lignose.oclsc.org> Doug McIlroy: The v8 manual was printed in 1985, but the system was not "released" in the ordinary sense until a couple of years ago. Some v8 features made it out into the world via USG; some were described in open literature or Usenix presentations, but I believe none were formally shipped out of the company. I'm surprised; I thought copies of the V8 manual existed when I arrived at the Labs in mid-1984, but the date on the title page is indeed February 1985. There was no general release of V8 like those for earlier Research systems, but there was a quasi-official V8 tape sent to a handful of universities under a special letter agreement. I remember working on that with Dennis, checking that everything compiled and worked properly in a chroot environment before the tape was written. I think that happened in the summer of 1985. I don't remember our doing that work, to make a single coherent consistency-checked release tape, for any subsequent system; just one-off caveat-emptor snapshots. Norman Wilson Toronto ON From norman at oclsc.org Sun Apr 12 01:38:44 2020 From: norman at oclsc.org (Norman Wilson) Date: Sat, 11 Apr 2020 11:38:44 -0400 (EDT) Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" Message-ID: <20200411153844.910A04422F@lignose.oclsc.org> Minor corrections to the material in Paul's text. This is meant to be a laundry-list of facts, not a suggested set of words; I'm feeling too prolix this morning to produce the latter, and figure those on the list may be interested in the petty details anyway. The initial user-mode environment was a mix of 32V, subsequent work within 1127, and imports from 4.1BSD. I don't know the exact heritage: whether it was 1127's work with 4.1BSD stuff added or vice-versa. The kernel was a clean break, however: 4.1xBSD for some value of x (probably 4.1a but I don't remember which) with Research changes. By the time of V8, that means: -- All trace of BSD's original network interfaces removed, except that select(2) remained in a slightly-different form. -- Stream I/O system added; all communication-device drivers (serial ports, Ethernet, Datakit) changed to work with streams. Pipes were streams. -- File system switch added, supporting Killian's /proc and Weinberger's first-generation (neta) network file system. -- Berkeley FFS replaced by Weinberger's bitmapped file system: essentially the V7 file system except the free list was a bitmap and the blocksize was 4KiB. Hacky implementation, depending on a flag bit in the minor device number; didn't use the file system switch. Old 512-byte-block file systems had to be supported partly to ease the changeover, partly because the first version had a limited bitmap size so file systems larger than about 120MiB wouldn't work. This limit was removed later. (In retrospect I'm surprised I didn't then insist on converting any remaining old-format file systems in our domain and then removing the old-format code from the kernel, since user-mode tools--including a user-mode file server!--could be used to access any old disks discovered later.) For the purposes of Paul's note it probably suffices just to say that there was a restart with a 4.1-series kernel with changes as he describes, except also the new file system format. Norman Wilson Toronto ON From lm at mcvoy.com Sun Apr 12 01:44:28 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 11 Apr 2020 08:44:28 -0700 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" In-Reply-To: <20200411153844.910A04422F@lignose.oclsc.org> References: <20200411153844.910A04422F@lignose.oclsc.org> Message-ID: <20200411154428.GF10016@mcvoy.com> On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote: > -- Stream I/O system added; all communication-device > drivers (serial ports, Ethernet, Datakit) changed to > work with streams. Pipes were streams. How was performance? Was this Dennis' streams, not Sys V STREAMS? I ported Lachmans/Convergents STREAMS based TCP/IP stack to the ETA 10 Unix and SCO Unix and performance just sucked. Ditto for the Solaris port (which I did not do, I don't think it made any difference who did the port though). From arnold at skeeve.com Sun Apr 12 04:49:00 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 11 Apr 2020 12:49:00 -0600 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" In-Reply-To: <20200411152403.5CB384422F@lignose.oclsc.org> References: <20200411152403.5CB384422F@lignose.oclsc.org> Message-ID: <202004111849.03BIn08J029073@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > There was no general release of V8 like those for earlier > Research systems, but there was a quasi-official V8 tape > sent to a handful of universities under a special letter > agreement. I remember working on that with Dennis, > checking that everything compiled and worked properly > in a chroot environment before the tape was written. > I think that happened in the summer of 1985. Sounds about right. Circa late '86 or early '87, IIRC correctly, DMR spoke at Georgia Tech, and Gene Spafford, who was still there arranged to get a copy of the V8 tape. I got a friend who worked there to send me the man page sources and printed a copy for myself. :-) I later got an official (but used) copy via BWK. (I also arranged to buy a V9 manual in the early 90s.) Arnold From arnold at skeeve.com Sun Apr 12 04:52:47 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 11 Apr 2020 12:52:47 -0600 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" In-Reply-To: <20200411153844.910A04422F@lignose.oclsc.org> References: <20200411153844.910A04422F@lignose.oclsc.org> Message-ID: <202004111852.03BIqlsD029181@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > The kernel was a clean break, however: 4.1xBSD for some > value of x (probably 4.1a but I don't remember which) > with Research changes. By the time of V8, that means: > .... > -- Berkeley FFS replaced by Weinberger's bitmapped > file system: As far as I understand it, the Berkeley FFS didn't appear until much closer to 4.2; it was definitely not in 4.1 and was likely not in 4.1a. Which would explain why V8 would have still had the 14 character filename limit. > essentially the V7 file system except > the free list was a bitmap and the blocksize was 4KiB. ISTR that System V picked this up at some point also, although I don't recall if the bigger block size was 1K or 4K. I may be misremembering though. Thanks, Arnold From angus at fairhaven.za.net Sun Apr 12 17:33:16 2020 From: angus at fairhaven.za.net (Angus Robinson) Date: Sun, 12 Apr 2020 09:33:16 +0200 Subject: [TUHS] Discord chat in about 13 hours? In-Reply-To: References: Message-ID: could you send an invite ? Would love to be on the next one or just browse the channels. On Fri, Apr 10, 2020 at 10:54 AM Warren Toomey wrote: > Anybody feel like a text/voice chat on the ClassicCmp Discord server in > about 13 hours, say 2200 UTC? > #coff and the General voice channel. > I'll pop on for an hour but start whenever you feel like. > Cheers, Warren > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sun Apr 12 18:51:58 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 12 Apr 2020 10:51:58 +0200 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" In-Reply-To: References: <58126C92-CB5E-4647-ACA6-3E6B1665FF4C@planet.nl> Message-ID: Below an update with comments reflected. === After the Seventh Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved and an Eighth Edition manual was completed by Bell Laboratories in February 1985, six years after 7th Edition. The 8th Edition source code was not as widely distributed as the 6th and 7th Edition sources had been. The file system in 8th Edition was rewritten to work with a bitmapped free list and allocation clusters of 4KB (8 blocks); it also supported the V7 filesystem for backwards compatibility with disk clusters of 1, 2 or 4 blocks. Key innovations in the 8th Edition kernel include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable developments built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system. Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal. Several of the new ideas from Eighth Edition found their way into the 3rd release of System V, although in a much modified form. === > On Sat, Apr 11, 2020 at 1:35 AM Paul Ruizendaal wrote: >> >> Warren has been nice enough to put 8th, 9th and 10th edition on the TUHS “Unix Tree” web page. >> >> There is the following question on each entry web page: “Who wants to write something here?” >> >> Below my suggested draft text for Eight Edition. All suggestions for improvement welcome. >> >> === >> >> Shortly after the release of 7th Edition, the VAX became the base machine for further Unix development. The initial code base was the 32V port, enhanced with selected elements from 4.1BSD, such as support for virtual memory and later the TCP/IP stack. From there the code further evolved: Eighth Edition of Unix was released by Bell Laboratories in February 1985, six years after Seventh Edition. >> >> Key innovations in 8th Edition include ‘streams’ and the 'file system switch’, which allowed the “everything is a file” approach to be extended to new areas. Three notable applications built on these were the ‘/proc’ file system and new debugger API, a unified approach to networking over Datakit, TCP/IP and phone lines, and a network file system. >> >> Eighth Edition is also at the root of graphical user interfaces on Unix, being the platform used for the development of the ‘Blit’ graphical terminal. >> >> Several of the new ideas from Eigth Edition found their way into the 3rd release of System V, although in a much modified way. >> >> === >> From pnr at planet.nl Sun Apr 12 19:26:44 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 12 Apr 2020 11:26:44 +0200 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" Message-ID: <60425F60-2759-423B-8C8F-916BF14CC221@planet.nl> Many thanks for the below notes! Some comments in line below: > The initial user-mode environment was a mix of 32V, > subsequent work within 1127, and imports from 4.1BSD. > I don't know the exact heritage: whether it was 1127's > work with 4.1BSD stuff added or vice-versa. Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later. > The kernel was a clean break, however: 4.1xBSD for some > value of x (probably 4.1a but I don't remember which) > with Research changes. I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort. As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/* vmmem.c 4.7 81/07/09 */“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?) For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition. As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet). > -- Berkeley FFS replaced by Weinberger's bitmapped > file system: essentially the V7 file system except > the free list was a bitmap and the blocksize was 4KiB. Thank you for pointing this out. With my focus on networking I had completely missed that. > Hacky implementation, depending on a flag bit in the > minor device number; didn't use the file system switch. > Old 512-byte-block file systems had to be supported > partly to ease the changeover, partly because the first > version had a limited bitmap size so file systems larger > than about 120MiB wouldn't work. For those interested, some of the relevant files are: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’) And indeed the bitmap was fitted inside the 4KB superblock, > This limit was removed > later. (In retrospect I'm surprised I didn't then insist > on converting any remaining old-format file systems in > our domain and then removing the old-format code from > the kernel, since user-mode tools--including a user-mode > file server!--could be used to access any old disks > discovered later.) > > For the purposes of Paul's note it probably suffices > just to say that there was a restart with a 4.1-series > kernel with changes as he describes, except also the > new file system format. From pnr at planet.nl Sun Apr 12 19:30:39 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 12 Apr 2020 11:30:39 +0200 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" Message-ID: Oops - pressed send too soon - apologies — Many thanks for the below notes! Some comments in line below: > The initial user-mode environment was a mix of 32V, > subsequent work within 1127, and imports from 4.1BSD. > I don't know the exact heritage: whether it was 1127's > work with 4.1BSD stuff added or vice-versa. Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later. > The kernel was a clean break, however: 4.1xBSD for some > value of x (probably 4.1a but I don't remember which) > with Research changes. I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort. As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/* vmmem.c 4.7 81/07/09 */“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?) For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition. As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet). > -- Berkeley FFS replaced by Weinberger's bitmapped > file system: essentially the V7 file system except > the free list was a bitmap and the blocksize was 4KiB. Thank you for pointing this out. With my focus on networking I had completely missed that. > Hacky implementation, depending on a flag bit in the > minor device number; didn't use the file system switch. > Old 512-byte-block file systems had to be supported > partly to ease the changeover, partly because the first > version had a limited bitmap size so file systems larger > than about 120MiB wouldn't work. For those interested, some of the relevant files are: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’) And indeed the bitmap was fitted inside the 4KB superblock, 961 longs. 961 x 32 bits x 4KB = 120MB I’m not sure I understand the link between cluster and page size that is mentioned in param.h > This limit was removed > later. (In retrospect I'm surprised I didn't then insist > on converting any remaining old-format file systems in > our domain and then removing the old-format code from > the kernel, since user-mode tools--including a user-mode > file server!--could be used to access any old disks > discovered later.) From robpike at gmail.com Sun Apr 12 20:00:56 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 12 Apr 2020 20:00:56 +1000 Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" In-Reply-To: References: Message-ID: My favorite use of the file system switch was the "face server" (analogous to name server), documented in a paper by myself and Dave Presotto at the Portland USENIX in 1985. http://doc.cat-v.org/bell_labs/face_the_nation/ We believe this was the first networked delivery of facial images to indicate the sender of an arriving mail message. The associated vismon program was also of interest in what it showed, and how small the code was given the uniform system interface to resources. -rob On Sun, Apr 12, 2020 at 7:31 PM Paul Ruizendaal wrote: > > Oops - pressed send too soon - apologies > > — > > Many thanks for the below notes! > > Some comments in line below: > > > The initial user-mode environment was a mix of 32V, > > subsequent work within 1127, and imports from 4.1BSD. > > I don't know the exact heritage: whether it was 1127's > > work with 4.1BSD stuff added or vice-versa. > > Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later. > > > The kernel was a clean break, however: 4.1xBSD for some > > value of x (probably 4.1a but I don't remember which) > > with Research changes. > > I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort. > > As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/* vmmem.c 4.7 81/07/09 */“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?) > > For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition. > > As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet). > > > -- Berkeley FFS replaced by Weinberger's bitmapped > > file system: essentially the V7 file system except > > the free list was a bitmap and the blocksize was 4KiB. > > Thank you for pointing this out. With my focus on networking I had completely missed that. > > > Hacky implementation, depending on a flag bit in the > > minor device number; didn't use the file system switch. > > Old 512-byte-block file systems had to be supported > > partly to ease the changeover, partly because the first > > version had a limited bitmap size so file systems larger > > than about 120MiB wouldn't work. > > For those interested, some of the relevant files are: > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit) > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union) > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’) > > And indeed the bitmap was fitted inside the 4KB superblock, 961 longs. > 961 x 32 bits x 4KB = 120MB > > I’m not sure I understand the link between cluster and page size that is mentioned in param.h > > > This limit was removed > > later. (In retrospect I'm surprised I didn't then insist > > on converting any remaining old-format file systems in > > our domain and then removing the old-format code from > > the kernel, since user-mode tools--including a user-mode > > file server!--could be used to access any old disks > > discovered later.) > From pnr at planet.nl Sun Apr 12 20:03:23 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 12 Apr 2020 12:03:23 +0200 Subject: [TUHS] STREAMS performance Message-ID: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> > Date: Sat, 11 Apr 2020 08:44:28 -0700 > From: Larry McVoy > > On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote: >> -- Stream I/O system added; all communication-device >> drivers (serial ports, Ethernet, Datakit) changed to >> work with streams. Pipes were streams. > > How was performance? Was this Dennis' streams, not Sys V STREAMS? It was streams, not STREAMS. > I ported Lachmans/Convergents STREAMS based TCP/IP stack to the > ETA 10 Unix and SCO Unix and performance just sucked. Ditto for > the Solaris port (which I did not do, I don't think it made any > difference who did the port though). STREAMS are outside the limited scope I try to restrain myself to, but I’m intrigued. What in the above case drove/caused the poor performance? There was a debate on the LKML in the late 1990’s where Caldera wanted STREAMS support in Linux and to the extent the arguments were technical *), my understanding of them is that the main show stopper was that STREAMS would make ‘zero copy’ networking impossible. If so, then it is a comment more about the underlying buffer strategy than STREAMS itself. Did STREAMS also perform poorly in the 1986 context they were developed in? Paul *) Other arguments pro- and con included forward maintenance and market need, but I’m not so interested in those aspects of the debate. From ality at pbrane.org Mon Apr 13 09:15:03 2020 From: ality at pbrane.org (Anthony Martin) Date: Sun, 12 Apr 2020 16:15:03 -0700 Subject: [TUHS] STREAMS performance In-Reply-To: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> Message-ID: <20200412231503.GA48389@alice> As an aside, Plan 9 began with a descendant of dmr's streams but replaced it in mid-1993 with a simple queued i/o scheme. This was done for performance and to simplify the code since they didn't end up using much of the streams functionality. Anthony From joe at via.net Mon Apr 13 08:55:48 2020 From: joe at via.net (joe mcguckin) Date: Sun, 12 Apr 2020 15:55:48 -0700 Subject: [TUHS] STREAMS performance In-Reply-To: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> Message-ID: <37F9655C-D42C-4504-9926-129F6DF5C158@via.net> I seem to remember that Sun was trying to sell boxes to the airline / reservation industry, and one of the ways they came up with to make Solaris handle thousands of ascii terminals was to push the character discipline code into streams in order to eliminate the multiple user/kernel crossings per character being handled… Joe Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Apr 12, 2020, at 3:03 AM, Paul Ruizendaal wrote: > > >> Date: Sat, 11 Apr 2020 08:44:28 -0700 >> From: Larry McVoy >> >> On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote: >>> -- Stream I/O system added; all communication-device >>> drivers (serial ports, Ethernet, Datakit) changed to >>> work with streams. Pipes were streams. >> >> How was performance? Was this Dennis' streams, not Sys V STREAMS? > > It was streams, not STREAMS. > >> I ported Lachmans/Convergents STREAMS based TCP/IP stack to the >> ETA 10 Unix and SCO Unix and performance just sucked. Ditto for >> the Solaris port (which I did not do, I don't think it made any >> difference who did the port though). > > STREAMS are outside the limited scope I try to restrain myself to, but I’m intrigued. > > What in the above case drove/caused the poor performance? > > There was a debate on the LKML in the late 1990’s where Caldera wanted STREAMS support in Linux and to the extent the arguments were technical *), my understanding of them is that the main show stopper was that STREAMS would make ‘zero copy’ networking impossible. If so, then it is a comment more about the underlying buffer strategy than STREAMS itself. > > Did STREAMS also perform poorly in the 1986 context they were developed in? > > Paul > > *) Other arguments pro- and con included forward maintenance and market need, but I’m not so interested in those aspects of the debate. > From robpike at gmail.com Mon Apr 13 11:43:03 2020 From: robpike at gmail.com (Rob Pike) Date: Mon, 13 Apr 2020 11:43:03 +1000 Subject: [TUHS] STREAMS performance In-Reply-To: <20200412231503.GA48389@alice> References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> <20200412231503.GA48389@alice> Message-ID: It did? I think a version of streams showed up at some point, and were replaced; of that you are correct. But it certainly didn't begin with anything like streams. It began with a file system mux. -rob On Mon, Apr 13, 2020 at 9:16 AM Anthony Martin wrote: > > As an aside, Plan 9 began with a descendant of dmr's streams > but replaced it in mid-1993 with a simple queued i/o scheme. > This was done for performance and to simplify the code since > they didn't end up using much of the streams functionality. > > Anthony From ality at pbrane.org Mon Apr 13 13:00:20 2020 From: ality at pbrane.org (Anthony Martin) Date: Sun, 12 Apr 2020 20:00:20 -0700 Subject: [TUHS] STREAMS performance In-Reply-To: References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> <20200412231503.GA48389@alice> Message-ID: <20200413030020.GA67784@alice> Rob Pike once said: > It did? I think a version of streams showed up at some point, and were > replaced; of that you are correct. But it certainly didn't begin with > anything like streams. It began with a file system mux. I realize you would probably know better, but ... I didn't mean that streams was the first thing in Plan 9, just that the I/O system for pipes, network devices, etc. was descended from streams. That was the case at least as far back as 1990. Look at the early Plan 9 code for the pipe¹ and ethernet² devices, the code for Streams, Queues, and Blocks in port/stream.c³ and power/dat.h⁴, and tell me that doesn't descend from v8 streams. :) Also, thanks for Plan 9. It's lovely. Anthony 1. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devpipe.c 2. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devlance.c#L256 3. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/stream.c 4. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/power/dat.h#L338 From robpike at gmail.com Mon Apr 13 13:14:55 2020 From: robpike at gmail.com (Rob Pike) Date: Mon, 13 Apr 2020 13:14:55 +1000 Subject: [TUHS] STREAMS performance In-Reply-To: <20200413030020.GA67784@alice> References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> <20200412231503.GA48389@alice> <20200413030020.GA67784@alice> Message-ID: Nice to see Egreg again. -rob On Mon, Apr 13, 2020 at 1:00 PM Anthony Martin wrote: > > Rob Pike once said: > > It did? I think a version of streams showed up at some point, and were > > replaced; of that you are correct. But it certainly didn't begin with > > anything like streams. It began with a file system mux. > > I realize you would probably know better, but ... > > I didn't mean that streams was the first thing in Plan 9, just that the > I/O system for pipes, network devices, etc. was descended from streams. > That was the case at least as far back as 1990. > > Look at the early Plan 9 code for the pipe¹ and ethernet² devices, the > code for Streams, Queues, and Blocks in port/stream.c³ and power/dat.h⁴, > and tell me that doesn't descend from v8 streams. :) > > Also, thanks for Plan 9. It's lovely. > > Anthony > > 1. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devpipe.c > 2. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devlance.c#L256 > 3. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/stream.c > 4. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/power/dat.h#L338 From doug at cs.dartmouth.edu Tue Apr 14 12:13:17 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 13 Apr 2020 22:13:17 -0400 Subject: [TUHS] First book on Unix for general readership Message-ID: <202004140213.03E2DHF1002571@tahoe.cs.Dartmouth.EDU> > Indeed the Unix manuals were available as printed books. Volume One was the manual pages and Volume Two the articles from /usr/doc. I remember seeing soft-cover bound copies of the 7th Edition manuals, ... > I think the next time this happened in the exact same way was with the "Unix Research System Tenth Edition" books published by Saunders College Publishing in 1990. Those were the only two that were published as trade books. I still use the 10th Ed regularly. The 7th Ed was a debacle. The publisher didn't bother to send us galleys because they had printed straight from troff. It turned out they did not have the full troff character set, and put an @ sign in place of each missing character. The whole print run was done before we saw a copy. Not knowing whether they ever fixed it, I'd be interested to hear whether or not the botch made it to bookstores. Doug From grog at lemis.com Tue Apr 14 15:30:24 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 14 Apr 2020 15:30:24 +1000 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <202004140213.03E2DHF1002571@tahoe.cs.Dartmouth.EDU> References: <202004140213.03E2DHF1002571@tahoe.cs.Dartmouth.EDU> Message-ID: <20200414053024.GA67339@eureka.lemis.com> On Monday, 13 April 2020 at 22:13:17 -0400, Doug McIlroy wrote: > > Those were the only two that were published as trade books. I still use > the 10th Ed regularly. The 7th Ed was a debacle. The publisher didn't > bother to send us galleys because they had printed straight from troff. > It turned out they did not have the full troff character set, and put > an @ sign in place of each missing character. The whole print run was > done before we saw a copy. Not knowing whether they ever fixed it, I'd > be interested to hear whether or not the botch made it to bookstores. OK, I've dug out my copies. Two volumes, published by CBS College publishing, aka Holt, Rinehart and Winston in 1982, both titled "UNIX Programmer's Manual". Volume 1 (ISBN 0-03-061742-1) was the man pages, and volume 2 (ISBN 0-03-061743-X) was the supplementary docs, starting with “7th Edition UNIX — Summary”, dated September 6, 1978. They have perforated, 3-hole punched pages, clearly intended to be torn out and put into a three-ring binder. I've skimmed through both of them, and I can't find any obvious typesetting errors. "Typesetting Mathematics" shows some quite complicated equations. And in the quick reference in volume 1, all the troff special characters seem right, even up to less common characters such as \(bs. Is there anything specific that I should look for? Scans available if they would help. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From imp at bsdimp.com Tue Apr 14 15:38:00 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 13 Apr 2020 23:38:00 -0600 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <20200414053024.GA67339@eureka.lemis.com> References: <202004140213.03E2DHF1002571@tahoe.cs.Dartmouth.EDU> <20200414053024.GA67339@eureka.lemis.com> Message-ID: On Mon, Apr 13, 2020, 11:31 PM Greg 'groggy' Lehey wrote: > On Monday, 13 April 2020 at 22:13:17 -0400, Doug McIlroy wrote: > > > > Those were the only two that were published as trade books. I still use > > the 10th Ed regularly. The 7th Ed was a debacle. The publisher didn't > > bother to send us galleys because they had printed straight from troff. > > It turned out they did not have the full troff character set, and put > > an @ sign in place of each missing character. The whole print run was > > done before we saw a copy. Not knowing whether they ever fixed it, I'd > > be interested to hear whether or not the botch made it to bookstores. > > OK, I've dug out my copies. Two volumes, published by CBS College > publishing, aka Holt, Rinehart and Winston in 1982, both titled "UNIX > Programmer's Manual". Volume 1 (ISBN 0-03-061742-1) was the man > pages, and volume 2 (ISBN 0-03-061743-X) was the supplementary docs, > starting with “7th Edition UNIX — Summary†, dated September 6, 1978. > They have perforated, 3-hole punched pages, clearly intended to be > torn out and put into a three-ring binder. > > I've skimmed through both of them, and I can't find any obvious > typesetting errors. "Typesetting Mathematics" shows some quite > complicated equations. And in the quick reference in volume 1, all > the troff special characters seem right, even up to less common > characters such as \(bs. Is there anything specific that I should > look for? Scans available if they would help. > Mine are like that too. Maybe it was just wrong for the first printing? Warner Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Wed Apr 15 00:54:23 2020 From: dot at dotat.at (Tony Finch) Date: Tue, 14 Apr 2020 15:54:23 +0100 Subject: [TUHS] STREAMS performance In-Reply-To: <37F9655C-D42C-4504-9926-129F6DF5C158@via.net> References: <2DE6E671-7FD2-463A-B2E7-7951DBD15CA0@planet.nl> <37F9655C-D42C-4504-9926-129F6DF5C158@via.net> Message-ID: joe mcguckin wrote: > > I seem to remember that Sun was trying to sell boxes to the airline / > reservation industry, and one of the ways they came up with to make > Solaris handle thousands of ascii terminals was to push the character > discipline code into streams in order to eliminate the multiple > user/kernel crossings per character being handled… I encountered this feature when deploying some new Solaris 2.5.1 / 2.6 web servers in about 1997/8. We were chroot()ing the user login daemons (telnet and ftp) to improve security, and they wouldn't work on a freshly rebooted server. Eventually I worked out that telnetd loaded a kernel module on demand, and this didn't work when it was chroot()ed, but telnetd could skip it if the module had previously been loaded. (I could see from truss and/or strings that telnetd was specifying an absolute path to the module rather than expecting the kernel to know where to find it.) I was kind of impressed by the performance engineering, and it stuck in my memory because it took me so long to understand why it sometimes didn't work... Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Variable 3 or 4 at first in southeast, otherwise cyclonic 5 to 7. Moderate or rough, occasionally very rough at first in northwest. Rain or thundery showers. Good, occasionally poor. From doug at cs.dartmouth.edu Wed Apr 15 01:10:50 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 14 Apr 2020 11:10:50 -0400 Subject: [TUHS] First book on Unix for general readership Message-ID: <202004141510.03EFAo1R018763@tahoe.cs.Dartmouth.EDU> > OK, I've dug out my copies. They have perforated, 3-hole punched pages ... > I can't find any obvious typesetting errors. That sets my mind at rest after three decades. What I saw back in the day was littered with @ signs, and was not punched for a ring binder. Thanks for checking. Doug From steve.mynott at gmail.com Wed Apr 15 01:27:37 2020 From: steve.mynott at gmail.com (Steve Mynott) Date: Tue, 14 Apr 2020 16:27:37 +0100 Subject: [TUHS] First book on Unix for general readership In-Reply-To: <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com> References: <1jKkMQ-2hN-00@marmaro.de> <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com> Message-ID: On Sat, 4 Apr 2020 at 16:58, Nemo Nusquam wrote: > > On 04/04/20 11:05, markus schnalke wrote (in part): > > Thus I now wonder what the first book on Unix, intended for a general > > readership was. > Not to be overly pedantic but what would be a "general readership"? I think the wikipedia article meant Bourne's "The Unix System" was the first general introduction to UNIX. In the autumn of 1984 it was a recommended text book for an introduction to computing course aimed at first year science undergraduates at an English university. They taught us awk programming and basic shell commands on a VAX running BSD 4.1 using it. I still have a copy. So by general readership they probably meant primer. -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 From imp at bsdimp.com Wed Apr 15 06:32:05 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 14 Apr 2020 14:32:05 -0600 Subject: [TUHS] First book on Unix for general readership In-Reply-To: References: <1jKkMQ-2hN-00@marmaro.de> <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com> Message-ID: On Tue, Apr 14, 2020 at 9:27 AM Steve Mynott wrote: > On Sat, 4 Apr 2020 at 16:58, Nemo Nusquam wrote: > > > > On 04/04/20 11:05, markus schnalke wrote (in part): > > > Thus I now wonder what the first book on Unix, intended for a general > > > readership was. > > Not to be overly pedantic but what would be a "general readership"? > > I think the wikipedia article meant Bourne's "The Unix System" was > the first general introduction to UNIX. > > In the autumn of 1984 it was a recommended text book for an > introduction to computing course aimed at first year science > undergraduates at an English university. > > They taught us awk programming and basic shell commands on a VAX > running BSD 4.1 using it. I still have a copy. > > So by general readership they probably meant primer. > I think it's not the first primer, but it's one of the first. But I'll know more once I process through the half dozen books from the early 80s on Unix that just arrived from ebay... I'll post a brief review and a bibliography Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Apr 15 08:03:40 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 14 Apr 2020 16:03:40 -0600 Subject: [TUHS] First book on Unix for general readership In-Reply-To: References: <1jKkMQ-2hN-00@marmaro.de> <154b6bec-aaaf-4c40-54b9-4409e0940a05@gmail.com> Message-ID: I have the following 5 books: The Unix Operating System Book by Mike Banahan and Andy Rutter (Copyright 1983) A Unix Primer by Ann Nicols Lomuto & Nico Lomuto (Copyright 1983) The Unix System by SR Borne (Copyright 1983) Introducing the Unix System by Henry McGilton and Rachel Morgan (Copyright 1983) A User Guide to the Unix System by Rebecca Thomas and Jean Yates (Copyright 1982) The last one is quite interesting because it has a 13 page annotated bibliography. Here's the earlier books: Information and Publication Division. The UNIX System. An Easier Way to Communicate with Computers." 1979. This has a similar title to an article by SP Morgan in Bell Laboratories Record 56 (1978). The rest are all clearly articles in journals and magazines back to the original in 75. And I have the following on the way that's been mentioned before: Using the Unix System by Richard Gauthier Command Computer Programming 1981 So there's at least 2 books that pre-date Borne's book, maybe more. There's a second Banahan book that I ordered, but didn't get that claims to be 1982. Trying to get to the bottom of that... All of the above are tutorials to varying degrees, though I've only reviewed the Lomuto and Thomas/Yates books in any detail. None appear to have useful additional historic information. The McGilton/Morgan book is the oldest one I've seen talk about Berkeley Unix system. The chapter was written in the spring of 1982. And there's this gem https://www.youtube.com/watch?v=XvDZLjaCJuw that I've seen before here I think, which is dated 1982 and is a film with the same title "he UNIX System. An Easier Way to Communicate with Computers" as one of the items above, so I wonder if that's this film or a paper copy of it. It's clearly Bell Labs related, though. Warner On Tue, Apr 14, 2020 at 2:32 PM Warner Losh wrote: > > > On Tue, Apr 14, 2020 at 9:27 AM Steve Mynott > wrote: > >> On Sat, 4 Apr 2020 at 16:58, Nemo Nusquam wrote: >> > >> > On 04/04/20 11:05, markus schnalke wrote (in part): >> > > Thus I now wonder what the first book on Unix, intended for a general >> > > readership was. >> > Not to be overly pedantic but what would be a "general readership"? >> >> I think the wikipedia article meant Bourne's "The Unix System" was >> the first general introduction to UNIX. >> >> In the autumn of 1984 it was a recommended text book for an >> introduction to computing course aimed at first year science >> undergraduates at an English university. >> >> They taught us awk programming and basic shell commands on a VAX >> running BSD 4.1 using it. I still have a copy. >> >> So by general readership they probably meant primer. >> > > I think it's not the first primer, but it's one of the first. But I'll > know more once I process through the half dozen books from the early 80s on > Unix that just arrived from ebay... I'll post a brief review and a > bibliography > > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Wed Apr 15 08:07:29 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 15 Apr 2020 00:07:29 +0200 Subject: [TUHS] 4.2BSD Steering committee Message-ID: <19A0192D-3035-4CA5-B66D-4C1D46F0CF1D@planet.nl> According to “20 years of BSD”, there was a steering committee to inform the development of what would eventually be 4.2BSD Unix. The committee had the following members: Duane Adams and Bob Baker: DARPA Bob Fabry, Bill Joy, Sam Leffler: CSRG Dennis Ritchie: Bell Labs Alan Nemeth, Rob Gurwitz: BBN Dan Lynch: ISI Keith Lantz: Stanford Rick Rashid: CMU Bert Halstead: MIT Jerry Popek: UCLA I’m intrigued by the composition and the rationale for each member. Some of it is obvious, some of it is not. According to “20 years of BSD” what DARPA wanted was: "In particular, the new system was expected to include a faster file system that would raise throughput to the speed of available disk technology, support processes with multi-gigabyte address space requirements, provide flexible interprocess communication facilities that allow researchers to do work in distributed systems, and would integrate networking support so that machines running the new system could easily participate in the ARPAnet." As I understand Duane Adams was the contract manager and Bob Baker a DARPA vice-president. The CSRG crowd are also clear, they were going to do the work. Then it becomes less clear. I can certainly see the logic of asking dmr to provide his guidance, also in view of Bell Labs expertise in working with large scale communication systems. I can also see the logic of having the BBN and ISI folk there, representing the Arpanet community and doing the work on the new TCP/IP protocol stack. I’m not sure about the four others. They seem to be one each for 4 main computer science schools in the US at the time. Rashid and Popek had moreover recently completed distributed systems (Aleph and LOCUS). Halstead seems to have been working on messaging systems at the time. I’m not sure what Lantz’ spike was at the time. All in all, a strong focus on distributed systems and messaging. No people with apparent links to virtual memory research or disk access research. Other than dmr, no research people from industry. For example, nobody from Xerox Parc. Nobody from IBM, HP, DEC, DG, etc. Any and all recollections about the committee and its composition welcome. From clemc at ccc.com Wed Apr 15 08:12:48 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 14 Apr 2020 18:12:48 -0400 Subject: [TUHS] 4.2BSD Steering committee In-Reply-To: <19A0192D-3035-4CA5-B66D-4C1D46F0CF1D@planet.nl> References: <19A0192D-3035-4CA5-B66D-4C1D46F0CF1D@planet.nl> Message-ID: On Tue, Apr 14, 2020 at 6:08 PM Paul Ruizendaal wrote: > I’m not sure what Lantz’ spike was at the time. > https://en.wikipedia.org/wiki/V_(operating_system) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Wed Apr 15 09:06:10 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 15 Apr 2020 01:06:10 +0200 Subject: [TUHS] Early Datakit - Summary of findings Message-ID: <686B5993-6772-4A0B-BAF0-90F1C882438B@planet.nl> I’ve posted a summary of my Datakit notes here: https://drive.google.com/open?id=1p6HD5-NSAYKfiXL6GUxfYZgGoesqG6Sp (available for a limited time) Hopefully, these notes are helpful for anyone trying to figure out Datakit networking in Eighth Edition. At the user level, access is organised through the ‘dkdial’ and ‘dkmgr’ routines: http://man.cat-v.org/unix_8th/3/dkmgr http://man.cat-v.org/unix_8th/3/tdkdial The IP networking is handled in the same pattern: http://man.cat-v.org/unix_8th/3/tcp http://man.cat-v.org/unix_8th/3/udp The ipc set of library routines that unify these lower level routines into a single API will only appear in 9th Edition (a year later). From efton.collins at gmail.com Wed Apr 15 16:46:21 2020 From: efton.collins at gmail.com (Efton Collins) Date: Wed, 15 Apr 2020 01:46:21 -0500 Subject: [TUHS] Bell Labs recruiter Message-ID: I was lucky enough to be in the room last year at VCF East when Ken told the story of how the move from Berkeley to Bell Labs happened. Ken's description of his interactions with the Bell recruiter was entertaining and made clear that persistent effort was needed to get him to come out to New Jersey and meet some of the people there. Does anyone know who the recruiter was? From don at DonHopkins.com Wed Apr 15 17:03:12 2020 From: don at DonHopkins.com (Don Hopkins) Date: Wed, 15 Apr 2020 09:03:12 +0200 Subject: [TUHS] =?utf-8?q?=227th_Edition_UNIX_TM=C2=80=C2=94_Summary=22_?= =?utf-8?b?PT4gIsOiwoDCnDd0aCBFZGl0aW9uIFVOSVggw6LCgMKUIFN1bW1hcnnDoiA9?= =?utf-8?b?PiDDouKCrMWTN3RoIEVkaXRpb24gVU5JWCDDouKCrOKAnSBTdW1tYXJ5w6I=?= =?utf-8?b?4oKs?= In-Reply-To: References: Message-ID: <0A51EA96-82C0-4A6E-AF30-1DFA31BD476B@gmail.com> I love how in a discussion of how difficult it was to publish a book on Unix with the correct punctuation characters 42 years ago, we still can’t even quote the title of the book in a discussion about Unix without the punctuation characters degrading and mutating each round trip. Worse truly is better! ;) -Don From dave at horsfall.org Wed Apr 15 18:19:57 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 15 Apr 2020 18:19:57 +1000 (EST) Subject: [TUHS] =?utf-8?q?=227th_Edition_UNIX_TM=C2=80=C2=94_Summary=22_?= =?utf-8?b?PT4gIsOiwoDCnDd0aCBFZGl0aW9uIFVOSVggw6LCgMKUIFN1bW1hcnnDoiA9?= =?utf-8?b?PiDDouKCrMWTN3RoIEVkaXRpb24gVU5JWCDDouKCrOKAnSBTdW1tYXJ5w6I=?= =?utf-8?b?4oKs?= In-Reply-To: <0A51EA96-82C0-4A6E-AF30-1DFA31BD476B@gmail.com> References: <0A51EA96-82C0-4A6E-AF30-1DFA31BD476B@gmail.com> Message-ID: On Wed, 15 Apr 2020, Don Hopkins wrote: > I love how in a discussion of how difficult it was to publish a book on > Unix with the correct punctuation characters 42 years ago, we still > can’t even quote the title of the book in a discussion about Unix > without the punctuation characters degrading and mutating each round > trip. Well, I'm not the one here using Windoze... -- Dave From pdagog at gmail.com Sun Apr 19 02:57:30 2020 From: pdagog at gmail.com (Pierre DAVID) Date: Sat, 18 Apr 2020 18:57:30 +0200 Subject: [TUHS] Plan 9 from outer space ? Message-ID: <20200418165730.GA20272@vagabond> There is a widespred anecdote that "Plan 9" name comes from the movie "Plan 9 From Outer Space". Since I didn't find anything more than a reference to this anecdote (see https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs for example), I forced myself to watch the movie until the end (what a pain!). Guess what? I couldn't find the link between the film and the beloved OS. I'm sure there are people here who know more. Thanks in advance for sharing your knowledge with us. Pierre From pdagog at gmail.com Sun Apr 19 03:23:37 2020 From: pdagog at gmail.com (Pierre DAVID) Date: Sat, 18 Apr 2020 19:23:37 +0200 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk> References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk> Message-ID: <20200418172337.GA22829@vagabond> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote: >> There is a widespred anecdote that "Plan 9" name comes from the >> movie "Plan 9 From Outer Space". > >Given that the full name is "Plan 9 from Bell Labs" I don't think >there's much doubt about it. > Yes, but is there anything besides the name? Pierre From imp at bsdimp.com Sun Apr 19 03:44:46 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 18 Apr 2020 11:44:46 -0600 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: <20200418172337.GA22829@vagabond> References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk> <20200418172337.GA22829@vagabond> Message-ID: On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID wrote: > On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote: > >> There is a widespred anecdote that "Plan 9" name comes from the > >> movie "Plan 9 From Outer Space". > > > >Given that the full name is "Plan 9 from Bell Labs" I don't think > >there's much doubt about it. > > > > Yes, but is there anything besides the name? > Plan 9 is the worst movie ever. And was for many years listed as the worst movie ever, including the formative years of plan 9. A professor(?) at CU once told me, though I don't know if I buy it, that plan 9 was Unix Plan B at first. There was a description that it was the worst system ever (except for all the others) in a knod to Churchill (supposedly based on his comment about Democracy). And from there it was a quick jump to Plan 9 from Bell Labs as all these themes flowed together in a mish-mash of creative naming... With a different name, it could break with Unix in interesting ways... I have no clue if this is true, and I'm no longer in contact with the professor that told me this since it was mid to late 90s, and I'm honestly having trouble recalling his name. It wasn't a 'big name' like Evi, but I think it was someone at CU I had a beer with (which means it could have been a grad student to post-doc as well, it was 25 years ago and beer was involved). It makes a great story, but I don't know if it's anything more than that. I put it out there because I know Rob or Ken is likely to correct something that's this detailed and specific if it's really wrong :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From royce at techsolvency.com Sun Apr 19 03:49:04 2020 From: royce at techsolvency.com (Royce Williams) Date: Sat, 18 Apr 2020 09:49:04 -0800 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk> <20200418172337.GA22829@vagabond> Message-ID: On Sat, Apr 18, 2020 at 9:45 AM Warner Losh wrote: > > On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID wrote: > >> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote: >> >> There is a widespred anecdote that "Plan 9" name comes from the >> >> movie "Plan 9 From Outer Space". >> > >> >Given that the full name is "Plan 9 from Bell Labs" I don't think >> >there's much doubt about it. >> > >> >> Yes, but is there anything besides the name? >> > > Plan 9 is the worst movie ever. And was for many years listed as the worst > movie ever, including the formative years of plan 9. > > A professor(?) at CU once told me, though I don't know if I buy it, that > plan 9 was Unix Plan B at first. There was a description that it was the > worst system ever (except for all the others) in a knod to Churchill > (supposedly based on his comment about Democracy). And from there it was a > quick jump to Plan 9 from Bell Labs as all these themes flowed together in > a mish-mash of creative naming... With a different name, it could break > with Unix in interesting ways... > > I have no clue if this is true, and I'm no longer in contact with the > professor that told me this since it was mid to late 90s, and I'm honestly > having trouble recalling his name. It wasn't a 'big name' like Evi, but I > think it was someone at CU I had a beer with (which means it could have > been a grad student to post-doc as well, it was 25 years ago and beer was > involved). It makes a great story, but I don't know if it's anything more > than that. I put it out there because I know Rob or Ken is likely to > correct something that's this detailed and specific if it's really wrong :) > See also: http://9p.io/wiki/plan9/lfaq/index.html#GENERAL_INFORMATION Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at inf.ed.ac.uk Sun Apr 19 03:20:18 2020 From: richard at inf.ed.ac.uk (Richard Tobin) Date: Sat, 18 Apr 2020 18:20:18 +0100 (BST) Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: Pierre DAVID's message of Sat, 18 Apr 2020 18:57:30 +0200 Message-ID: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk> > There is a widespred anecdote that "Plan 9" name comes from the > movie "Plan 9 From Outer Space". Given that the full name is "Plan 9 from Bell Labs" I don't think there's much doubt about it. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From a.phillip.garcia at gmail.com Sun Apr 19 04:40:05 2020 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sat, 18 Apr 2020 14:40:05 -0400 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: <20200418165730.GA20272@vagabond> References: <20200418165730.GA20272@vagabond> Message-ID: On Sat, Apr 18, 2020, 12:58 PM Pierre DAVID wrote: > There is a widespred anecdote that "Plan 9" name comes from the > movie "Plan 9 From Outer Space". > > Since I didn't find anything more than a reference to this > anecdote (see https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs > for example), I forced myself to watch the movie until the end > (what a pain!). > > Guess what? I couldn't find the link between the film and the > beloved OS. > > I'm sure there are people here who know more. Thanks in advance > for sharing your knowledge with us. > > Pierre > Someone posted some pictures of the office area at Murray Hill to this list. I seem to recall A plan 9 from outer space poster hanging. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Apr 19 07:38:58 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 19 Apr 2020 07:38:58 +1000 (EST) Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: <20200418165730.GA20272@vagabond> References: <20200418165730.GA20272@vagabond> Message-ID: On Sat, 18 Apr 2020, Pierre DAVID wrote: > Since I didn't find anything more than a reference to this anecdote (see > https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs for example), I > forced myself to watch the movie until the end (what a pain!). Trust me, there are even worse movies... The colourised ones, for example, out of Hollywood (aarrgghh!). (Follow-ups to COFF, of course) -- Dave, who thinks that the best films were early B&W ones From robpike at gmail.com Sun Apr 19 08:26:16 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 19 Apr 2020 08:26:16 +1000 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk> <20200418172337.GA22829@vagabond> Message-ID: As it says there, *The hermeneutics of naming yields few insights. Things are named usually because the name is nice (sam), or there is some private reference hard to decode (8½), or in honour (perhaps backhanded) of another system (mothra), or an indication of expectation (Plan 9, acme), or just because (acid). None of the names tell you anything helpful.Despite the lack of information, those who guess at reasons for naming generate volumes of apocrypha. The real reason is usually, ``because''.* -rob On Sun, Apr 19, 2020 at 3:50 AM Royce Williams wrote: > On Sat, Apr 18, 2020 at 9:45 AM Warner Losh wrote: > >> >> On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID wrote: >> >>> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote: >>> >> There is a widespred anecdote that "Plan 9" name comes from the >>> >> movie "Plan 9 From Outer Space". >>> > >>> >Given that the full name is "Plan 9 from Bell Labs" I don't think >>> >there's much doubt about it. >>> > >>> >>> Yes, but is there anything besides the name? >>> >> >> Plan 9 is the worst movie ever. And was for many years listed as the >> worst movie ever, including the formative years of plan 9. >> >> A professor(?) at CU once told me, though I don't know if I buy it, that >> plan 9 was Unix Plan B at first. There was a description that it was the >> worst system ever (except for all the others) in a knod to Churchill >> (supposedly based on his comment about Democracy). And from there it was a >> quick jump to Plan 9 from Bell Labs as all these themes flowed together in >> a mish-mash of creative naming... With a different name, it could break >> with Unix in interesting ways... >> >> I have no clue if this is true, and I'm no longer in contact with the >> professor that told me this since it was mid to late 90s, and I'm honestly >> having trouble recalling his name. It wasn't a 'big name' like Evi, but I >> think it was someone at CU I had a beer with (which means it could have >> been a grad student to post-doc as well, it was 25 years ago and beer was >> involved). It makes a great story, but I don't know if it's anything more >> than that. I put it out there because I know Rob or Ken is likely to >> correct something that's this detailed and specific if it's really wrong :) >> > > See also: > > http://9p.io/wiki/plan9/lfaq/index.html#GENERAL_INFORMATION > > Royce > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Apr 19 11:28:29 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 19 Apr 2020 11:28:29 +1000 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk> <20200418172337.GA22829@vagabond> Message-ID: It wasn't my intention. -rob On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson wrote: > > rob, > you shouldn't have shut down this discussion. > > > On Sat, Apr 18, 2020 at 3:27 PM Rob Pike wrote: >> >> As it says there, >> >> The hermeneutics of naming yields few insights. Things are named usually because the name is nice (sam), or there is some private reference hard to decode (8½), or in honour (perhaps backhanded) of another system (mothra), or an indication of expectation (Plan 9, acme), or just because (acid). None of the names tell you anything helpful. >> >> Despite the lack of information, those who guess at reasons for naming generate volumes of apocrypha. The real reason is usually, ``because''. >> >> -rob >> >> >> >> On Sun, Apr 19, 2020 at 3:50 AM Royce Williams wrote: >>> >>> On Sat, Apr 18, 2020 at 9:45 AM Warner Losh wrote: >>>> >>>> >>>> On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID wrote: >>>>> >>>>> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote: >>>>> >> There is a widespred anecdote that "Plan 9" name comes from the >>>>> >> movie "Plan 9 From Outer Space". >>>>> > >>>>> >Given that the full name is "Plan 9 from Bell Labs" I don't think >>>>> >there's much doubt about it. >>>>> > >>>>> >>>>> Yes, but is there anything besides the name? >>>> >>>> >>>> Plan 9 is the worst movie ever. And was for many years listed as the worst movie ever, including the formative years of plan 9. >>>> >>>> A professor(?) at CU once told me, though I don't know if I buy it, that plan 9 was Unix Plan B at first. There was a description that it was the worst system ever (except for all the others) in a knod to Churchill (supposedly based on his comment about Democracy). And from there it was a quick jump to Plan 9 from Bell Labs as all these themes flowed together in a mish-mash of creative naming... With a different name, it could break with Unix in interesting ways... >>>> >>>> I have no clue if this is true, and I'm no longer in contact with the professor that told me this since it was mid to late 90s, and I'm honestly having trouble recalling his name. It wasn't a 'big name' like Evi, but I think it was someone at CU I had a beer with (which means it could have been a grad student to post-doc as well, it was 25 years ago and beer was involved). It makes a great story, but I don't know if it's anything more than that. I put it out there because I know Rob or Ken is likely to correct something that's this detailed and specific if it's really wrong :) >>> >>> >>> See also: >>> >>> http://9p.io/wiki/plan9/lfaq/index.html#GENERAL_INFORMATION >>> >>> Royce From athornton at gmail.com Sun Apr 19 12:51:22 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 18 Apr 2020 19:51:22 -0700 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200418172018.AE33F2CF6BF9@macaroni.inf.ed.ac.uk> <20200418172337.GA22829@vagabond> Message-ID: <2F517789-DDA2-4475-90DD-E0D8B946ED57@gmail.com> So it could be the lack of televised sports getting to me in these shelter-in-place days, but, I mean, sure, I guess I’ll throw in some bucks for a pay-per-view of a Pike/Thompson cage match. FIGHT! Followups set. > On Apr 18, 2020, at 6:28 PM, Rob Pike wrote: > It wasn't my intention. > On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson wrote: >> >> you shouldn't have shut down this discussion. >> On Sat, Apr 18, 2020 at 3:27 PM Rob Pike wrote: >>> ``because''. From doug at cs.dartmouth.edu Sun Apr 19 13:09:46 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 18 Apr 2020 23:09:46 -0400 Subject: [TUHS] Plan 9 from outer space ? Message-ID: <202004190309.03J39knr075360@tahoe.cs.Dartmouth.EDU> I'll keep it going. rc was a startup script from very early times in Unix, shortened, as Ken was wont to do, from runcom, the nearest thing CTSS had to a shell--it could run up to six prespecified commands in background. The name runcom came to be applied to the scripts as well as to their interpreter. Doug ------------------------------------- It wasn't my intention. -rob On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson wrote: > > rob, > you shouldn't have shut down this discussion. From norman at oclsc.org Mon Apr 20 00:35:34 2020 From: norman at oclsc.org (Norman Wilson) Date: Sun, 19 Apr 2020 10:35:34 -0400 (EDT) Subject: [TUHS] Plan 9 from outer space ? Message-ID: <20200419143534.D96C94422F@lignose.oclsc.org> I asked a friend who was around at the time (I think he and Rob worked together at times). Here's what he recalls: I'll keep it going. rc was a description that it was the worst movie ever. And was for many years listed as the worst system ever (except for all the others) in a mish-mash of creative naming... I have no clue if this is true, and I'm honestly having trouble recalling his name. It wasn't my intention. There was a description that it was a startup script from very early times in Unix, shortened, as Ken was wont to do, from runcom, the nearest thing CTSS had to a shell--it could run up to six prespecified commands in background. It wasn't a 'big name' like Evi, but I don't know if I buy it, that plan 9 from outer space poster hanging. Plan 9 from Bell Labs as all these themes flowed together in a mish-mash of creative naming... With a different name, it could be the lack of information, those who guess at reasons for naming generate volumes of apocrypha. The real reason is usually, ``because''.* Trust me, there are even worse movies... Someone posted some pictures of the names tell you anything helpful. Despite the lack of televised sports getting to me in these shelter-in-place days, but, I mean, sure, I guess I'll throw in some bucks for a pay-per-view of a Pike/Thompson cage match. FIGHT! Followups set. Things are named usually because the name is "Plan 9 from outer space poster hanging. None of the office area at Murray Hill to this list. Plan 9 is the worst system ever (except for all the others) in a knod to Churchill (supposedly based on his comment about Democracy). And from there it was 25 years ago and beer was involved). It makes a great story, but I don't think there's much doubt about it. And was for many years listed as the worst movie ever, including the formative years of plan 9. Yes, but is there anything besides the name? There is a widespred anecdote that "Plan 9" name comes from the movie until the end (what a pain!). _-_-_-_-Mark Norman Wilson Toronto ON From bigato at bus142.net Mon Apr 20 01:59:22 2020 From: bigato at bus142.net (Daniel Camoles) Date: Sun, 19 Apr 2020 12:59:22 -0300 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: <20200419143534.D96C94422F@lignose.oclsc.org> References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: I’m surprised no one mentioned the Brazil movie so far, and rio named from that. I seem to remember that before being called Plan 9 it was called Brazil because of the movie. Did I dream that? > Em 19 de abr de 2020, à(s) 11:37, Norman Wilson escreveu: > > I asked a friend who was around at the time (I think he and > Rob worked together at times). Here's what he recalls: > > I'll keep it going. rc was a description that it was the worst movie > ever. And was for many years listed as the worst system ever (except > for all the others) in a mish-mash of creative naming... I have no clue > if this is true, and I'm honestly having trouble recalling his name. > It wasn't my intention. > > There was a description that it was a startup script from very early > times in Unix, shortened, as Ken was wont to do, from runcom, the nearest > thing CTSS had to a shell--it could run up to six prespecified commands > in background. It wasn't a 'big name' like Evi, but I don't know if I buy > it, that plan 9 from outer space poster hanging. Plan 9 from Bell Labs > as all these themes flowed together in a mish-mash of creative naming... > With a different name, it could be the lack of information, those who > guess at reasons for naming generate volumes of apocrypha. > > The real reason is usually, ``because''.* Trust me, there are even > worse movies... Someone posted some pictures of the names tell you > anything helpful. Despite the lack of televised sports getting to me > in these shelter-in-place days, but, I mean, sure, I guess I'll throw > in some bucks for a pay-per-view of a Pike/Thompson cage match. FIGHT! > Followups set. > > Things are named usually because the name is "Plan 9 from outer space > poster hanging. None of the office area at Murray Hill to this list. > Plan 9 is the worst system ever (except for all the others) in a > knod to Churchill (supposedly based on his comment about Democracy). > And from there it was 25 years ago and beer was involved). It makes > a great story, but I don't think there's much doubt about it. And was > for many years listed as the worst movie ever, including the formative > years of plan 9. Yes, but is there anything besides the name? There is > a widespred anecdote that "Plan 9" name comes from the movie until the > end (what a pain!). > > _-_-_-_-Mark > > Norman Wilson > Toronto ON From robpike at gmail.com Mon Apr 20 08:19:33 2020 From: robpike at gmail.com (Rob Pike) Date: Mon, 20 Apr 2020 08:19:33 +1000 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: Rio is a reference to a different movie, not to Brazil. Brazil is a reference to Brazil. Hope that helps. -rob On Mon, Apr 20, 2020 at 2:07 AM Daniel Camoles wrote: > > I’m surprised no one mentioned the Brazil movie so far, and rio named from that. I seem to remember that before being called Plan 9 it was called Brazil because of the movie. Did I dream that? > > > Em 19 de abr de 2020, à(s) 11:37, Norman Wilson escreveu: > > > > I asked a friend who was around at the time (I think he and > > Rob worked together at times). Here's what he recalls: > > > > I'll keep it going. rc was a description that it was the worst movie > > ever. And was for many years listed as the worst system ever (except > > for all the others) in a mish-mash of creative naming... I have no clue > > if this is true, and I'm honestly having trouble recalling his name. > > It wasn't my intention. > > > > There was a description that it was a startup script from very early > > times in Unix, shortened, as Ken was wont to do, from runcom, the nearest > > thing CTSS had to a shell--it could run up to six prespecified commands > > in background. It wasn't a 'big name' like Evi, but I don't know if I buy > > it, that plan 9 from outer space poster hanging. Plan 9 from Bell Labs > > as all these themes flowed together in a mish-mash of creative naming... > > With a different name, it could be the lack of information, those who > > guess at reasons for naming generate volumes of apocrypha. > > > > The real reason is usually, ``because''.* Trust me, there are even > > worse movies... Someone posted some pictures of the names tell you > > anything helpful. Despite the lack of televised sports getting to me > > in these shelter-in-place days, but, I mean, sure, I guess I'll throw > > in some bucks for a pay-per-view of a Pike/Thompson cage match. FIGHT! > > Followups set. > > > > Things are named usually because the name is "Plan 9 from outer space > > poster hanging. None of the office area at Murray Hill to this list. > > Plan 9 is the worst system ever (except for all the others) in a > > knod to Churchill (supposedly based on his comment about Democracy). > > And from there it was 25 years ago and beer was involved). It makes > > a great story, but I don't think there's much doubt about it. And was > > for many years listed as the worst movie ever, including the formative > > years of plan 9. Yes, but is there anything besides the name? There is > > a widespred anecdote that "Plan 9" name comes from the movie until the > > end (what a pain!). > > > > _-_-_-_-Mark > > > > Norman Wilson > > Toronto ON > From a.phillip.garcia at gmail.com Mon Apr 20 09:42:19 2020 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 19 Apr 2020 19:42:19 -0400 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: <20200419143534.D96C94422F@lignose.oclsc.org> References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: On Sun, Apr 19, 2020, 10:37 AM Norman Wilson wrote: > I asked a friend who was around at the time (I think he and > Rob worked together at times). Here's what he recalls: > > I'll keep it going. rc was a description that it was the worst movie > ever. And was for many years listed as the worst system ever (except > for all the others) in a mish-mash of creative naming... > > _-_-_-_-Mark Mark V Chaney! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From musher at ucsc.edu Mon Apr 20 12:27:12 2020 From: musher at ucsc.edu (Michael Usher) Date: Sun, 19 Apr 2020 19:27:12 -0700 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: I think this reflects a very static view of hermeneutics. Just because a term "meant" something at the time of its first use, doesn't mean that one should ignore all of the modification of that meaning subsequently. Language is truly a virus of a type that evolves over time as it is adjusted by its tree of hosts. I think you can separate the initial intent of a label from its current usage. I wonder what mvs would have said to that. Didn't he read sci.philosophy at one point? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Mon Apr 20 12:50:05 2020 From: robpike at gmail.com (Rob Pike) Date: Mon, 20 Apr 2020 12:50:05 +1000 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: A name that refers to something does not imply some form of metempsychosis. Sometimes a cigar is just a cigar. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Mon Apr 20 13:08:06 2020 From: ggm at algebras.org (George Michaelson) Date: Mon, 20 Apr 2020 13:08:06 +1000 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: Sometimes a cigar is just a cigar, but "ceci, n'est pas un pipe" is also true: just because you called it a cigar, doesn't mean it can't be a fish. The version I heard once, was "hitch the wagon to the engine and see what entrains" where every one of hitch, wagon, engine, entrain does not refer in any way to railways, or even "wagons" if its shakespeare. It is not very useful to try and have a conversation about anything EXCEPT the mutability of words, if you don't actually agree what the words mean in context. I think this may be why Haskell draws a distinction between things of type Integer and the specific intent behind "int" and I could be drawn to say the whole 8/16/32/64/128 problem inherent in (unsigned (long) ) int is kind-of more of a problem than not. If we'd selected IPv6 as 64 bit quantities then because at the time the 32/64 division of intent was mostly ok, we'd be good. We went to 128: GCC (sorry) doesn't handle unsigned 128 bit quantities well. A problem ensues. On Mon, Apr 20, 2020 at 12:50 PM Rob Pike wrote: > > A name that refers to something does not imply some form of metempsychosis. Sometimes a cigar is just a cigar. > > -rob > From imp at bsdimp.com Mon Apr 20 14:39:52 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 19 Apr 2020 22:39:52 -0600 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: On Sun, Apr 19, 2020, 8:50 PM Rob Pike wrote: > A name that refers to something does not imply some form of > metempsychosis. Sometimes a cigar is just a cigar. > "We named stuff for a combination of movies we were into, inside jokes and occasionally after repurposed historical names for new animals." Don't overthink it. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Apr 20 17:42:07 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Apr 2020 01:42:07 -0600 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: <202004200742.03K7g7b9018092@freefriends.org> Rob Pike wrote: > Rio is a reference to a different movie, not to Brazil. Brazil is a > reference to Brazil. Hope that helps. > > -rob What movie is Rio a reference to? Thanks, Arnold From pnr at planet.nl Mon Apr 20 23:59:58 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 20 Apr 2020 15:59:58 +0200 Subject: [TUHS] 8th Edition and /dev/stdio Message-ID: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> Whilst spelunking in the V8 source code I came across this dozen lines: http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187 It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful. As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages. Who added this neat little innovation? From arnold at skeeve.com Tue Apr 21 00:28:53 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Apr 2020 08:28:53 -0600 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> Message-ID: <202004201428.03KESrgI032002@freefriends.org> See if there are man pages for /dev/fd/XXX. IIRC /dev/stdin was a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2, and, as a really nice generalization, /dev/tty to /dev/fd/4. For the latter, init(1) simply dup'ed the opened tty file descriptor one more time before exec-ing login. HTH, Arnold Paul Ruizendaal wrote: > Whilst spelunking in the V8 source code I came across this dozen lines: > http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187 > > It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful. > > As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages. > > Who added this neat little innovation? > > From pnr at planet.nl Tue Apr 21 01:01:57 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 20 Apr 2020 17:01:57 +0200 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: <202004201428.03KESrgI032002@freefriends.org> References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> Message-ID: Thanks for that! Indeed they are on the /dev/fd man page of 8th Edition. I’m thrilled that https://unix50.org is back up and could quickly check. They are not symlinks, but character special files (with the same major/minor, of course). In the /dev/fd directory all 128 possible device entries were added. It certainly suggests that a virtual /dev directory (like /proc) would have been useful. >> Who added this neat little innovation? Googling for /dev/fd also answered my other question: http://poincare.matf.bg.ac.rs/~ivana/courses/ps/sistemi_knjige/pomocno/apue/APUE/0201433079/ch03lev1sec16.html "The /dev/fd feature was developed by Tom Duff and appeared in the 8th Edition of the Research UNIX System.” > On 20 Apr 2020, at 16:28, arnold at skeeve.com wrote: > > See if there are man pages for /dev/fd/XXX. IIRC /dev/stdin was > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2, > and, as a really nice generalization, /dev/tty to /dev/fd/4. For the > latter, init(1) simply dup'ed the opened tty file descriptor one more > time before exec-ing login. > > HTH, > > Arnold > > Paul Ruizendaal wrote: > >> Whilst spelunking in the V8 source code I came across this dozen lines: >> http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187 >> >> It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful. >> >> As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages. >> >> Who added this neat little innovation? >> >> From arnold at skeeve.com Tue Apr 21 01:16:43 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Apr 2020 09:16:43 -0600 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> Message-ID: <202004201516.03KFGhPd001645@freefriends.org> Glad to have helped. Maybe later systems did the symlink. I'm pretty sure SVR4 and later Linux did it with symlinks. SVR4 went overboard - /dev/fd was a separate file system type! Arnold Paul Ruizendaal wrote: > Thanks for that! > > Indeed they are on the /dev/fd man page of 8th Edition. > > I’m thrilled that https://unix50.org is back up and could quickly check. They are not symlinks, but character special files (with the same major/minor, of course). In the /dev/fd directory all 128 possible device entries were added. > > It certainly suggests that a virtual /dev directory (like /proc) would have been useful. > > >> Who added this neat little innovation? > > Googling for /dev/fd also answered my other question: http://poincare.matf.bg.ac.rs/~ivana/courses/ps/sistemi_knjige/pomocno/apue/APUE/0201433079/ch03lev1sec16.html > > "The /dev/fd feature was developed by Tom Duff and appeared in the 8th Edition of the Research UNIX System.” > > > > > On 20 Apr 2020, at 16:28, arnold at skeeve.com wrote: > > > > See if there are man pages for /dev/fd/XXX. IIRC /dev/stdin was > > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2, > > and, as a really nice generalization, /dev/tty to /dev/fd/4. For the > > latter, init(1) simply dup'ed the opened tty file descriptor one more > > time before exec-ing login. > > > > HTH, > > > > Arnold > > > > Paul Ruizendaal wrote: > > > >> Whilst spelunking in the V8 source code I came across this dozen lines: > >> http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187 > >> > >> It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful. > >> > >> As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages. > >> > >> Who added this neat little innovation? > >> > >> > From cbbrowne at gmail.com Tue Apr 21 03:35:58 2020 From: cbbrowne at gmail.com (Christopher Browne) Date: Mon, 20 Apr 2020 13:35:58 -0400 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: <202004200742.03K7g7b9018092@freefriends.org> References: <20200419143534.D96C94422F@lignose.oclsc.org> <202004200742.03K7g7b9018092@freefriends.org> Message-ID: On Mon, 20 Apr 2020 at 03:43, wrote: > Rob Pike wrote: > > > Rio is a reference to a different movie, not to Brazil. Brazil is a > > reference to Brazil. Hope that helps. > > > > -rob > > What movie is Rio a reference to? > I imagine there's some bad romantic comedy movie starring Michael Caine to Blame It On... Timing seems about right. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Tue Apr 21 03:58:59 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 20 Apr 2020 19:58:59 +0200 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: <202004201516.03KFGhPd001645@freefriends.org> References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> <202004201516.03KFGhPd001645@freefriends.org> Message-ID: <86CC0B00-8BDA-4896-B288-D987E2D0AB59@planet.nl> I looked through the later Editions. 9th is the same as 8th. In the 10th edition the hack is replaced by an equally small, slightly naughty, but otherwise normal device driver: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/sys/io/fd.c This approach, too, would have worked as early as 4th edition. > On Apr 20, 2020, at 5:16 PM, arnold at skeeve.com wrote: > > Glad to have helped. Maybe later systems did the symlink. I'm pretty sure SVR4 and later Linux did > it with symlinks. > > SVR4 went overboard - /dev/fd was a separate file system type! > > Arnold > > Paul Ruizendaal wrote: > >> Thanks for that! >> >> Indeed they are on the /dev/fd man page of 8th Edition. >> >> I’m thrilled that https://unix50.org is back up and could quickly check. They are not symlinks, but character special files (with the same major/minor, of course). In the /dev/fd directory all 128 possible device entries were added. >> >> It certainly suggests that a virtual /dev directory (like /proc) would have been useful. >> >>>> Who added this neat little innovation? >> >> Googling for /dev/fd also answered my other question: http://poincare.matf.bg.ac.rs/~ivana/courses/ps/sistemi_knjige/pomocno/apue/APUE/0201433079/ch03lev1sec16.html >> >> "The /dev/fd feature was developed by Tom Duff and appeared in the 8th Edition of the Research UNIX System.” >> >> >> >>> On 20 Apr 2020, at 16:28, arnold at skeeve.com wrote: >>> >>> See if there are man pages for /dev/fd/XXX. IIRC /dev/stdin was >>> a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2, >>> and, as a really nice generalization, /dev/tty to /dev/fd/4. For the >>> latter, init(1) simply dup'ed the opened tty file descriptor one more >>> time before exec-ing login. >>> >>> HTH, >>> >>> Arnold >>> >>> Paul Ruizendaal wrote: >>> >>>> Whilst spelunking in the V8 source code I came across this dozen lines: >>>> http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?ln=174,187 >>>> >>>> It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful. >>>> >>>> As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages. >>>> >>>> Who added this neat little innovation? >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Tue Apr 21 04:17:13 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Mon, 20 Apr 2020 19:17:13 +0100 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: <202004201428.03KESrgI032002@freefriends.org> References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> Message-ID: <20200420181713.GB51234@clarinet.employees.org> On Mon, Apr 20, 2020 at 08:28:53AM -0600, arnold at skeeve.com wrote: > See if there are man pages for /dev/fd/XXX. IIRC /dev/stdin was > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2, > and, as a really nice generalization, /dev/tty to /dev/fd/4. For the > latter, init(1) simply dup'ed the opened tty file descriptor one more > time before exec-ing login. So what happened to /dev/fd/3 ? DF From arnold at skeeve.com Tue Apr 21 04:32:32 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Apr 2020 12:32:32 -0600 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: <20200420181713.GB51234@clarinet.employees.org> References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> <20200420181713.GB51234@clarinet.employees.org> Message-ID: <202004201832.03KIWWeJ008975@freefriends.org> Derek Fawcus wrote: > On Mon, Apr 20, 2020 at 08:28:53AM -0600, arnold at skeeve.com wrote: > > See if there are man pages for /dev/fd/XXX. IIRC /dev/stdin was > > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to /dev/fd/2, > > and, as a really nice generalization, /dev/tty to /dev/fd/4. For the > > latter, init(1) simply dup'ed the opened tty file descriptor one more > > time before exec-ing login. > > So what happened to /dev/fd/3 ? > > DF My bad. I meant /dev/fd/3. What was cute was that /dev/tty was no longer a special device of it's own, but just another inherited open file descriptor. Sadly, that generalization never made it out into other *nix systems. Arnold From robpike at gmail.com Tue Apr 21 06:49:04 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 21 Apr 2020 06:49:04 +1000 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> <202004200742.03K7g7b9018092@freefriends.org> Message-ID: No, that's not it. You have the wrong actor. The right one appears in the rio source. -rob On Tue, Apr 21, 2020 at 3:37 AM Christopher Browne wrote: > > > On Mon, 20 Apr 2020 at 03:43, wrote: > >> Rob Pike wrote: >> >> > Rio is a reference to a different movie, not to Brazil. Brazil is a >> > reference to Brazil. Hope that helps. >> > >> > -rob >> >> What movie is Rio a reference to? >> > > I imagine there's some bad romantic comedy movie starring Michael Caine to > Blame It On... > > Timing seems about right. > -- > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Apr 22 10:50:31 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Apr 2020 18:50:31 -0600 Subject: [TUHS] Usenix tapes Message-ID: So in the archives we have tapes from 1977, 1980-83 and 1987-89. So I thought I'd ask if there's other tapes that aren't in the archive... google can't even find the tapes we have in our archive, let alone others... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Apr 22 11:48:11 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Apr 2020 19:48:11 -0600 Subject: [TUHS] Usenix tapes In-Reply-To: References: Message-ID: On Tue, Apr 21, 2020, 7:37 PM Jeremy C. Reed wrote: > On Tue, 21 Apr 2020, Warner Losh wrote: > > > So in the archives we have tapes from 1977, 1980-83 and 1987-89. > > So I thought I'd ask if there's other tapes that aren't in the > archive...? > > google can't even find the tapes we have in our archive, let alone > others... > > Hi Warner, > > I will list my tar files since may have different years than you list > above. I think all this is at the TUHs archives. > > 2710098 ug091377.tar.gz Sep 1977: > Aviation Research Laboratory, Harvard/Unix, circle (Chicago?), > Explor (Bell?), Queen Mary College, Nymegen Univ (nijmegen), UCSD, > Brooklyn College of CUNY, cooper, ... > This is in the archives. I just got done browsing it. Did developers at Bell submit directly to share on these tapes? Or was > it via third-party? (Lots of Bell code on there.) > > 1273420 uk1.tar.gz Jan 1978: > Queen Mary College, University of Kent at Canterbury, and University of > Glasgow > > 2739630 tor79.tar.gz 1979 > University of New South Wales; U.S. Air FOrce Data Services Centre; > Berkeley/VAX; Case Western Reserve; Department of Defence, Ft George. D. > Mumaugh; Duke University; Graphic Management Systems; Johns Hopkins > Univ.; Johns Hopkins Applied Physics Lab.; University of Minnesota; > Engineering Computer Network, Univ of Oklahoma; Plastic Optics Inc.; > Rochester Institue of Technology; Vrije University. Pascal. > > 1823101 purdue.tar.gz 1979 > School of Electrical Engineering, Purdue University > These might be. Maybe not. 10443465 del.tar.gz 1980 plus Boulder 1980 and Toronto June 1979 (but > many differences) > > 8945578 usenix_80_delaware.tar.gz > > 1848640 usenix_81.tar.gz > > 829661 usenix83.tar.gz > > 28719717 usenix878889.tar.gz These are. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Wed Apr 22 11:37:30 2020 From: reed at reedmedia.net (Jeremy C. Reed) Date: Tue, 21 Apr 2020 20:37:30 -0500 (CDT) Subject: [TUHS] Usenix tapes In-Reply-To: References: Message-ID: On Tue, 21 Apr 2020, Warner Losh wrote: > So in the archives we have tapes from 1977, 1980-83 and 1987-89. > So I thought I'd ask if there's other tapes that aren't in the archive...? > google can't even find the tapes we have in our archive, let alone others... Hi Warner, I will list my tar files since may have different years than you list above. I think all this is at the TUHs archives. 2710098 ug091377.tar.gz Sep 1977: Aviation Research Laboratory, Harvard/Unix, circle (Chicago?), Explor (Bell?), Queen Mary College, Nymegen Univ (nijmegen), UCSD, Brooklyn College of CUNY, cooper, ... Did developers at Bell submit directly to share on these tapes? Or was it via third-party? (Lots of Bell code on there.) 1273420 uk1.tar.gz Jan 1978: Queen Mary College, University of Kent at Canterbury, and University of Glasgow 2739630 tor79.tar.gz 1979 University of New South Wales; U.S. Air FOrce Data Services Centre; Berkeley/VAX; Case Western Reserve; Department of Defence, Ft George. D. Mumaugh; Duke University; Graphic Management Systems; Johns Hopkins Univ.; Johns Hopkins Applied Physics Lab.; University of Minnesota; Engineering Computer Network, Univ of Oklahoma; Plastic Optics Inc.; Rochester Institue of Technology; Vrije University. Pascal. 1823101 purdue.tar.gz 1979 School of Electrical Engineering, Purdue University 10443465 del.tar.gz 1980 plus Boulder 1980 and Toronto June 1979 (but many differences) 8945578 usenix_80_delaware.tar.gz 1848640 usenix_81.tar.gz 829661 usenix83.tar.gz 28719717 usenix878889.tar.gz From robpike at gmail.com Wed Apr 22 19:21:09 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 22 Apr 2020 19:21:09 +1000 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: <202004201832.03KIWWeJ008975@freefriends.org> References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> <20200420181713.GB51234@clarinet.employees.org> <202004201832.03KIWWeJ008975@freefriends.org> Message-ID: I think dmr put them in, at my suggestion. I was bothered by the inconsistent use of '-' as a name for standard input. Giving stdin a real name meant we had a consistent mechanism. 8th edition sounds right. -rob On Tue, Apr 21, 2020 at 4:33 AM wrote: > Derek Fawcus wrote: > > > On Mon, Apr 20, 2020 at 08:28:53AM -0600, arnold at skeeve.com wrote: > > > See if there are man pages for /dev/fd/XXX. IIRC /dev/stdin was > > > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to > /dev/fd/2, > > > and, as a really nice generalization, /dev/tty to /dev/fd/4. For the > > > latter, init(1) simply dup'ed the opened tty file descriptor one more > > > time before exec-ing login. > > > > So what happened to /dev/fd/3 ? > > > > DF > > My bad. I meant /dev/fd/3. What was cute was that /dev/tty was > no longer a special device of it's own, but just another inherited > open file descriptor. > > Sadly, that generalization never made it out into other *nix systems. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Apr 22 19:33:32 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 22 Apr 2020 03:33:32 -0600 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> <20200420181713.GB51234@clarinet.employees.org> <202004201832.03KIWWeJ008975@freefriends.org> Message-ID: <202004220933.03M9XWk2002533@freefriends.org> Other mail in the thread credits Tom Duff with /dev/fd ... In any case, /dev/stdin et al was a great idea. Kudos. Arnold Rob Pike wrote: > I think dmr put them in, at my suggestion. I was bothered by the > inconsistent use of '-' as a name for standard input. Giving stdin a real > name meant we had a consistent mechanism. > > 8th edition sounds right. > > -rob > > > On Tue, Apr 21, 2020 at 4:33 AM wrote: > > > Derek Fawcus wrote: > > > > > On Mon, Apr 20, 2020 at 08:28:53AM -0600, arnold at skeeve.com wrote: > > > > See if there are man pages for /dev/fd/XXX. IIRC /dev/stdin was > > > > a symlink to /dev/fd/0, /dev/stdout to /dev/fd/1, /dev/stderr to > > /dev/fd/2, > > > > and, as a really nice generalization, /dev/tty to /dev/fd/4. For the > > > > latter, init(1) simply dup'ed the opened tty file descriptor one more > > > > time before exec-ing login. > > > > > > So what happened to /dev/fd/3 ? > > > > > > DF > > > > My bad. I meant /dev/fd/3. What was cute was that /dev/tty was > > no longer a special device of it's own, but just another inherited > > open file descriptor. > > > > Sadly, that generalization never made it out into other *nix systems. > > > > Arnold > > From usotsuki at buric.co Wed Apr 22 19:35:42 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 22 Apr 2020 05:35:42 -0400 (EDT) Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: <202004220933.03M9XWk2002533@freefriends.org> References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> <20200420181713.GB51234@clarinet.employees.org> <202004201832.03KIWWeJ008975@freefriends.org> <202004220933.03M9XWk2002533@freefriends.org> Message-ID: On Wed, 22 Apr 2020, arnold at skeeve.com wrote: > Other mail in the thread credits Tom Duff with /dev/fd ... In any case, > /dev/stdin et al was a great idea. I make *heavy* use of /dev/stdin and /dev/stdout on Linux. Very useful concept. -uso. From robpike at gmail.com Wed Apr 22 19:41:36 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 22 Apr 2020 19:41:36 +1000 Subject: [TUHS] 8th Edition and /dev/stdio In-Reply-To: References: <46EFF8FB-86D2-407A-87A7-B7A58D47C2D9@planet.nl> <202004201428.03KESrgI032002@freefriends.org> <20200420181713.GB51234@clarinet.employees.org> <202004201832.03KIWWeJ008975@freefriends.org> <202004220933.03M9XWk2002533@freefriends.org> Message-ID: Not certain, but it's possible /dev/stdin went in first, and /dev/fd/* generalized it. -rob On Wed, Apr 22, 2020 at 7:35 PM Steve Nickolas wrote: > On Wed, 22 Apr 2020, arnold at skeeve.com wrote: > > > Other mail in the thread credits Tom Duff with /dev/fd ... In any case, > > /dev/stdin et al was a great idea. > > I make *heavy* use of /dev/stdin and /dev/stdout on Linux. Very useful > concept. > > -uso. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Apr 23 07:53:45 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Apr 2020 15:53:45 -0600 Subject: [TUHS] Off Topic: Unix Kermit 4x software archeology Message-ID: Greetings, So this happened: https://bsdimp.blogspot.com/2020/04/finding-kermit-4x.html tl;dr: while obsessing over 4C(052) kermit that's in Rainbow Venix, I found a lot of cool "lost" source code versions of Kermit... All except the one I was looking for. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Apr 23 23:48:55 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 23 Apr 2020 15:48:55 +0200 Subject: [TUHS] V3 pipes Message-ID: <57D2AE85-21DB-4D8F-8211-8ED7C1E60421@planet.nl> Was looking into pipes. For the 3rd Edition TUHS does not have source, but is does have a man page. In V3, pipe returns a single file descriptor that echoes whatever is written back upon reading. The pipe buffer capacity is 504 bytes. The surviving ‘nsys’ source for V4 does not yet include the source for pipes, but the man page for 4th edition pipes has - more or less - the well known semantics, including the 4096 byte buffer capacity. Does anyone remember: - why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. Maybe the reason was that it becomes harder to detect broken pipes? - whether the V3 implementation was based on an in-memory approach and not the later 'anonymous backing file’? The 504 byte buffer capacity suggests a single buffer page minus some header info. From elbingmiss at gmail.com Fri Apr 24 01:33:24 2020 From: elbingmiss at gmail.com (=?UTF-8?Q?=C3=81lvaro_Jurado?=) Date: Thu, 23 Apr 2020 17:33:24 +0200 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> <202004200742.03K7g7b9018092@freefriends.org> Message-ID: :-D /* * WASHINGTON (AP) - The Food and Drug Administration warned * consumers Wednesday not to use ``Rio'' hair relaxer products * because they may cause severe hair loss or turn hair green.... * The FDA urged consumers who have experienced problems with Rio * to notify their local FDA office, local health department or the * company at 1‑800‑543‑3002. */ sys/src/cmd/rio/rio.c https://en.m.wikipedia.org/wiki/Rio_Hair_Naturalizer_System On Mon, 20 Apr 2020 at 22:50, Rob Pike wrote: > No, that's not it. You have the wrong actor. The right one appears in the > rio source. > > -rob > > > On Tue, Apr 21, 2020 at 3:37 AM Christopher Browne > wrote: > >> >> >> On Mon, 20 Apr 2020 at 03:43, wrote: >> >>> Rob Pike wrote: >>> >>> > Rio is a reference to a different movie, not to Brazil. Brazil is a >>> > reference to Brazil. Hope that helps. >>> > >>> > -rob >>> >>> What movie is Rio a reference to? >>> >> >> I imagine there's some bad romantic comedy movie starring Michael Caine >> to Blame It On... >> >> Timing seems about right. >> -- >> When confronted by a difficult problem, solve it by reducing it to the >> question, "How would the Lone Ranger handle this?" >> > -- Álvaro -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Fri Apr 24 03:10:57 2020 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 23 Apr 2020 13:10:57 -0400 Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> <202004200742.03K7g7b9018092@freefriends.org> Message-ID: Rio the movie: https://en.wikipedia.org/wiki/Rio_(2011_film) -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Fri Apr 24 22:54:39 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 24 Apr 2020 08:54:39 -0400 Subject: [TUHS] v3 pipes Message-ID: <202004241254.03OCsd9m066621@tahoe.cs.Dartmouth.EDU> > why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. My understanding is that the single file descriptor broke the open-file model, which had a single read/write pointer. Two-way communication via Doug From dave at horsfall.org Sat Apr 25 06:55:24 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 25 Apr 2020 06:55:24 +1000 (EST) Subject: [TUHS] Plan 9 from outer space ? In-Reply-To: References: <20200419143534.D96C94422F@lignose.oclsc.org> Message-ID: [ Catching up on old email ] On Sun, 19 Apr 2020, A. P. Garcia wrote: > Mark V Chaney! Shaney. I know the culprit(s) behind it... -- Dave From athornton at gmail.com Sat Apr 25 11:59:00 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 24 Apr 2020 18:59:00 -0700 Subject: [TUHS] v7 K&R C Message-ID: The C in v7 is, canonically, the language described in K&R, right? I must be doing something dumb. I am getting Webb Miller’s “s” editor built there, and I am down to one function. /* chop_arg - chop a function's argument to a maximum length */ static chop_arg(fcn, arg, maxlen) int (*fcn)(); int maxlen; char *arg; { char save; save = arg[maxlen]; arg[maxlen] = '\0'; fcn(arg); arg[maxlen] = save; } This doesn’t like the function pointer. $ cc -c choparg.c choparg.c:11: Call of non-function So, uh, what is the obvious thing I am missing? How am I supposed to be passing function pointers in the C compiler that comes with v7? Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.unix.pro at gmail.com Sat Apr 25 12:37:57 2020 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Fri, 24 Apr 2020 19:37:57 -0700 Subject: [TUHS] v7 K&R C In-Reply-To: References: Message-ID: On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton wrote: > This doesn’t like the function pointer. > > $ cc -c choparg.c > choparg.c:11: Call of non-function > > Perhaps: (*fcn)(arg); -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Apr 25 12:47:50 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 24 Apr 2020 19:47:50 -0700 Subject: [TUHS] v7 K&R C In-Reply-To: References: Message-ID: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> > On Apr 24, 2020, at 7:37 PM, Charles Anthony wrote: > > > > On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton > wrote: > This doesn’t like the function pointer. > > $ cc -c choparg.c > choparg.c:11: Call of non-function > > Perhaps: > > (*fcn)(arg); > We have a winner! Also, Kartik, dunno where it is on the net, but if you install a v7 system, /usr/src/cmd/c Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Apr 25 12:50:24 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 24 Apr 2020 19:50:24 -0700 Subject: [TUHS] v7 K&R C In-Reply-To: References: Message-ID: <8329FD62-3822-4572-B66E-137FE4F7CFD9@gmail.com> Getting closer! $ cc -c s *.o $ ./s Makefile ./s: cannot execute $ ls -l s -rw-rw-r-- 1 dmr 61644 Apr 23 11:06 s $ chmod +x s $ ./s usage: s file $ ./s Makefile Memory fault - core dumped -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sat Apr 25 12:51:31 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 25 Apr 2020 12:51:31 +1000 Subject: [TUHS] v7 K&R C In-Reply-To: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> Message-ID: The ability to call a function pointer fp with the syntax fp() rather than (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty sure it was not in v7 C, as you observe. Convenient though the shorthand may be, it always bothered me as inconsistent and misleading. (I am pretty sure I used it sometimes regardless.) -rob On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton wrote: > > > On Apr 24, 2020, at 7:37 PM, Charles Anthony > wrote: > > > > On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton wrote: > >> This doesn’t like the function pointer. >> > >> $ cc -c choparg.c >> choparg.c:11: Call of non-function >> >> Perhaps: > > (*fcn)(arg); > > > We have a winner! > > Also, Kartik, dunno where it is on the net, but if you install a v7 > system, /usr/src/cmd/c > > Adam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sat Apr 25 12:54:27 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 25 Apr 2020 12:54:27 +1000 Subject: [TUHS] v7 K&R C In-Reply-To: References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> Message-ID: Another debate at the time was caused by a disagreement between pcc and cc regarding enums: are they a type or just a way to declare constant? I remember getting annoyed by pcc not letting me declare a constant with an enum and use it as an int. I protested to scj and dmr and after some to-ing and fro-ing Steve changed pcc to treat them as constants. Not sure it was the right decision, but C desperately wanted a non-macro way to define a constant. I'd probably argue the same way today. The real lesson is how propinquity affects progress. -rbo On Sat, Apr 25, 2020 at 12:51 PM Rob Pike wrote: > The ability to call a function pointer fp with the syntax fp() rather than > (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty > sure it was not in v7 C, as you observe. > > Convenient though the shorthand may be, it always bothered me as > inconsistent and misleading. (I am pretty sure I used it sometimes > regardless.) > > -rob > > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton > wrote: > >> >> >> On Apr 24, 2020, at 7:37 PM, Charles Anthony >> wrote: >> >> >> >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton >> wrote: >> >>> This doesn’t like the function pointer. >>> >> >>> $ cc -c choparg.c >>> choparg.c:11: Call of non-function >>> >>> Perhaps: >> >> (*fcn)(arg); >> >> >> We have a winner! >> >> Also, Kartik, dunno where it is on the net, but if you install a v7 >> system, /usr/src/cmd/c >> >> Adam >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Apr 25 13:04:36 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 24 Apr 2020 20:04:36 -0700 Subject: [TUHS] v7 K&R C In-Reply-To: References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> Message-ID: <20200425030436.GF30547@mcvoy.com> I hate enums. I thought they would be type checked and they are just ints. I love C but enums suck. On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote: > Another debate at the time was caused by a disagreement between pcc and cc > regarding enums: are they a type or just a way to declare constant? I > remember getting annoyed by pcc not letting me declare a constant with an > enum and use it as an int. I protested to scj and dmr and after some to-ing > and fro-ing Steve changed pcc to treat them as constants. > > Not sure it was the right decision, but C desperately wanted a non-macro > way to define a constant. I'd probably argue the same way today. The real > lesson is how propinquity affects progress. > > -rbo > > > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike wrote: > > > The ability to call a function pointer fp with the syntax fp() rather than > > (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty > > sure it was not in v7 C, as you observe. > > > > Convenient though the shorthand may be, it always bothered me as > > inconsistent and misleading. (I am pretty sure I used it sometimes > > regardless.) > > > > -rob > > > > > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton > > wrote: > > > >> > >> > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony > >> wrote: > >> > >> > >> > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton > >> wrote: > >> > >>> This doesn???t like the function pointer. > >>> > >> > >>> $ cc -c choparg.c > >>> choparg.c:11: Call of non-function > >>> > >>> Perhaps: > >> > >> (*fcn)(arg); > >> > >> > >> We have a winner! > >> > >> Also, Kartik, dunno where it is on the net, but if you install a v7 > >> system, /usr/src/cmd/c > >> > >> Adam > >> > >> -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Sat Apr 25 13:30:26 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 24 Apr 2020 23:30:26 -0400 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425030436.GF30547@mcvoy.com> References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> <20200425030436.GF30547@mcvoy.com> Message-ID: Amen bro. I always felt that they got added because pascal had something that C didn’t, and yet it really was not the same. I always felt they were a feature that was only partly implemented and if they were not going to be fully typed then just leave them out and use cpp like we had always done before. On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy wrote: > I hate enums. I thought they would be type checked and they are just ints. > I love C but enums suck. > > On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote: > > Another debate at the time was caused by a disagreement between pcc and > cc > > regarding enums: are they a type or just a way to declare constant? I > > remember getting annoyed by pcc not letting me declare a constant with an > > enum and use it as an int. I protested to scj and dmr and after some > to-ing > > and fro-ing Steve changed pcc to treat them as constants. > > > > Not sure it was the right decision, but C desperately wanted a non-macro > > way to define a constant. I'd probably argue the same way today. The real > > lesson is how propinquity affects progress. > > > > -rbo > > > > > > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike wrote: > > > > > The ability to call a function pointer fp with the syntax fp() rather > than > > > (*fp)() came rather late, I think at Bjarne's suggestion or example. > Pretty > > > sure it was not in v7 C, as you observe. > > > > > > Convenient though the shorthand may be, it always bothered me as > > > inconsistent and misleading. (I am pretty sure I used it sometimes > > > regardless.) > > > > > > -rob > > > > > > > > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton > > > wrote: > > > > > >> > > >> > > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony < > charles.unix.pro at gmail.com> > > >> wrote: > > >> > > >> > > >> > > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton > > >> wrote: > > >> > > >>> This doesn???t like the function pointer. > > >>> > > >> > > >>> $ cc -c choparg.c > > >>> choparg.c:11: Call of non-function > > >>> > > >>> Perhaps: > > >> > > >> (*fcn)(arg); > > >> > > >> > > >> We have a winner! > > >> > > >> Also, Kartik, dunno where it is on the net, but if you install a v7 > > >> system, /usr/src/cmd/c > > >> > > >> Adam > > >> > > >> > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Apr 25 13:37:24 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 25 Apr 2020 13:37:24 +1000 (EST) Subject: [TUHS] v7 K&R C In-Reply-To: References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> Message-ID: On Sat, 25 Apr 2020, Rob Pike wrote: > The ability to call a function pointer fp with the syntax fp() rather > than (*fp)() came rather late, I think at Bjarne's suggestion or > example. Pretty sure it was not in v7 C, as you observe. I have never seen that syntax used (and I've been tooling around with Unix for decades). The variable "fp" in an argument list is a pointer to the function, not the function itself, so dereference it. I wouldn't put it past Stroustrup to have it in C++ though, as it pretty much has everything else in it. > Convenient though the shorthand may be, it always bothered me as > inconsistent and misleading. (I am pretty sure I used it sometimes > regardless.) Indeed... My principle is to write code as though the next person to maintain it is a psychopathic axe-murderer who knows where you live (or perhaps even yourself, a year later)... -- Dave From lm at mcvoy.com Sat Apr 25 13:43:07 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 24 Apr 2020 20:43:07 -0700 Subject: [TUHS] v7 K&R C In-Reply-To: References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> <20200425030436.GF30547@mcvoy.com> Message-ID: <20200425034307.GG30547@mcvoy.com> What Clem said, that is precisely how I feel. I'd be fully for them if they fully type checked but without that, yeah, cpp is fine, enums are just a distraction. On Fri, Apr 24, 2020 at 11:30:26PM -0400, Clem Cole wrote: > Amen bro. I always felt that they got added because pascal had something > that C didn???t, and yet it really was not the same. I always felt they were > a feature that was only partly implemented and if they were not going to > be fully typed then just leave them out and use cpp like we had always done > before. > > On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy wrote: > > > I hate enums. I thought they would be type checked and they are just ints. > > I love C but enums suck. > > > > On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote: > > > Another debate at the time was caused by a disagreement between pcc and > > cc > > > regarding enums: are they a type or just a way to declare constant? I > > > remember getting annoyed by pcc not letting me declare a constant with an > > > enum and use it as an int. I protested to scj and dmr and after some > > to-ing > > > and fro-ing Steve changed pcc to treat them as constants. > > > > > > Not sure it was the right decision, but C desperately wanted a non-macro > > > way to define a constant. I'd probably argue the same way today. The real > > > lesson is how propinquity affects progress. > > > > > > -rbo > > > > > > > > > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike wrote: > > > > > > > The ability to call a function pointer fp with the syntax fp() rather > > than > > > > (*fp)() came rather late, I think at Bjarne's suggestion or example. > > Pretty > > > > sure it was not in v7 C, as you observe. > > > > > > > > Convenient though the shorthand may be, it always bothered me as > > > > inconsistent and misleading. (I am pretty sure I used it sometimes > > > > regardless.) > > > > > > > > -rob > > > > > > > > > > > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton > > > > wrote: > > > > > > > >> > > > >> > > > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony < > > charles.unix.pro at gmail.com> > > > >> wrote: > > > >> > > > >> > > > >> > > > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton > > > >> wrote: > > > >> > > > >>> This doesn???t like the function pointer. > > > >>> > > > >> > > > >>> $ cc -c choparg.c > > > >>> choparg.c:11: Call of non-function > > > >>> > > > >>> Perhaps: > > > >> > > > >> (*fcn)(arg); > > > >> > > > >> > > > >> We have a winner! > > > >> > > > >> Also, Kartik, dunno where it is on the net, but if you install a v7 > > > >> system, /usr/src/cmd/c > > > >> > > > >> Adam > > > >> > > > >> > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > > -- > Sent from a handheld expect more typos than usual -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jon at fourwinds.com Sat Apr 25 13:54:14 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 24 Apr 2020 20:54:14 -0700 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425034307.GG30547@mcvoy.com> References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> <20200425030436.GF30547@mcvoy.com> <20200425034307.GG30547@mcvoy.com> Message-ID: <202004250354.03P3sFJe2522940@darkstar.fourwinds.com> Larry McVoy writes: > What Clem said, that is precisely how I feel. I'd be fully for them if they > fully type checked but without that, yeah, cpp is fine, enums are just a > distraction. Enums are implemented badly, but it's possible to do even worse. This is from linux /usr/include/sys/mount.h - can anyone explain the point of it to me? enum { MS_RDONLY = 1, /* Mount read-only. */ #define MS_RDONLY MS_RDONLY MS_NOSUID = 2, /* Ignore suid and sgid bits. */ #define MS_NOSUID MS_NOSUID MS_NODEV = 4, /* Disallow access to device special files. */ #define MS_NODEV MS_NODEV MS_NOEXEC = 8, /* Disallow program execution. */ #define MS_NOEXEC MS_NOEXEC MS_SYNCHRONOUS = 16, /* Writes are synced at once. */ #define MS_SYNCHRONOUS MS_SYNCHRONOUS MS_REMOUNT = 32, /* Alter flags of a mounted FS. */ #define MS_REMOUNT MS_REMOUNT MS_MANDLOCK = 64, /* Allow mandatory locks on an FS. */ #define MS_MANDLOCK MS_MANDLOCK MS_DIRSYNC = 128, /* Directory modifications are synchronous. */ #define MS_DIRSYNC MS_DIRSYNC MS_NOATIME = 1024, /* Do not update access times. */ #define MS_NOATIME MS_NOATIME MS_NODIRATIME = 2048, /* Do not update directory access times. */ #define MS_NODIRATIME MS_NODIRATIME MS_BIND = 4096, /* Bind directory at different place. */ #define MS_BIND MS_BIND MS_MOVE = 8192, #define MS_MOVE MS_MOVE MS_REC = 16384, #define MS_REC MS_REC MS_SILENT = 32768, #define MS_SILENT MS_SILENT MS_POSIXACL = 1 << 16, /* VFS does not apply the umask. */ #define MS_POSIXACL MS_POSIXACL MS_UNBINDABLE = 1 << 17, /* Change to unbindable. */ #define MS_UNBINDABLE MS_UNBINDABLE MS_PRIVATE = 1 << 18, /* Change to private. */ #define MS_PRIVATE MS_PRIVATE MS_SLAVE = 1 << 19, /* Change to slave. */ #define MS_SLAVE MS_SLAVE MS_SHARED = 1 << 20, /* Change to shared. */ #define MS_SHARED MS_SHARED MS_RELATIME = 1 << 21, /* Update atime relative to mtime/ctime. */ #define MS_RELATIME MS_RELATIME MS_KERNMOUNT = 1 << 22, /* This is a kern_mount call. */ #define MS_KERNMOUNT MS_KERNMOUNT MS_I_VERSION = 1 << 23, /* Update inode I_version field. */ #define MS_I_VERSION MS_I_VERSION MS_STRICTATIME = 1 << 24, /* Always perform atime updates. */ #define MS_STRICTATIME MS_STRICTATIME MS_LAZYTIME = 1 << 25, /* Update the on-disk [acm]times lazily. */ #define MS_LAZYTIME MS_LAZYTIME MS_ACTIVE = 1 << 30, #define MS_ACTIVE MS_ACTIVE MS_NOUSER = 1 << 31 #define MS_NOUSER MS_NOUSER }; From lars at nocrew.org Sat Apr 25 15:59:19 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 25 Apr 2020 05:59:19 +0000 Subject: [TUHS] v7 K&R C In-Reply-To: <8329FD62-3822-4572-B66E-137FE4F7CFD9@gmail.com> (Adam Thornton's message of "Fri, 24 Apr 2020 19:50:24 -0700") References: <8329FD62-3822-4572-B66E-137FE4F7CFD9@gmail.com> Message-ID: <7wtv18p0lk.fsf@junk.nocrew.org> Adam Thornton wrote: > Getting closer! > > $ cc -c s *.o > $ ./s Makefile > ./s: cannot execute -c says to make an object file, right? Try -o instead. From pnr at planet.nl Sat Apr 25 21:14:15 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 25 Apr 2020 13:14:15 +0200 Subject: [TUHS] v3 pipes Message-ID: <430B2F35-D250-499E-83F9-58D4C1764CE0@planet.nl> >> why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. > My understanding is that the single file descriptor broke the open-file > model, which had a single read/write pointer. Two-way communication via I’m not sure I understand. In the implementation, the read pointer is file location offset (“fp->f_offset”) and the write pointer is the file size (“ip->i_size”). The location offset on the writing end of the pipe is always zero, and on the reading end it moves between zero and PIPSIZ (but that is unobservable). I just tried making both pipe ends readable+writeable in my “V6.5” kernel and that appears to work. It allows for bi-directional communication in a half-duplex sense (i.e communicating walky-talky style). The other benefit is using just one file descriptor, at a time when a process had just 15 to work with. Maybe the issue was that two sides writing to a full pipe at the same time will cause deadlock? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Sat Apr 25 21:44:23 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 25 Apr 2020 11:44:23 +0000 Subject: [TUHS] v7 K&R C In-Reply-To: <202004250354.03P3sFJe2522940@darkstar.fourwinds.com> References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> <20200425030436.GF30547@mcvoy.com> <20200425034307.GG30547@mcvoy.com> <202004250354.03P3sFJe2522940@darkstar.fourwinds.com> Message-ID: On 24 Apr 2020 20:54 -0700, from jon at fourwinds.com (Jon Steinhart): > Enums are implemented badly, but it's possible to do even worse. This is from > linux /usr/include/sys/mount.h - can anyone explain the point of it to me? > > enum > { > MS_RDONLY = 1, /* Mount read-only. */ > #define MS_RDONLY MS_RDONLY > MS_NOSUID = 2, /* Ignore suid and sgid bits. */ > #define MS_NOSUID MS_NOSUID If you mean the #defining to itself, check out the discussion starting at . If you have the archive locally, that's Message-ID <201911131802.xADI2fxE752068 at darkstar.fourwinds.com> from 13 Nov 2019 10:02 -0800 / 18:02 UTC. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From jnc at mercury.lcs.mit.edu Sat Apr 25 23:11:12 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 25 Apr 2020 09:11:12 -0400 (EDT) Subject: [TUHS] v7 K&R C Message-ID: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> > From: Rob Pike > Convenient though the shorthand may be, it always bothered me as > inconsistent and misleading. As someone who made very extensive use of procedure pointers (most notably in upcalls, which never caught on, alas), I couldn't agree more. Two very different things are happenging, but with the shorthand notation, they share an identical representation. And for what? To save three characters? Noel From robpike at gmail.com Sat Apr 25 23:18:02 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 25 Apr 2020 23:18:02 +1000 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> Message-ID: To make chaining of calls simpler. Write f()->g()->h()->i() the other way and you'll see why Bjarne asked for the shorthand. -rob On Sat, Apr 25, 2020 at 11:12 PM Noel Chiappa wrote: > > From: Rob Pike > > > Convenient though the shorthand may be, it always bothered me as > > inconsistent and misleading. > > As someone who made very extensive use of procedure pointers (most notably > in > upcalls, which never caught on, alas), I couldn't agree more. > > Two very different things are happenging, but with the shorthand notation, > they share an identical representation. And for what? To save three > characters? > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Apr 25 23:17:55 2020 From: crossd at gmail.com (Dan Cross) Date: Sat, 25 Apr 2020 09:17:55 -0400 Subject: [TUHS] v7 K&R C In-Reply-To: References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> <20200425030436.GF30547@mcvoy.com> Message-ID: On Fri, Apr 24, 2020 at 11:31 PM Clem Cole wrote: > Amen bro. I always felt that they got added because pascal had something > that C didn’t, and yet it really was not the same. I always felt they were > a feature that was only partly implemented and if they were not going to > be fully typed then just leave them out and use cpp like we had always done > before. > Aww shucks; I actually kinda like enums. When creating sequentially numbered constants, they're convenient. That said, the typing issues I have a lot of sympathy for. For true constants, it's a shame that `const` didn't make it in earlier, though we have it now. Abusing enum to define constants certainly feels like, well, abuse. - Dan C. On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy wrote: > >> I hate enums. I thought they would be type checked and they are just >> ints. >> I love C but enums suck. >> >> On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote: >> > Another debate at the time was caused by a disagreement between pcc and >> cc >> > regarding enums: are they a type or just a way to declare constant? I >> > remember getting annoyed by pcc not letting me declare a constant with >> an >> > enum and use it as an int. I protested to scj and dmr and after some >> to-ing >> > and fro-ing Steve changed pcc to treat them as constants. >> > >> > Not sure it was the right decision, but C desperately wanted a non-macro >> > way to define a constant. I'd probably argue the same way today. The >> real >> > lesson is how propinquity affects progress. >> > >> > -rbo >> > >> > >> > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike wrote: >> > >> > > The ability to call a function pointer fp with the syntax fp() rather >> than >> > > (*fp)() came rather late, I think at Bjarne's suggestion or example. >> Pretty >> > > sure it was not in v7 C, as you observe. >> > > >> > > Convenient though the shorthand may be, it always bothered me as >> > > inconsistent and misleading. (I am pretty sure I used it sometimes >> > > regardless.) >> > > >> > > -rob >> > > >> > > >> > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton >> > > wrote: >> > > >> > >> >> > >> >> > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony < >> charles.unix.pro at gmail.com> >> > >> wrote: >> > >> >> > >> >> > >> >> > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton >> > >> wrote: >> > >> >> > >>> This doesn???t like the function pointer. >> > >>> >> > >> >> > >>> $ cc -c choparg.c >> > >>> choparg.c:11: Call of non-function >> > >>> >> > >>> Perhaps: >> > >> >> > >> (*fcn)(arg); >> > >> >> > >> >> > >> We have a winner! >> > >> >> > >> Also, Kartik, dunno where it is on the net, but if you install a v7 >> > >> system, /usr/src/cmd/c >> > >> >> > >> Adam >> > >> >> > >> >> >> -- >> --- >> Larry McVoy lm at mcvoy.com >> http://www.mcvoy.com/lm >> > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hellwig.geisse at mni.thm.de Sat Apr 25 23:35:12 2020 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Sat, 25 Apr 2020 15:35:12 +0200 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> Message-ID: <1587821712.2206.338.camel@mni.thm.de> On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote: >     > From: Rob Pike > >     > Convenient though the shorthand may be, it always bothered me as >     > inconsistent and misleading. > > As someone who made very extensive use of procedure pointers (most notably in > upcalls, which never caught on, alas), I couldn't agree more. > > Two very different things are happenging, but with the shorthand notation, > they share an identical representation. And for what? To save three characters? The subject can be looked at from another angle. Consider the call f(42). This might be read as first naming f (and thus constructing a pointer to f) and then calling the function which the pointer is pointing to. So at least it should be possible to write the call as (*f)(42), which indeed is equivalent to f(42). So it can be argued that this notational shorthand should be allowed with all function pointers. Hellwig From rich.salz at gmail.com Sat Apr 25 23:59:59 2020 From: rich.salz at gmail.com (Richard Salz) Date: Sat, 25 Apr 2020 09:59:59 -0400 Subject: [TUHS] v7 K&R C In-Reply-To: <1587821712.2206.338.camel@mni.thm.de> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> <1587821712.2206.338.camel@mni.thm.de> Message-ID: The compilers have caught up, -Wswitch-enum is worthwhile. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Apr 26 00:57:50 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 25 Apr 2020 08:57:50 -0600 Subject: [TUHS] v7 K&R C In-Reply-To: References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> Message-ID: On Sat, Apr 25, 2020, 7:18 AM Rob Pike wrote: > To make chaining of calls simpler. Write > > f()->g()->h()->i() > > the other way and you'll see why Bjarne asked for the shorthand. > Yea. The other way looks way too lispy... Warner -rob > > > On Sat, Apr 25, 2020 at 11:12 PM Noel Chiappa > wrote: > >> > From: Rob Pike >> >> > Convenient though the shorthand may be, it always bothered me as >> > inconsistent and misleading. >> >> As someone who made very extensive use of procedure pointers (most >> notably in >> upcalls, which never caught on, alas), I couldn't agree more. >> >> Two very different things are happenging, but with the shorthand notation, >> they share an identical representation. And for what? To save three >> characters? >> >> Noel >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sun Apr 26 02:13:03 2020 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Sat, 25 Apr 2020 12:13:03 -0400 Subject: [TUHS] C and C++ Regrets In-Reply-To: References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> Message-ID: <869178f23343aa4169c4c907bdade7bf.squirrel@squirrelmail.tuffmail.net> The two things I'd wish had happened in C or C++ 1. That when they fixed structs/unions to have proper assignment and function argument and return behavior (i.e., making them full-fledged types), that they would have done the same for arrays. This inane "treat it like a pointer" has always been problematic. 2. That the default behavior in C++ is to *ALWAYS* initialize an object, even if it is POD, no matter how it is allocated. From paul.winalski at gmail.com Sun Apr 26 03:54:42 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 25 Apr 2020 13:54:42 -0400 Subject: [TUHS] v3 pipes In-Reply-To: <430B2F35-D250-499E-83F9-58D4C1764CE0@planet.nl> References: <430B2F35-D250-499E-83F9-58D4C1764CE0@planet.nl> Message-ID: On 4/25/20, Paul Ruizendaal wrote: > > I just tried making both pipe ends readable+writeable in my “V6.5” kernel > and that appears to work. It allows for bi-directional communication in a > half-duplex sense (i.e communicating walky-talky style). The other benefit > is using just one file descriptor, at a time when a process had just 15 to > work with. If both pipe ends are readable+writeable, you have the Unix equivalent of VMS mailboxes. There's lots of opportunity for both deadlock and livelock, and some "broken pipe" situations become difficult or impossible to detect. -Paul W. From jnc at mercury.lcs.mit.edu Sun Apr 26 04:03:57 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 25 Apr 2020 14:03:57 -0400 (EDT) Subject: [TUHS] v7 K&R C Message-ID: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> > From: Rob Pike > To make chaining of calls simpler. Write > f()->g()->h()->i() > the other way You mean: (*f)((*g)((*h)((*i)()))) I dunno, it doesn't seem that much worse to me. What I like about the explicit notation (i.e. (*f) ()) is that it forces the programmer to recognize what's going on. On the other hand, I guess, the whole concept of compiled languages is to get the programmer's nose out of the low-level details, so they can focus on the high level. So I guess one could see allowing f() in place of (*f)() as an instance of that. Then again, down that road you find a lot of modern code, where a programmer writes something that is e.g. horribly inefficient and slow, precisely because they are so divorced from the low-level of what the code they wrote turns into... Still, I'd be a little worried about a program doing (*f)((*g)((*h)((*i)()))), no matter what the notation was; it would be awfully hard to recognize what all the possible call chains are. But then again I guess a lot of e.g. AI code does things like that... Noel From blstuart at bellsouth.net Sun Apr 26 05:01:10 2020 From: blstuart at bellsouth.net (Brian L. Stuart) Date: Sat, 25 Apr 2020 19:01:10 +0000 (UTC) Subject: [TUHS] v7 K&R C In-Reply-To: <1587821712.2206.338.camel@mni.thm.de> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> <1587821712.2206.338.camel@mni.thm.de> Message-ID: <2050076633.160857.1587841270567@mail.yahoo.com> On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse wrote: > On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote: > > Two very different things are happenging, but with the shorthand notation, > > they share an identical representation. And for what? To save three characters? > > The subject can be looked at from another angle. Consider > the call f(42). This might be read as first naming f (and > thus constructing a pointer to f) and then calling the > function which the pointer is pointing to. This is the way that I've taken to looking at it for the last 10 years or so. In fact, I see it as the same thing as an array. Specifically, I've taken to thinking of [] as a postfix indexing operator and () as a postfix calling operator, and the thing on the left is a pointer in both cases. BLS -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Apr 26 05:41:02 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 25 Apr 2020 15:41:02 -0400 (EDT) Subject: [TUHS] v7 K&R C Message-ID: <20200425194102.3A54318C0BE@mercury.lcs.mit.edu> > From: moanga >> To make chaining of calls simpler. Write >> f()->g()->h()->i() Ah; I was confused by his notation; I didn't realize he meant the C operator '->'. Noel From michael at kjorling.se Sun Apr 26 06:11:31 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 25 Apr 2020 20:11:31 +0000 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> Message-ID: <9b9e01a6-fc1a-48a3-879c-665eb5a74205@localhost> On 25 Apr 2020 14:03 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa): > Then again, down that road you find a lot of modern code, where a programmer > writes something that is e.g. horribly inefficient and slow, precisely because > they are so divorced from the low-level of what the code they wrote turns into... ...and then there's an exceptionally complicated CPU execution pipeline in which code is rearranged to try to allow the CPU to execute it as fast as possible while preserving "observable" behavior. As we know, down that road lies... security vulnerabilities. That said, I agree; I don't know how many times I've nearly headdesked coming across code that looks like someone typed the first thing that entered their mind, instead of actually thinking the problem through first and _then_ coding a solution. I'm almost certainly not innocent there myself, either, although I do try. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From michael at kjorling.se Sun Apr 26 06:07:03 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 25 Apr 2020 20:07:03 +0000 Subject: [TUHS] v7 K&R C In-Reply-To: <2050076633.160857.1587841270567@mail.yahoo.com> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> <1587821712.2206.338.camel@mni.thm.de> <2050076633.160857.1587841270567@mail.yahoo.com> Message-ID: <9900c104-6f80-4b35-ae53-08b95c9dfbdf@localhost> On 25 Apr 2020 19:01 +0000, from blstuart at bellsouth.net (Brian L. Stuart): > On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse wrote: >> The subject can be looked at from another angle. Consider >> the call f(42). This might be read as first naming f (and >> thus constructing a pointer to f) and then calling the >> function which the pointer is pointing to. > > This is the way that I've taken to looking at it for the > last 10 years or so. In fact, I see it as the same thing > as an array. Specifically, I've taken to thinking of [] > as a postfix indexing operator and () as a postfix > calling operator, and the thing on the left is a pointer > in both cases. That's an interesting way of looking at it. I was thinking: couldn't we apply the same kind of reasoning to variables as well? Bear with me for a second. If we have int z = 123; then "z" is a mnenomic way of referring to an int-sized memory location, which after initialization holds the value 123. In C, we can take the address of any variable stored in memory, and we can dereference any address into memory. (How _meaningful_ especially the latter is varies, particularly on memory-protected architectures, but it's still possible.) So, is there any material difference between printf("%d", z); and printf("%d", *(&z)); If there is, then certainly GCC isn't indicating that it's there. Both print 123, and both variants compile cleanly even with -Wall -pedantic. OpenBSD clang 8.0.1 cc also gives identical output for both variants. So if "z" and "*(&z)" (take the address of z, then dereference that address, then use the value stored there) are equivalent, then in the name of consistency, why _shouldn't_ f() and (*f)() (dereference the address of f, then call) also be equivalent? After all, what is "f" here, other than a mnenomic name for a memory location? -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From steffen at sdaoden.eu Sun Apr 26 06:27:06 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 25 Apr 2020 22:27:06 +0200 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425194102.3A54318C0BE@mercury.lcs.mit.edu> References: <20200425194102.3A54318C0BE@mercury.lcs.mit.edu> Message-ID: <20200425202706.AA2BQ%steffen@sdaoden.eu> Noel Chiappa wrote in <20200425194102.3A54318C0BE at mercury.lcs.mit.edu>: |> From: moanga | |>> To make chaining of calls simpler. Write |>> f()->g()->h()->i() | |Ah; I was confused by his notation; I didn't realize he meant the C \ |operator |'->'. Oh, i love this method-on-object as opposed to object-on-function methodology. while(_tr.read_line(*&_line) >= 0){ ln = _line.trim().squeeze().data(); len = _line.length(); which can easily exceed a 80x2[45] screen in C. Especially with "more modern" frameworks which try to avoid namespace pollution and easily exceed 20 bytes for a single function name alone. Of course error handling is often a problem unless you go for exceptions (terrible, especially if they do not have language builtin support for file and line number, at least without -DNDEBUG, imho), general state machines or whatever. While at C++, the checked automatic upcasts are also very helpful, especially if you have a deeper object hierarchy. (As in, struct object{}, struct drawable{struct object super...}, struct button{struct drawable super..}, then "drawable d;.. object*=&d (or for heaven's sake &d.super) is much much better as &d.super.super or even (object*)&d.) Damn i have given up on perfection, and sometimes even on "being explicit is better", but a shame it is. Ciao, a nice Sunday and Good luck! from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From blstuart at bellsouth.net Sun Apr 26 07:27:11 2020 From: blstuart at bellsouth.net (Brian L. Stuart) Date: Sat, 25 Apr 2020 21:27:11 +0000 (UTC) Subject: [TUHS] v7 K&R C In-Reply-To: <9b9e01a6-fc1a-48a3-879c-665eb5a74205@localhost> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> <9b9e01a6-fc1a-48a3-879c-665eb5a74205@localhost> Message-ID: <1734443289.192430.1587850031879@mail.yahoo.com> On Saturday, April 25, 2020, 04:11:58 PM EDT, Michael Kjörling wrote: > That said, I agree; I don't know how many times I've nearly headdesked > coming across code that looks like someone typed the first thing that > entered their mind, instead of actually thinking the problem through > first and _then_ coding a solution. I'm almost certainly not innocent > there myself, either, although I do try. I know that feeling all too well. I try to think of it in the same terms as "Let him who is without sin cast the first stone." But students coming to me with code that is clearly created using the random walk method of programming lead to me not always being as patient with my counsel as I should be. BLS -------------- next part -------------- An HTML attachment was scrubbed... URL: From blstuart at bellsouth.net Sun Apr 26 07:34:44 2020 From: blstuart at bellsouth.net (Brian L. Stuart) Date: Sat, 25 Apr 2020 21:34:44 +0000 (UTC) Subject: [TUHS] v7 K&R C In-Reply-To: <9900c104-6f80-4b35-ae53-08b95c9dfbdf@localhost> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> <1587821712.2206.338.camel@mni.thm.de> <2050076633.160857.1587841270567@mail.yahoo.com> <9900c104-6f80-4b35-ae53-08b95c9dfbdf@localhost> Message-ID: <1862444098.192050.1587850484006@mail.yahoo.com> On Saturday, April 25, 2020, 04:17:14 PM EDT, Michael Kjörling wrote: > I was thinking: couldn't we apply the same kind of reasoning to > variables as well? > ... In short, yes. In the language Bliss, all identifiers stood for the address of that thing. A prefix dot (.) dereferences that thing. So copying x to y would be something like y = .x; In C, rvalues have an implicit dereference happening. I've actually created a toy language that I subject my students to that revives the Bliss view to drive home in their minds the difference between the address of a memory location and the contents of a memory location. I want them to have some concept of how the program connects to the machine before they find themselves so mired in abstraction that everything is treated as magic. One of my TAs in that class last fall was taking a class in the winter where she was using C seriously for the first time and having trouble understanding pointers. When I explained how C pointers worked in terms of the variables and dots of this other language it became much more clear for her. BLS -------------- next part -------------- An HTML attachment was scrubbed... URL: From emu at e-bbes.com Sun Apr 26 10:07:33 2020 From: emu at e-bbes.com (emanuel stiebler) Date: Sat, 25 Apr 2020 20:07:33 -0400 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> Message-ID: <0db3027a-0928-99a8-240c-4b8b3edf4401@e-bbes.com> On 2020-04-25 14:03, Noel Chiappa wrote: > You mean: > (*f)((*g)((*h)((*i)()))) Are we still discussing LISP or C? Sorry, couldn't resist ;-) From robpike at gmail.com Sun Apr 26 10:54:07 2020 From: robpike at gmail.com (Rob Pike) Date: Sun, 26 Apr 2020 10:54:07 +1000 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> Message-ID: > > You mean: > > (*f)((*g)((*h)((*i)()))) > > No. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Apr 26 16:40:58 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 26 Apr 2020 00:40:58 -0600 Subject: [TUHS] v7 K&R C In-Reply-To: <2050076633.160857.1587841270567@mail.yahoo.com> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> <1587821712.2206.338.camel@mni.thm.de> <2050076633.160857.1587841270567@mail.yahoo.com> Message-ID: <202004260640.03Q6ewui006245@freefriends.org> "Brian L. Stuart" wrote: > On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse wrote: > > On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote: > > > Two very different things are happenging, but with the shorthand notation, > > > they share an identical representation. And for what? To save three characters? > > > > The subject can be looked at from another angle. Consider > > the call f(42). This might be read as first naming f (and > > thus constructing a pointer to f) and then calling the > > function which the pointer is pointing to. > > This is the way that I've taken to looking at it for the > last 10 years or so. In fact, I see it as the same thing > as an array. Specifically, I've taken to thinking of [] > as a postfix indexing operator and () as a postfix > calling operator, and the thing on the left is a pointer > in both cases. > > BLS > Algol 68 had a concept "deproceduring" similar to "dereferencing". If you think of foo(arg) where plain "foo" is a pointer to a function and adding the parentheses does the call, then it's the same with a procedure name or with a function pointer. This is pretty much what BLS said. Thinking of [] and () as operators is explicit in C++ (for good and for ill). Arnold From dfawcus+lists-tuhs at employees.org Mon Apr 27 05:37:04 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sun, 26 Apr 2020 20:37:04 +0100 Subject: [TUHS] v7 K&R C In-Reply-To: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> Message-ID: <20200426193704.GA87816@clarinet.employees.org> On Sat, Apr 25, 2020 at 02:03:57PM -0400, Noel Chiappa wrote: > > From: Rob Pike > > > To make chaining of calls simpler. Write > > f()->g()->h()->i() > > the other way > > You mean: > > (*f)((*g)((*h)((*i)()))) > > I dunno, it doesn't seem that much worse to me. No, I think he means something like: (*((*((*((*f)()->g))()->h))()->i))() but I can't recall the relative priority of '*' and '->' in the above, so I may have added unnecessary parens. Or was he thinking of having to use '.' as well to access the member pointers within the structs? DF From dfawcus+lists-tuhs at employees.org Mon Apr 27 06:10:44 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sun, 26 Apr 2020 21:10:44 +0100 Subject: [TUHS] v7 K&R C In-Reply-To: <20200426193704.GA87816@clarinet.employees.org> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> <20200426193704.GA87816@clarinet.employees.org> Message-ID: <20200426201044.GB87816@clarinet.employees.org> On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote: > No, I think he means something like: > > (*((*((*((*f)()->g))()->h))()->i))() > > but I can't recall the relative priority of '*' and '->' in > the above, so I may have added unnecessary parens. Actually trying it, while the above does the right thing, I can also get the following to compile with a modern compiler (*(*(*(*f)()->g)()->h)()->i)(); So maybe that was the answer? I guess I'd have to question why someone would wish to write such a construct, as error handling seems awkward. Even in the modern form. DF From rdm at cfcl.com Mon Apr 27 07:59:43 2020 From: rdm at cfcl.com (Rich Morin) Date: Sun, 26 Apr 2020 14:59:43 -0700 Subject: [TUHS] v7 K&R C In-Reply-To: <20200426201044.GB87816@clarinet.employees.org> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> <20200426193704.GA87816@clarinet.employees.org> <20200426201044.GB87816@clarinet.employees.org> Message-ID: <9EE9F12A-F44F-4BB8-B859-9D77AF46F4EF@cfcl.com> > On Apr 26, 2020, at 13:10, Derek Fawcus wrote: > > I guess I'd have to question why someone would wish to write such a construct, > as error handling seems awkward. FWIW, I do most of my programming these days in Elixir. It's a functional programming language with pervasive pattern matching, Rubyish syntax, and Lispish macros. It runs on the Erlang virtual machine, so it has a good story for Actor-based concurrency, distribution, etc. For details, see: https://en.wikipedia.org/wiki/Elixir_(programming_language) Anyway, compilation is mostly handled by Lispish macros, so it can support some fairly cool metaprogramming. In particular, I can write things like: out_map = inp_list |> Enum.filter(filter_fn) |> Enum.map(map_fn) |> Enum.reduce(%{}, reduce_fn) Piped values are handed in as the first argument to each function and most functions expect this behavior. For extra credit, there is a set of Stream functions (really, macros) that process one element at a time and handle errors in a reasonable manner. -r From noel.hunt at gmail.com Mon Apr 27 08:38:39 2020 From: noel.hunt at gmail.com (Noel Hunt) Date: Mon, 27 Apr 2020 08:38:39 +1000 Subject: [TUHS] v7 K&R C In-Reply-To: <20200426201044.GB87816@clarinet.employees.org> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> <20200426193704.GA87816@clarinet.employees.org> <20200426201044.GB87816@clarinet.employees.org> Message-ID: Tom Cargill makes (made) frequent use of this construction in 'pi' (process inspector, first in Eight Edition), e.g., asm.c: _asm->core->process()->openmemory(addr); frame.c: return core->process()->frame(level-1)->regloc((int)v->range.lo, v->type.size_of()); phrase.c: frame->symtab()->core()->process()->openmemory(expr->val.lng); On Mon, Apr 27, 2020 at 6:11 AM Derek Fawcus < dfawcus+lists-tuhs at employees.org> wrote: > On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote: > > No, I think he means something like: > > > > (*((*((*((*f)()->g))()->h))()->i))() > > > > but I can't recall the relative priority of '*' and '->' in > > the above, so I may have added unnecessary parens. > > Actually trying it, while the above does the right thing, > I can also get the following to compile with a modern compiler > > (*(*(*(*f)()->g)()->h)()->i)(); > > So maybe that was the answer? > > I guess I'd have to question why someone would wish to write > such a construct, as error handling seems awkward. Even in > the modern form. > > DF > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Mon Apr 27 09:57:24 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Sun, 26 Apr 2020 19:57:24 -0400 Subject: [TUHS] v7 K&R C In-Reply-To: <20200426201044.GB87816@clarinet.employees.org> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> <20200426193704.GA87816@clarinet.employees.org> <20200426201044.GB87816@clarinet.employees.org> Message-ID: <62bd7be3-a608-f9fd-3544-8620802d4ac7@gmail.com> On 04/26/20 16:10, Derek Fawcus wrote: > On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote: >> No, I think he means something like: >> >> (*((*((*((*f)()->g))()->h))()->i))() >> >> but I can't recall the relative priority of '*' and '->' in >> the above, so I may have added unnecessary parens. > Actually trying it, while the above does the right thing, > I can also get the following to compile with a modern compiler > > (*(*(*(*f)()->g)()->h)()->i)(); > > So maybe that was the answer? K&R 1, Sect. 6.2. (with no mention of Rob Pike's influence). N. > > I guess I'd have to question why someone would wish to write > such a construct, as error handling seems awkward. Even in > the modern form. > > DF From robpike at gmail.com Mon Apr 27 13:38:18 2020 From: robpike at gmail.com (Rob Pike) Date: Mon, 27 Apr 2020 13:38:18 +1000 Subject: [TUHS] v7 K&R C In-Reply-To: <62bd7be3-a608-f9fd-3544-8620802d4ac7@gmail.com> References: <20200425180357.A004918C0B6@mercury.lcs.mit.edu> <20200426193704.GA87816@clarinet.employees.org> <20200426201044.GB87816@clarinet.employees.org> <62bd7be3-a608-f9fd-3544-8620802d4ac7@gmail.com> Message-ID: Yes, that's the issue, which arose in C++ programs. The question at the time was whether C would allow the same syntax. Nothing to do with me. -rob On Mon, Apr 27, 2020 at 9:58 AM Nemo Nusquam wrote: > On 04/26/20 16:10, Derek Fawcus wrote: > > On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote: > >> No, I think he means something like: > >> > >> (*((*((*((*f)()->g))()->h))()->i))() > >> > >> but I can't recall the relative priority of '*' and '->' in > >> the above, so I may have added unnecessary parens. > > Actually trying it, while the above does the right thing, > > I can also get the following to compile with a modern compiler > > > > (*(*(*(*f)()->g)()->h)()->i)(); > > > > So maybe that was the answer? > > K&R 1, Sect. 6.2. (with no mention of Rob Pike's influence). > > N. > > > > > I guess I'd have to question why someone would wish to write > > such a construct, as error handling seems awkward. Even in > > the modern form. > > > > DF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Mon Apr 27 23:19:23 2020 From: dot at dotat.at (Tony Finch) Date: Mon, 27 Apr 2020 14:19:23 +0100 Subject: [TUHS] v7 K&R C In-Reply-To: References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> Message-ID: Rob Pike wrote: > The ability to call a function pointer fp with the syntax fp() rather than > (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty > sure it was not in v7 C, as you observe. I've seen some interesting discussion about Dave Horsfall's favourite retro-C definition of abort(): int abort 4; ... abort(); https://minnie.tuhs.org/pipermail/tuhs/2020-March/020680.html In particular a lot of people didn't know that function pointers could not be called like abort() so they didn't realise that 4 was the machine code contents of the function, not the address of the function. (Extra confusing since branching to address 4 was also a plausible way to crash the program...) But that made me wonder what 7th-and-earlier C would do if you tried to call a local variable. I guess that would lead to the compiler saying error("Call of non-function"); Tony. -- f.anthony.n.finch http://dotat.at/ Hebrides, Bailey, Fair Isle, Faeroes: Northeasterly 4 to 6, occasionally 7 at first in north Fair Isle. Moderate or rough. Showers. Good, occasionally moderate. From jnc at mercury.lcs.mit.edu Tue Apr 28 03:45:53 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 27 Apr 2020 13:45:53 -0400 (EDT) Subject: [TUHS] v7 K&R C Message-ID: <20200427174553.2801618C09B@mercury.lcs.mit.edu> > From: Derek Fawcus > I think he means something like: > (*((*((*((*f)()->g))()->h))()->i))() So I've been confused by this thread, and I'm hoping someone can deconfuse me - but I think I may have figured it out. What's confusing me is that in C, the -> operator is followed by "an identifier [which] designates a member of a structure or union object" (I checked the spec to make sure my memory hadn't dropped any bits) - but g, h above are arguments; so I couldn't figure out what was going on. I think what may have happened is that initially the discussion was about C ("Pretty sure it was not in v7 C"), but then it switched to C++ - with which I'm not familiar, hence my confusion - without explicitly indicating that change (although the reference to Bjarne Stroustrup should been a clue). (And that's why I thought "f()->g()->h()->i()" was ad hoc notation for "calls f(), then calls g()".) Am I tracking now? Noel From rich.salz at gmail.com Tue Apr 28 03:56:37 2020 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 27 Apr 2020 13:56:37 -0400 Subject: [TUHS] v7 K&R C In-Reply-To: <20200427174553.2801618C09B@mercury.lcs.mit.edu> References: <20200427174553.2801618C09B@mercury.lcs.mit.edu> Message-ID: /* struct declarations. */ struct fval; struct gval; struct hval; /* function declarations */ struct fval *f(); struct gval *g(); struct hval *h(); struct fval { struct gval* (*g)(); int dummy; }; struct gval { struct hval* (*h)(); }; struct hval { void (*i)(); }; extern void test(); void test() { f()->g()->h()->i(); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Tue Apr 28 04:02:29 2020 From: brantley at coraid.com (Brantley Coile) Date: Mon, 27 Apr 2020 18:02:29 +0000 Subject: [TUHS] v7 K&R C In-Reply-To: <20200427174553.2801618C09B@mercury.lcs.mit.edu> References: <20200427174553.2801618C09B@mercury.lcs.mit.edu> Message-ID: g, h and i are members of structures, the pointer of which is returned by the preceding function call. They have to be defined as pointers to functions returning a pointer to the following structure. A simple example is: typedef struct Node Node; struct Node { Node *(*f)(void); }; void main(void) { Node *p; p->f()->f()->f(); call(); (*((*((*p->f)()->f))())->f)(); } // (*((*((*((*f)()->g))()->h))()->i))() > On Apr 27, 2020, at 1:45 PM, Noel Chiappa wrote: > >> From: Derek Fawcus > >> I think he means something like: >> (*((*((*((*f)()->g))()->h))()->i))() > > So I've been confused by this thread, and I'm hoping someone can deconfuse me > - but I think I may have figured it out. > > What's confusing me is that in C, the -> operator is followed by "an > identifier [which] designates a member of a structure or union object" (I > checked the spec to make sure my memory hadn't dropped any bits) - but g, h > above are arguments; so I couldn't figure out what was going on. > > I think what may have happened is that initially the discussion was about C > ("Pretty sure it was not in v7 C"), but then it switched to C++ - with which > I'm not familiar, hence my confusion - without explicitly indicating that > change (although the reference to Bjarne Stroustrup should been a clue). (And > that's why I thought "f()->g()->h()->i()" was ad hoc notation for "calls f(), > then calls g()".) > > Am I tracking now? > > Noel > > From dfawcus+lists-tuhs at employees.org Tue Apr 28 04:47:22 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Mon, 27 Apr 2020 19:47:22 +0100 Subject: [TUHS] v7 K&R C In-Reply-To: <20200427174553.2801618C09B@mercury.lcs.mit.edu> References: <20200427174553.2801618C09B@mercury.lcs.mit.edu> Message-ID: <20200427184722.GA64072@clarinet.employees.org> On Mon, Apr 27, 2020 at 01:45:53PM -0400, Noel Chiappa wrote: > So I've been confused by this thread, and I'm hoping someone can deconfuse me > - but I think I may have figured it out. > > What's confusing me is that in C, the -> operator is followed by "an > identifier [which] designates a member of a structure or union object" (I > checked the spec to make sure my memory hadn't dropped any bits) - but g, h > above are arguments; so I couldn't figure out what was going on. See below. DF #include struct h_ret { void (*i)(); }; struct g_ret { struct h_ret *(*h)(); }; struct f_ret { struct g_ret *(*g)(); }; void i_fn() { printf("I\n"); } struct h_ret h_val = { i_fn }; struct h_ret *h_fn() { printf("H\n"); return &h_val; } struct g_ret g_val = { h_fn }; struct g_ret *g_fn() { printf("G\n"); return &g_val; } struct f_ret f_val = { g_fn }; struct f_ret *f_fn() { printf("F\n"); return &f_val; } void fred(struct f_ret *(*f)()) { #if 1 (*(*(*(*f)()->g)()->h)()->i)(); #else f()->g()->h()->i(); #endif } int main() { fred(f_fn); return 0; } From athornton at gmail.com Tue Apr 28 04:47:29 2020 From: athornton at gmail.com (Adam Thornton) Date: Mon, 27 Apr 2020 11:47:29 -0700 Subject: [TUHS] s-for-v7, was Re: v7 K&R C In-Reply-To: <202004260640.03Q6ewui006245@freefriends.org> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> <1587821712.2206.338.camel@mni.thm.de> <2050076633.160857.1587841270567@mail.yahoo.com> <202004260640.03Q6ewui006245@freefriends.org> Message-ID: If anyone else could use it, “s” slightly modified from Miller’s sources (via Udo Munk’s repository) to build on out-of-the-box v7 + C compiler: https://github.com/athornton/s/tree/v7 It’s a reimplementation of Paul Ruizendall’s work. The changes are: 1) the indirect function call syntax needs to be (*fcn)(arg) rather than fcn(arg). 2) scr_delr and scr_delc needed to be shortened by a character because the linker puts an underscore in front of the name and truncates the symbol to 8 characters, and without that fix they are not distinguishable. 3) isprint() in v7 didn't recognize the space as a printable character Screen repainting doesn’t seem to be entirely reliable, but…it still works a lot like vi, which I find more pleasant than ed. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ritorto at gmail.com Tue Apr 28 11:56:20 2020 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Mon, 27 Apr 2020 21:56:20 -0400 Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD Message-ID: Hiya! Got these two pdp11s, one an 11/23 (Ultrix-11 3.1) and the other an 11/84 (2.11BSD) On the Ultrix machine, I can enter an assembly language program, assemble it and run it fine. amnesiac# cat hello.s mov $1,r0 sys 4 a 6 sys 1 a: amnesiac# od hello 0000000 000407 000022 000000 000000 000014 000000 000000 000000 0000020 012700 000001 104404 000014 000006 104401 062510 066154 0000040 005157 000000 000000 000000 000002 000000 000000 000000 0000060 000000 000000 000141 000000 000000 000000 000002 000014 0000100 amnesiac# ./hello Hello amnesiac# But on the BSD machine, the exact same source program assembles differently and crashes with Illegal instruction when I run it. > cat hello.s mov $1,r0 sys 4 a 6 sys 1 a: > od a.out 0000000 000407 000022 000000 000000 000010 000000 000000 000000 0000020 012700 000001 104404 000014 000006 104401 062510 066154 0000040 005157 000000 000000 000000 000002 000000 000000 000000 0000060 000000 000000 000000 000004 000002 000014 000000 000006 0000100 000141 0000102 > ./a.out Illegal instruction (core dumped) > Anyone know what I'm doing wrong? thx jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Apr 28 23:03:16 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 28 Apr 2020 09:03:16 -0400 Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD In-Reply-To: References: Message-ID: <3642A182-45AA-43F8-A07B-8FAB69AD84A9@ronnatalie.com> Yes, you aren’t programming 2.11 BSD correctly. Your examples are the older UNIX syscalls (your programs work correctly in Version 6 by the way as well). In 2.11 BSD, all the arguments for the syscalls are inline (i.e., none are passed in registers. This appears to be the beginnings of making the kernel protable across architectures. The systent table no longer has separate fields for args in registers and not in registers and the code in sys/pdp/trap.c doesn’t look at the registers anymore. > On Apr 27, 2020, at 9:56 PM, Jacob Ritorto wrote: > > mov $1,r0 > sys 4 > a > 6 > sys 1 Proper code now should be: sys 4 1 a 6 sys 1 0 Note your previous code used to just return 6 from the program (the return value of write). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ritorto at gmail.com Wed Apr 29 10:17:54 2020 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Tue, 28 Apr 2020 20:17:54 -0400 Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD In-Reply-To: <3642A182-45AA-43F8-A07B-8FAB69AD84A9@ronnatalie.com> References: <3642A182-45AA-43F8-A07B-8FAB69AD84A9@ronnatalie.com> Message-ID: On Tue, Apr 28, 2020 at 9:03 AM Ronald Natalie wrote: > Yes, you aren’t programming 2.11 BSD correctly. > Wow, I'd hoped it was that. Thank you so much! I spent way too much time fiddling incorrectly. Was an example I'd cobbled together from my college textbook I've been going back through, _Assembly_Language_for_the_PDP-11_RT-RSX-UNIX_ (c)1981 Kapps and Stafford. We didn't have UNIX for the class so never ran into this. > Your examples are the older UNIX syscalls (your programs work correctly in > Version 6 by the way as well). > > In 2.11 BSD, all the arguments for the syscalls are inline (i.e., none are > passed in registers. This appears to be the beginnings of making the > kernel protable across architectures. > The systent table no longer has separate fields for args in registers and > not in registers and the code in sys/pdp/trap.c doesn’t look at the > registers anymore. > I wonder if the differences are written up somewhere. I did try to look for more documentation but came up short. Must've been quite well-ingrained in programmers' minds in the day. > Proper code now should be: > sys 4 > 1 > a > 6 > sys 1 > 0 > Note your previous code used to just return 6 from the program (the return > value of write). > Ah, so passing exit code as an arg to sys 1. Cool. Thanks again! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Apr 29 10:54:24 2020 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Tue, 28 Apr 2020 20:54:24 -0400 Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD In-Reply-To: References: <3642A182-45AA-43F8-A07B-8FAB69AD84A9@ronnatalie.com> Message-ID: Yes, the calling sequence changes were in the back of my mind, but fortunately the TUHS source archives allowed me to easily look at the kernel source to see how the arguments were passed. Somewhere between 2.8 and 2.11 they changed it. Again, 2.11 was one fo the first attempts to formalize a true "multi platform" kernel rather than just copying over the kernel and reworking it for a new machine from a seperate source "tree." Yes, your code takes the return of the write system call and uses it as the exit code. Not that it makes too much difference. My 2.11 version of your code passes a zero explicitly. Amusingly, speaking of college courses. I had early on joined the UNIX systems programming team at JHU and had also done some custom work for various PDP-11 sites on campus (DOS/BATCH, RT-11, etc...). PDP-11 assembler was something I knew well. The head of the EE department told me he'd be very disappointed if I actually signed up for his PDP-11 assembler programming course my senior year. Oddly, this caused some consternation with the faculty committee approving my graduation as I hadn't taken it and it was required. Our department UNIX machine as a PDP-11/45 running a high modified V6 kernel. I also got one of the early 11/23's and we brought up the same software on that. A year after I graduated, I was attending a DEC announcement on the T-11 (I think the first single chip PDP-11). The speaker says it had all the instructions with the exception of MARK. Me and one other guy are going, "What? No MARK instruction?" MARK was the most useless instruction concocted and it wouldn't even work on an executable that was set up split I/D. From jnc at mercury.lcs.mit.edu Wed Apr 29 12:26:54 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 28 Apr 2020 22:26:54 -0400 (EDT) Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD Message-ID: <20200429022654.D43FA18C08D@mercury.lcs.mit.edu> > From: Jacob Ritorto > I wonder if the differences are written up somewhere. I did try to look > for more documentation but came up short. Sounds like a perfect topic for a CHWiki page. :-) E.g. this one: http://gunkies.org/wiki/Unix_V6_internals which I did as a bit of an addendum to Lions, to explain rsav, qsav and ssav, and similar topics. I noticed in the comparison of your two binary files that the instructions looked the same, but the a.out headers had a difference, but I didn't remember the fields in the a.out header enough to know what the differences meant. I thought I remembered doing an a.out page there, but apparently not. I thought about doing one now, but decided it wasn't worth it; I just needed to spin up my V6 system and do 'man a.out'! :-) Noel From jacob.ritorto at gmail.com Wed Apr 29 14:08:35 2020 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 29 Apr 2020 00:08:35 -0400 Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD In-Reply-To: <20200429022654.D43FA18C08D@mercury.lcs.mit.edu> References: <20200429022654.D43FA18C08D@mercury.lcs.mit.edu> Message-ID: Shoot, celebrated too soon. I rearranged it per your tutelage, Ron, and it's still giving an Illegal Instruction error! >From the adb output it looks like it's balking at the "14" instruction at location 24, which, based on the BSD updates you mentioned, I thought should've been taken as an arg, not an instruction, right? I assume this worked for you on some BSD, right? If so, is it a bug in the recent 2.11BSD patch release, perhaps? Anyone able to help me understand? > vi hello.s "hello.s" 8 lines, 52 characters sys 4 1 a 6 sys 1 0 a: "hello.s" 7 lines, 78 characters > as !$ as hello.s > ./a.out Illegal instruction (core dumped) > od a.out 0000000 000407 000022 000000 000000 000010 000000 000000 000000 0000020 104404 000001 000014 000006 104401 000000 062510 066154 0000040 005157 000000 000000 000002 000000 000000 000000 000000 0000060 000000 000000 000000 000004 000002 000014 000000 000006 0000100 000141 0000102 > adb adb> :s stopped at 0: sys write adb> :s a.out: running stopped at 04: 014 adb> :s a.out: running Illegal instruction stopped at 06: rtt adb> :s a.out: running Illegal instruction - core dumped process terminated adb> > On Tue, Apr 28, 2020 at 10:26 PM Noel Chiappa wrote: > > From: Jacob Ritorto > > > I wonder if the differences are written up somewhere. I did try to > look > > for more documentation but came up short. > > Sounds like a perfect topic for a CHWiki page. :-) E.g. this one: > > http://gunkies.org/wiki/Unix_V6_internals > > which I did as a bit of an addendum to Lions, to explain rsav, qsav and > ssav, and > similar topics. > > > I noticed in the comparison of your two binary files that the instructions > looked the same, but the a.out headers had a difference, but I didn't > remember > the fields in the a.out header enough to know what the differences meant. > > I thought I remembered doing an a.out page there, but apparently not. I > thought about doing one now, but decided it wasn't worth it; I just needed > to > spin up my V6 system and do 'man a.out'! :-) > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Apr 29 22:20:25 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Wed, 29 Apr 2020 08:20:25 -0400 Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD In-Reply-To: References: <20200429022654.D43FA18C08D@mercury.lcs.mit.edu> Message-ID: <56F9E80D-8942-4E05-A22F-4A6A123D4F71@ronnatalie.com> Sorry, I typed that in haste without testing. I don’t have a 2.11 system to try it on. However, reading the source code, I did that wrong. The args go on the stack, not in line with the code. mov $6, -(sp) mov a, -(sp) mov $1,-(sp) sys 4 > On Apr 29, 2020, at 12:08 AM, Jacob Ritorto wrote: > > Shoot, celebrated too soon. I rearranged it per your tutelage, Ron, and it's still giving an Illegal Instruction error! > From the adb output it looks like it's balking at the "14" instruction at location 24, which, based on the BSD updates you mentioned, I thought should've been taken as an arg, not an instruction, right? > > I assume this worked for you on some BSD, right? > If so, is it a bug in the recent 2.11BSD patch release, perhaps? Anyone able to help me understand? > > > vi hello.s > "hello.s" 8 lines, 52 characters > sys 4 > 1 > a > 6 > sys 1 > 0 > a: > > "hello.s" 7 lines, 78 characters > > as !$ > as hello.s > > ./a.out > Illegal instruction (core dumped) > > od a.out > 0000000 000407 000022 000000 000000 000010 000000 000000 000000 > 0000020 104404 000001 000014 000006 104401 000000 062510 066154 > 0000040 005157 000000 000000 000002 000000 000000 000000 000000 > 0000060 000000 000000 000000 000004 000002 000014 000000 000006 > 0000100 000141 > 0000102 > > adb > adb> :s > stopped at 0: sys write > adb> :s > a.out: running > stopped at 04: 014 > adb> :s > a.out: running > Illegal instruction > stopped at 06: rtt > adb> :s > a.out: running > Illegal instruction - core dumped > process terminated > adb> > > > On Tue, Apr 28, 2020 at 10:26 PM Noel Chiappa > wrote: > > From: Jacob Ritorto > > > I wonder if the differences are written up somewhere. I did try to look > > for more documentation but came up short. > > Sounds like a perfect topic for a CHWiki page. :-) E.g. this one: > > http://gunkies.org/wiki/Unix_V6_internals > > which I did as a bit of an addendum to Lions, to explain rsav, qsav and ssav, and > similar topics. > > > I noticed in the comparison of your two binary files that the instructions > looked the same, but the a.out headers had a difference, but I didn't remember > the fields in the a.out header enough to know what the differences meant. > > I thought I remembered doing an a.out page there, but apparently not. I > thought about doing one now, but decided it wasn't worth it; I just needed to > spin up my V6 system and do 'man a.out'! :-) > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Wed Apr 29 23:55:41 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 29 Apr 2020 15:55:41 +0200 Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD Message-ID: <9A1BF33E-49C9-4712-BF25-4C0BBC504CD1@planet.nl> > Sorry, I typed that in haste without testing. I don’t have a 2.11 system to try it on. However, reading the source code, I did that wrong. The args go on the stack, not in line with the code. > mov $6, -(sp) > mov a, -(sp) > mov $1,-(sp) > sys 4 Without suggesting that every helpful post should be tested, I find the superb https://unix50.org web emulator excellent for such things. Many thanks to the folks hosting & maintaining this great resource! From ron at ronnatalie.com Thu Apr 30 00:18:57 2020 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Wed, 29 Apr 2020 10:18:57 -0400 Subject: [TUHS] as(1) on Ultrix-11 vs 2.11BSD In-Reply-To: <9A1BF33E-49C9-4712-BF25-4C0BBC504CD1@planet.nl> References: <9A1BF33E-49C9-4712-BF25-4C0BBC504CD1@planet.nl> Message-ID: Thanks for the link. With that help, I fixed the bug in the program: mov $6., -(sp) mov $1f, -(sp) mov $1,-(sp) mov $0,-(sp) sys 4 add $8., sp mov $0,-(sp) mov $0,-(sp) sys 1 1: >> Sorry, I typed that in haste without testing. I don’t have a 2.11 system >> to try it on. However, reading the source code, I did that wrong. The >> args go on the stack, not in line with the code. >> mov $6, -(sp) >> mov a, -(sp) >> mov $1,-(sp) >> sys 4 > > Without suggesting that every helpful post should be tested, I find the > superb https://unix50.org web emulator excellent for such things. > > Many thanks to the folks hosting & maintaining this great resource! > >