- TUHS - www.tuhs.org

by steve jenkin

In 2007 I started entering the contents of Eric Levenez’s “Unix History” diagram into “dot” format to use with Graphviz. It stalled when I was unable to create a diagram I really liked. My recollection is that I talked with Warren about encoding this data and creating diagrams. He compiled the TUHS “Unix Tree”, presumably now the definitive resource, but I haven’t see a diagram linked from there. There’s the github “Unix History” project by TUHS list folk <https://github.com/dspinellis/unix-history-repo> I didn’t research producing timelines & relationships automatically from git: this would be a solid solution, if the Repo was considered as permanent as the TUHS site. The “Linux Distribution Timeline” is based on a tool, gnuclad, that takes CSV files and 'computes a cladogram’ in SVG. conversion to PNG is via ImageMagick’s “convert”. By default, timelines are produced ‘left to right’, with claimed ‘right to left’, ’top to bottom’ and ‘bottom to top’ formats - which I haven’t tested. The CSV file can include links which are built into clickable points in the final image, at least for SVG, unsure of PNG. A concern that I have is the creation of the CSV file from Distrowatch is opaque. Possibly built by hand. New diagrams are uploaded 2-3 times a year. The Levenez "fishbone" diagram doesn’t seem to be updated with Warner Losh’s 2020 “Hidden Early History”. Clem Cole’s Big Block diagram shows “low-res” diagrams are also very useful, eliminating distracting detail when appropriate. Groklaw from 2004-2009 tried to collect information about the Unix/Linux Timelines, but the site is gone now & Wayback machine hasn’t picked up many of the detail / comments page. I’ve no contact with PJ & whoever runs Groklaw now. Would that data collection contain anything more than TUHS, as it does try to include both Linux and Unix? Any suggestions? Something extra in the Linux Distro Tree is a notation for people moving between projects and tracking forks. Unsure how that’s accomplished, and not sure how important that is for Unixes. TUHS is “Early Unix”, not about Linux. However, some degree of compatibility between Unix & Linux Timeline diagrams might be useful for others if they ever try to join multiple trees. If a timeline / relationship table is constructed, designing it to be somewhat compatible will help future people. I’m not sure about tracking the many descendants of BSD. Wikipedia has a list without a timeline . <https://en.wikipedia.org/wiki/List_of_BSD_operating_systems> Someone may already be being doing this somewhere, I didn’t look. Don’t think modern descendants of BSD should be tracked by a Unix Heritage Society, has to be a boundary somewhere. regards steve jenkin ============ Some Questions: 1. Is there any benefit in developing a canonical “Unix Timeline” dataset containing the relationships, allowing programatic conversion to diagrams? There might be better tools in the future. I’d favour tab-separated text files, because they can be read / written by Spreadsheets and converted to CSV. Warren’s solution of tables & pages is good: there’s simply too much information & complexity to capture in simple file formats The gnuclad solution of providing “Clickable Links” is useful, if like TUHS, the pages are well maintained. 2. How to cater for: - adding extra-fine detail for segments of the timeline (Warner Losh) - ‘zooming out’ and providing an overview (Clem Cole) - some sort of compatibility with known tables, like Linux Distro Timeline 3. No simple representation can, or should try, to be “all things to all people”, there’s too much detail and too many events occurred. Is there a useful subset of detail that can be captured in a simple table? There may be useful subsets of the Unix Timeline that show more or less detail, To support programatic zoom In/Out, an indent or level descriptor is required in the table. Does anyone have a good data model for that? ============ Warner Losh, "Hidden Early History of Unix”, Fosdem 2020 -> "Standard History of Unix, in 3 slides” graphviz, coloured names, landscape format [small] “Simplified family tree” 4th Edition Family Tree 6th Edition Family Tree 7th Edition Family Tree Clem Cole, UNIX, Linux and BSD, USENIX 2009, reexamining "A Short UNIX History”, 2000 talk -> "A UNIX Family History 1st 25 Yrs” [69-93] graphviz ?, landscape, coloured, triangle symbols, thin lines & arrows -> Simplified Linux Family Tree, circa ’09 graphviz ?, landscape, coloured, blocks + text, short thick lines & arrows ============ TUHS, The Unix Tree No diagrams, tarball with all content <https://www.tuhs.org/cgi-bin/utree.pl> Éric Lévénez’s, "UNIX History” landscape format [very wide], lines & arrows, hand drawn, no source <https://www.levenez.com/unix/> David du Colombier, Unix Diagram portrait format, graphviz, source <http://www.unix-diagram.org> Linux Timeline, Fabio Loli et al landscape format, gnuclad, source (CSV + links to <https://distroware.gitlab.io/>) uses ‘curved’ lines, can be changed <https://github.com/FabioLolix/LinuxTimeline> Images: SVG, PNG <https://github.com/FabioLolix/LinuxTimeline/releases/tag/v21.10> Grokline, UNIX TIMELINE, 2004-2009 [dead site] Lists by Date, Vendor, Product detail pages not archived <https://web.archive.org/web/20091217070631/http://www.grokline.net/time_ind…> ============ -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

2 years, 8 months

1
0
0 0

The MGR window system and the Macintosh

by John Floren

Today I came across an article about the MGR window system for Unix: https://hack.org/mc/mgr/ One thing that interested me was a note that some versions worked on the Macintosh: > The window system ran on many different hardware platforms, at least > these: Sun 3/xx workstations running SunOS, which was the the original > development platform, Sun SPARCstations (SunOS and then ported by me to > Solaris), Intel x86 based PCs (Coherent, Minix, FreeBSD or Linux), > Atari ST (under MiNT), AT&T UnixPC (SysV) and the Macintosh. As the owner of a Macintosh Plus, I think it would be a very interesting thing to experiment with, but I haven't had much luck finding any more information about it. Does anyone know more about MGR, particularly on the Mac? That page has the source for MGR 0.69, but there's no mention of the Macintosh in it (aside from comments about how it was supported on older versions...) John

2 years, 8 months

13
21
0 0

Re: "9 skills our grandkids won't have" - Is this a TUHS topic?

by Matthias Bruestle

I know something! On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: > > o why CTRL/S and CTRL/Q are used for flow control in a shell command > > line session > > > Also would be happy to know. https://en.wikipedia.org/wiki/Software_flow_control But I don't know the answer to Ctrl-D. :( And also the bus error and maybe the segmentation fault if it hasn't to do with a segment register. Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine

2 years, 8 months

6
6
0 0

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by Douglas McIlroy

> I heard that the IBM 709 > series had 36 bit words because Arthur Samuel, > then at IBM, needed 32 bits to identify the playable squares on a > checkerboard, plus some bits for color and kinged To be precise, Samuel's checkers program was written for the 701, which originated the architecture that the 709 inherited. Note that IBM punched cards had 72 data columns plus 8 columns typically dedicated to sequence numbers. 700-series machines supported binary IO encoded two words per row, 12 rows per card--a perfect fit to established technology. (I do not know whether the fit was deliberate or accidental.) As to where the byte came from, it was christened for the IBM Stretch, aka 7020. The machine was bit-addressed and the width of a byte was variable. Multidimensional arrays of packed bytes could be streamed at blinding speeds. Eight bits, which synced well with the 7020's 64-bit words, was standardized in the 360 series. The term "byte" was not used in connection with 700-series machines. Doug

2 years, 8 months

5
4
0 0

Extracting files from various old dump/restore tapes

by Lars Brinkhoff

Hello, I have on my hands many images of tapes that seems to have been written by various implementaions of dump. I see the magic numbers 60011 and 60012 in little and big endian at offsets 18 (16-bit version?) and 24 (32-bit version?). I don't know the dating of the tapes, but around 1980 would be a reasonable guess. Are there some easy to use (ready to run on a modern Unix) tools to extract files from such tape files? I'm not looking to restore a file system on disk, just extract the files.

2 years, 8 months

4
9
0 0

DMD 5620 simulator

by Seth Morabito

Hello all, I've recently been improving the AT&T/Teletype DMD 5620 simulator I wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 firmware. It also now supports executing a local shell or connecting directly to a physical or virtual tty device. It runs natively on Linux or macOS with X11 or Wayland, but I would love help creating a Windows version if you're a Windows programmer (I am an occasional Windows user, but I am not at all knowledgeable about Windows programming). Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html The source code is here: https://github.com/sethm/dmd_gtk Many thanks go to my friend Sark (@crtdude on Twitter) for tracking down the 8;7;3 firmware and dumping it for me. I'd also like to thank Mike Haertel for helping find bugs, providing feedback, and inspiring me to get it working with Research Unix in addition to SVR3. Feedback, bug reports, and pull requests are all welcome! -Seth -- Seth Morabito Poulsbo, WA web(a)loomcom.com

2 years, 8 months

12
17
0 0

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by Douglas McIlroy

Anecdote prompted by the advent of Burroughs in this thread: At the 1968 NATO conference on Software Engineering, the discussion turned to language design strategies. I noted that the design of Algol 68, for example, presupposed a word-based machine, whereupon Burroughs architect Bob Barton brought the house down with the remark, "In the beginning was the Word, all right--but it was not a fixed number of bits!" [Algol 68's presupposition is visible in declarations like "long long long ... int". An implementation need support only a limited number of "longs", but each supported variety must have a definite maximum value, which is returned by an "environment enquiry" function. For amusement, consider the natural idea of implementing the longest variety with bignums.] Doug

2 years, 8 months

5
4
0 0

Re: [COFF] Re: Will someone update the 386BSD Wikipedia page for me?

by David Arnold

The error was introduced on 13 September 2005, by an anonymous user from an IP address allocated to Web Perception, a Californian ISP, and (currently) geolocated to Sonoma. The change comment was: Changes - 386BSD factual errors corrected, potentially libelous statements removed, links updated, refocus on 386BSD history, authority-386BSD authors, published works, DMR refs The same IP address was used for a series of edits over 2005-2006, to topics including 386BSD, Lynne Jolitz, William Jolitz, and Radiocarbon Dating. I imagine it was simply a mistake. d > On 10 Sep 2022, at 12:26, Grant Taylor via COFF <coff(a)tuhs.org> wrote: > > On 9/9/22 8:05 PM, Greg 'groggy' Lehey wrote: >> Done. > > Thank you! > >> Do you have an idea about how this error crept in? > > No, I do not. > > I came to this article after reading about the DDJ DVD archive on the geeks mailing list. I was sensitive to the emails about DDJ because I've been looking to acquire the issues (or at least articles) with the Porting Unix to the 386 articles in them. > > Now I have them! :-D > > > > -- > Grant. . . . > unix || die >

2 years, 8 months

6
5
0 0

Happy birthday, Unix timestamp!

by Dave Horsfall

https://www.timeanddate.com/on-this-day/september/9 ``Unix time or Unix epoch, POSIX time or Unix timestamp, is a time system that measures the number of seconds since midnight UTC of January 1, 1970, not counting leap seconds. At 01:46:40 UTC on September 9, 2001, Unix time reached the billionth second timestamp.'' Hard to believe that it was that long ago... -- Dave

2 years, 8 months

5
6
0 0

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by Nelson H. F. Beebe

Paul Winalski and Bakul Shah commented on bit addressable machines on the TUHS list recently. From Blaauw and Brooks' excellent Computer Architecture book http://www.math.utah.edu/pub/tex/bib/master.html#Blaauw:1997:CAC on page 98, I find >> ... >> The earliest computer with bit resolution is the [IBM 7030] Stretch. >> The Burroughs B1700 (1972) and CDC STAR100 (1973) are later examples. >> >> Bit resolution is costly in format space, since it uses a maximum >> number of bits for address and length specification. Sharpening >> resolution from the byte to the bit costs the same as increasing >> address-space size eight-fold. >> >> Since almost all storage realizations are organized as matrices, >> bit resolution is also expensive in time or equipment. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

2 years, 8 months

5
4
0 0

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by norman＠oclsc.org

Doug McIlroy: Bit-addressing is very helpful for manipulating characters in a word-organized memory. The central idea of my ancient (patented!) string macros that underlay SNOBOL was that it's more efficient to refer to 6-bit characters as living at bits 0,6,12,... of a 36-bit word than as being characters 0,1,2,... of the word. I've heard that this convention was supported in hardware on the PDP-10. ==== Indeed it was. The DEC-10 had `byte pointers' as well as (36-bit) word addresses. A byte pointer comprised an address, a starting bit within the addressed word, and a length. There were instructions to load and store an addressed byte to or from a register, and to do same while incrementing the pointer to the next byte, wrapping the start of the next word if the remainder of the current word was too small. (Bytes couldn't span word boundaries.) Byte pointers were used routinely to process text. ASCII text was conventionally stored as five 7-bit bytes packed into each 36-bit word. The leftover bit was used by some programs as a flag to mean these five characters (usually the first of a line) were special, e.g. represented a five-decimal-digit line number. Byte pointers were used to access Sixbit characters as well (each character six bits, so six to the word, character set comprising the 64-character subset of ASCII starting with 0 == space). Norman Wilson Toronto ON (spent about four years playing with TOPS-10 before growing up to play with UNIX)

2 years, 8 months

2
1
0 0

Re: Happy birthday, Unix timestamp!

by norman＠oclsc.org

Andrew Hume: if i recall correctly, V1 of Unix had time measured in milliseconds. were folks that sure that this would change before wrap-around? ==== Not milliseconds (which were infinitesimally small to the computers of 1969!) but clock ticks, 60 per second. Initially such times were stored in a pair of 18-bit PDP-7 words, giving a lifetime of about 36 years, so not so bad. The PDP-11's 16-bit words made that a 32-bit representation, or about two and a quarter years before overflow. Which explains why the time base was updated a few times in early days, then the representation changed to whole seconds, which in 32 bits would last about as long as 36 bits of 60 Hz ticks. The PDP-7 convention is documented only in the source code, so far as I know. The evolution of time on the PDP-11 can be tracked in time(II) in old manuals; the whole-seconds representation first appears in the Fourth Edition. Norman Wilson Toronto ON Not that old a timer, but once looked into old time

2 years, 8 months

1
0
0 0

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by jnc＠mercury.lcs.mit.edu

> From: Jim Capp > See "The Preparation of Programs for an Electronic Digital Computer", > by Maurice V. Wilkes, David J. Wheeler, and Stanley Gill Blast! I looked in the index in my copy (ex the Caltech CS Dept Library :-), but didn't find 'word' in the index! Looking a little further, Turing's ACE Report, from 1946, uses the term (section 4, pg. 25; "minor cycle, or word"). My copy, the one edited by Carpenter and Doran, has a note #1 by them, "Turing seems to be the first user of 'word' with this meaning." I have Brian's email, I can ask him how they came to that determination, if you'd like. There aren't many things older than that! I looked quickly through the "First Draft on the EDVAC", 1945 (re-printed in "From ENIAC to UNIVAC", by Stein), but did not see word there. It does use the term "minor cycle", though. Other places worth checking are the IBM/Harvard Mark I, the ENIAC and ... I guess therer's not much else! Oh, there was a relay machine at Bell, too. The Atanasoff-Berry computer? > From: "John P. Linderman" > He claims that if you wanted to do decimal arithmetic on a binary > machine, you'd want to have 10 digits of accuracy to capture the 10 > digit log tables that were then popular. The EDVAC draft talks about needing 8 decimal digits (Appendix A, pg.190); apparently von Neumann knew that that's how many digits one needed for reasonable accuracy in differential equations. That is 27 "binary digits" (apparently 'bit' hadn't been coined yet). Noel

2 years, 8 months

5
4
0 0

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by Douglas McIlroy

> Doug or anyone, why do bit pointers make sense? Why? Bit-addressing is very helpful for manipulating characters in a word-organized memory. The central idea of my ancient (patented!) string macros that underlay SNOBOL was that it's more efficient to refer to 6-bit characters as living at bits 0,6,12,... of a 36-bit word than as being characters 0,1,2,... of the word. I've heard that this convention was supported in hardware on the PDP-10. In the IBM 7020 floats and ints were word-addressed. But those addresses could be extended past the "decimal point" to refer to bits. Bits were important. The computer was designed in parallel with the Harvest streaming "attachment" for NSA. Harvest was basically intended to gather statistics useful in code-breaking, such as frequency counts and autocorrelations, for data typically encoded in packed 5- to 8-bit characters. It was controlled by a 20-word "setup" that specified operations on rectangular and triangular indexing patterns in multidimensional arrays. Going beyond statistics, one of the operations was SQML (sequential multiple lookup) where each character was looked up in a table that specified a replacement and a next table--a spec for an arbitrary Turing machine that moved its tape at byte-streaming speed! Doug

2 years, 8 months

1
0
0 0

Re: Happy birthday, Unix timestamp!

by Douglas McIlroy

> Well, you can imagine what happened when the leading digit changed > from an ASCII "9" to an ASCII "1". Oops. I first saw a time-overflow bug more than 60 years ago. Accounting went haywire in the Bell Labs' comp center on day 256 of the year, when the encoded output of a new time clock reached the sign bit. Doug

2 years, 8 months

2
1
0 0

Re: Re-implementations/Clean-Rooms et al.

by Clem Cole

On Thu, Sep 8, 2022 at 12:51 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote: > Both Coherent and 4.4BSD have stuck out to me as examples of > not-quite-so-clean-room implementations that did well enough (more than > enough for BSD) and didn't die a fiery death in litigation (as much as USL > tried...). Be careful with that statement both parts of it are not wholly on target. In the first, AT&T chose not to litigate against Coherent fully. As was pointed out, Dennis and the team that examined the code base determined it was 'clean enough.' If I recall, his comment was something like "It was clear they had seen and had access to the AT&T IP at some point, most likely at University (IIRC many of the founders were ex-University Waterloo), but they did not find evidence of direct copying of files." BSDi/UCB *vs. *USL was a different kettle of fish altogether. As has been discussed here extensively (and needs not to be repeated), that suit was about *Trade Secrets and >>ideas<< that make up what we call UNIX.* The real interesting thing about that case is that had USL/AT&T won, the repercussions for the industry would have been way beyond just BSDi - *but all of the UNIX clones* and many of us on this list who had been "mentally contaminated" with AT&T's ideas (I still have my 'mental contamination' button somewhere in my archives). The good news is that the US courts had the good sense to realize that the moment the US Gov put the consent decree down in 1956 and required that AT&T make their IP available and then enabled AT&T had its people start to write about their work in the open literature (in UNIX's case the original CACM paper, but continuing with all the books, follow on papers, etc), plus being such wonderfully active participants in the research community at large, it could not be called a secret. > What I find interesting is that in this day and age, it seems there is > almost a requirement for true "clean-room" implementation if something is > going to be replicated, which I understand to mean the team developing the > new implementation can't be the same team that performed a detailed > analysis of the product being reimplemented, but the latter team can > produce a white paper/writeup/memorandum describing the results of their > analysis and the development team can then use that so long as it doesn't > contain any implementation details. > It's not "day and age" it's from the original case law -- the term was coined by the late Arthur Kahn, Esquire who was the lead attorney for Franklin Computers, Inc in the Franklin *vs.* Apple Case - which he originally won and ultimately lost on appeal [Good guy BTW, particularly for a non-technically trained person - he 'got it']. The concept is that one group is in a dirty room and the other in a clean room. Information is unidirectional. The dirty room can read published documentation, probe, and test the device/implementation using standard programming techniques. And then write a new document that describes the functionality of the device in question. Then hand it to the folks in the clean room who can reimplement a device to that new specification. The point of contention in the case is if *the original documentation for the device*, in this case, the Apple Assembler listing for Wos's Apple-II ROMs were protected by copy once they had been transformed from their printed form in Apple;'s red books into the binary and stored in the ROMS themselves. Franklin's 'dirty room' ultimately wrote a series of test programs that demonstrated each of the externally available locations and entries in the ROMs. This they documents and their new clean-room programmers wrote a new set of ROM that duplicated the functionality. IIRC the story is that Franklin ROMs were a few bytes smaller in the end. Compaq would later the same scheme for the IBM PC. > I would assume the current definition of a clean-room implementation only > requires that the developers/implementors don't have access to the code of > the parent product (source or reverse engineered), but could read manuals, > study behavior in-situ, and use that level of "reverse engineering" to > extract the design from the implementation, so not knowing the gritty > details, Coherent could be a true clean-room. > Be careful here. I used to work for a firm that did a lot of work for different vendors that would build some of these clean-room sub-systems (in fact for some of the folks -- at least one -- of the readers of this list). We were always careful for the clean-room people to be ones we were fairly sure had not seen that customers product previously. I was almost always on the 'dirty' team in many of those projects because I was so contaminated with the IP of so many of our customers' work. Because we worked for IBM, Sun, DEC, HP, DG, AT&T, *etc*. all at the same time had their IP in-house we had very strict rules about how things were handled. Even what sites and what sub-nets data could be on -- which system admins had the passwords. No one person had access to all of the passwords. We had a locked safe for each customer with secure things like passwords (really) and rooms with locks and videos, and access doors. It was really serious stuff. Frankly, I think part of why we got some of the "work for hires" tasks was because those firms trusted us to handle their IP properly. No way did we want to contaminate something accidentally. Some projects like our big TNC [Transparent Network Computing] system we were working on for all of IBM, DEC, HP, and Intel simultaneously -- 4 different teams. The architects could talk to each other, and we talked about common issues, but it was a different code. I know we implemented things a couple of times - although we got smarter. For instance, the original RPC marshaling was done for IBM with 'the awk script from hell' which later became an interface generator that all four teams used. > > BSD is a different beast, as they were literally replacing the AT&T source > code before their eyes, so there isn't much argument that can be made for > 4.4BSD being a "clean-room" implementation of UNIX. It was not a clean-room as Arthur defined it. It was rewritten over time, which replaced AT&T's implementation. Which is all that was ever claimed. > Given that, that's one of the more surprising things to me about 4.4BSD > prevailing in the lawsuit, because while Berkeley could easily prove that > they had replaced most of AT&T's code, there's still the fact that their > team did have complete and unfettered access to Bell UNIX code at least > circa 32V. I expect this is because you don't quite understand what happened. > but I remember reading somewhere that CSRG students and faculty avoided > commercial UNIX like the plague, Hmmm, I read it on the Internet -- it must be true ;-) CSRG had Ultrix/VAX, SunOS/3, and I believe HP-UX/PA sources. They shipped several DEC-developed drivers in 4.1A/4.1B/4.1C -- Sam, Bill Shanon, and I tested a couple of them on one of my machines in Cory Hall as DEC has donated one of the 3 CAD machines [UCBCAD - a.k.a. 'coke' ], and it was the only 'pure' DEC machine on campus - without any 3rd party HW in it. After I graduated, I suspect Sam continued the relationship with Tom Quarles, so 4.2BSD was likely tested on that system too. But I know the RH-based TAPES and DISKs were all straight from Shannon's SCCS Ultrix repo as he sent them to me to try before I gave them to Sam. > Does anyone know if there was a "formal" PDP-11 and/or VAX disassembler > produced by Bell? Most of the compiler kits have disassemblers, as do many debuggers -- what are you asking? > saying something to the effect "Rumor has it there is a PDP-11 > disassembler" but I'm curious if such tools were ever provided in any sort > of official capacity. > In the mid/late-70s (*i.e.* V6/V7 time frame) there are a couple of them -- where to start -- V7 has one inside of adb, and if I recall later versions of PCC2 has one. But if you look in the USENIX tapes you can find a couple of pretty well-adorned ones. There was one that IIRC was done by ??Cooper Union?? guys that spit out DEC MACRO-11 syntax for the Harvard assembler. That should be on the TUHS archives. Thinking about it, Phil Karn had one too that did some interesting label patch-up IIRC - which I think he brought with him to CMU from somewhere -- but I may be miss remembering that.

2 years, 8 months

4
11
0 0

"... interesting old-timey UNIXes ..." (cross post from geeks)

by Grant Taylor

Hi, The following comment was made on the geeks mailing list and I figured it was worth cross posting to the TUHS mailing list. -- I'm BCCing the original poster so that they are aware of the cross post and in case they want to say more. --8<-- In related news that might entertain and inform, there are some interesting old-timey UNIXes out there that I've come across recently though: XV6: https://pdos.csail.mit.edu/6.828/2012/xv6.html OMU: http://www.pix.net/mirrored/discordia.org.uk/~steve/omu.html V7/x86: https://www.nordier.com/ RUnix and Singlix: https://www.singlix.com/runix/ -->8-- I don't know if any of it should be included in the TUHS archives or not. -- I figure discussing it on TUHS is the best way to find out. P.S. Re-sending to the correct TUHS email address. Somehow I had something on file reflecting the old server. :-/ -- Grant. . . . unix || die

2 years, 8 months

1
0
0 0

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by jnc＠mercury.lcs.mit.edu

> It was used, in the modern sense, in "Planning a Computer System", > Buchholz,1962. Also in the IBM "650 Manual of Operation", June, 1955. (Before I was born! :-) Noel

2 years, 8 months

2
1
0 0

Re: Does anybody know the etymology of the term "word" as in collection of bits

by jnc＠mercury.lcs.mit.edu

> On Sep 8, 2022, at 9:51 AM, Jon Steinhart <jon(a)fourwinds.com> wrote: > One of those questions for which there is no search engine incantation. Whatever it is, it's really old. I found it used, not quite in the modern sense, in "Hi-Speed Computing Devices", by ERA, 1950. It was used, in the modern sense, in "Planning a Computer System", Buchholz,1962. Noel

2 years, 8 months

2
1
0 0

Re: Has this been discussed on-list? How Unix changed Software.

by Douglas McIlroy

> (Research) Unix ... 'shipped' with zero known bugs. It wasn't a Utopia. Right from the start man pages reported BUGS, though many were infelicities, not implementation errors. Dennis once ran a demo of a ubiquitous bug: buffer overflow. He fed a 2000-character line on stdin to every program in /bin. Many crashed. Nobody was surprised; and nobody was moved to fix the offenders. The misdesign principle that "no real-life input looks like that" fell into disrepute, but the bad stuff lived on. Some years down the road a paper appeared (in CACM?) that repeated Dennis's exercise. > An emergent property is "Good Security” Actually security (or at least securability) was a conscious theme from the start to which Ken, Bob Morris, and Fred Grampp gave serious attention. Networking brought insecurity, especially to Berkeley Unix. But research was not immune; remote execution via uucp caused much angst, but not enough to kill it. In regards to the basic question. To oversimplify: Theme 1. Unix facilities encouraged what Brian recognized and proselytized as software tools. Theme 2. OS portability was new and extraordinarily final. Subsequent OS's were all portable and were all Unix. Doug

2 years, 8 months

9
15
0 0

Does anybody know the etymology of the term "word" as in collection of bits?

by Jon Steinhart

One of those questions for which there is no search engine incantation. Jon

2 years, 8 months

3
2
0 0

"dmd-pgmg" Toolchest package (SysV 5620+630 version of Sam)

by Mike Haertel

Does anybody out there have a copy of the old AT&T Toolchest "dmd-pgmg" package? This apparently includes the a SysV port of Sam for 5620/630 as well as other programs for the AT&T windowing terminals.

2 years, 8 months

1
0
0 0

Has this been discussed on-list? How Unix changed Software.

by steve jenkin

I’ve been looking at this question for a time and thought it could’ve appeared on the TUHS list - but don’t have an idea of the search terms to use on the list. Perhaps someone suggest some to me. As a starting point, below is what John Lions wrote on a similar topic in 1978. Conspicuously, “Security” is missing, though “Reliability & Maintenance” would encompass the idea. With hindsight, I’d suggest (Research) Unix took a very strong stance on “Technical Debt” - it was small, clean & efficient, even elegant. And ‘shipped' with zero known bugs. It didn’t just bring the Unix kernel to many architectures, the same tools were applied to create what we now call “Open Source” in User land: - Multi-platform / portable - the very act of porting software to diverse architectures uncovered new classes of bugs and implicit assumptions. Big- & Little-endian were irrelevant or unknown Before Unix. - full source - compatibility layers via - written in common, well-known, well-supported languages [ solving the maintenance & update problem ] - standard, portable “toolchains” - shell, make, compiler, library tools for system linker, documentation & doc reading tools - distribution systems including test builds, issue / fault reporting & tracking An emergent property is "Good Security”, both by Design and by (mostly) error-free implementations. In the Epoch Before Unix (which started when exactly?), there was a lot of Shared Software, but very little that could be mechanically ported to another architecture. Tools like QED and ROFF were reimplemented on multiple platforms, not ‘ported’ in current lingo. There are still large, complex FORTRAN libraries shared as source. There’s an important distinction between “Open” and “Free” : cost & availability. We’ve gone on to have broadband near universally available with easy to use Internet collaboration tools - e.g. “git”, “mercurial” and “Subversion” just as CVS’s. The Unix-created Open Source concept broke Vendor Lock-in & erased most “Silos”. The BSD TCP/IP stack, and Berkeley sockets library, were sponsored by DARPA, and made freely available to vendors as source code. Similarly, important tools for SMTP and DNS were freely available as Source Code, both speeding the implementation of Internet services and providing “out of the box” protocol / function compatibility. The best tools, or even just adequate, became only a download & install away for all coding shops, showing up a lot of poor code developed by in-house “experts” and radically trimming many project schedules. While the Unix “Software Tools” approach - mediated by the STDOUT / STDIN interface, not API’s - was new & radical, and for many classes of problems, provided a definitive solution, I’d not include it in a list of “Open Source” features. It assumes a “command line” and process pipelines, which aren’t relevant to very large post-Unix program classes: Graphical Apps and Web / Internet services. regards steve jenkin ============== Lions, J., "An operating system case study" ACM SIGOPS Operating Systems Review, July 1978, ACM SIGOPS Oper. Syst. Rev. 12(3): 46-53 (1978) 2. Some Comments on UNIX ------------------------ There is no space here to describe the technical features of UNIX in detail (see Ritchie and Thompson, 1974 ; also Kernighan and Plauger, 1976), nor to document its performance characteristics, which we have found to be very satisfactory. The following general comments do bear upon the present discussion: (a) Cost. UNIX is distributed for "academic and educational purposes" to educational institutions by the Western Electric Company for only a nominal fee, and may be implemented effectively on hardware configurations costing less than $50,000. (b) Reliability and Maintenance. Since no support of any kind is provided by Western Electric, each installation is potentially on its own for software maintenance. UNIX would not have prospered if it were not almost completely error-free and easy to use. There are few disappointments and no unpleasant surprises. (c) Conciseness. The PDP-11 architecture places a strong limitation on the size of the resident operating system nucleus. As Ritchie and Thompson (1974) observe, "the size constraint has encouraged not only economy but a certain elegance of design". The nucleus provides support services and basic management of processes, files and other resources. Many important system functions are carried out by utility programs. Perhaps the most important of these is the command language interpreter, known as the "shell". (Modification of this program could alter, even drastically, the interface between the system and the user.) (d) Source Code. UNIX is written almost entirely in a high level language called "C" which is derived from BCPL and which is well matched to the PDP-11. It provides record and pointer types, has well developed control structures, and is consistent with modern ideas on structured Programming. (For the curious, the paper by Kernighan (1975) indirectly indicates the flavour of "C" and exemplifies one type of utility program contained in UNIX.) Something less than i0,000 lines of code are needed to describe the resident nucleus. pg 47 (e) Amenability. Changes can be made to UNIX with little difficulty. A new system can be instituted by recompiling one or more files (at an average of 20 to 30 seconds per file), relinking the file containing the nucleus (another 30 seconds or so), and rebooting using the new file. In simple cases the whole process need take no more than a few minutes. (f) Intrinsic Interest. UNIX contains a number of features which make it interesting in its own right: the run-time support for the general tree structured file system is particularly efficient; the use of a reserved set of file names smooths the concepts of device independence; multiple processes (three or four per user is average) are used in a way which in most systems is regarded as totally extravagant (this leads to considerable simplification of the system/user interface); and the interactive intent of the system has resulted in an unusually rich set of text editing and formatting programs. (g) Limitations. There are few limitations which are of concern to us. The PDP-11 architecture limits program size, and this for example frustrated an initial attempt to transfer Pascal P onto the 11/40. Perhaps the greatest weakness of UNIX as it is presently distributed (and this is not fundamental!) is in the area where other systems usually claim to be strong: support for "bread and butter" items such as Fortran and Basic. (h) Documentation. The entire official UNIX documentation, including tutorial material, runs to less than 500 pages. By some standards this is incredibly meagre, but it does mean that student can carry his own copy in his brief case. Features of the documentation include: - an unconventional arrangement of material (unsettling at first, but really very convenient); - a terse, enigmatic style, with much information conveyed by innuendo; - a permuted KWIC index. Most importantly perhaps UNIX encourages the programmer to document his work. There is a very full set of programs for editing and formatting text. The extent to which this has been developed can be gauged from the paper by Kernighan and Cherry (1975). ============== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

2 years, 8 months

9
13
0 0

Re: Has this been discussed on-list? How Unix changed Software.

by Douglas McIlroy

>> a paper appeared (in CACM?) that repeated Dennis's exercise. > Maybe this one? > B.P. Miller, L. Fredriksen, and B. So, "An Empirical Study of the Reliability > of UNIX Utilities", Communications of the ACM 33, 12 (December 1990). > http://www.paradyn.org/papers/fuzz.pdf Probably. I had forgotten that the later effort was considerably more elaborate than Dennis's. It created multiple random inputs that might stumble on other things besides buffer overflow. I see a Unix parable in the remarkable efficacy of Dennis's single-shot test. Doug

2 years, 8 months

1
0
0 0

i386 binary of 4.4BSD-Alpha

by MOCHIDA Shuji

I added i386 binary compiled from 4.4BSD-Alpha source. http://www.netside.co.jp/~mochid/comp/bsd44-build/ Boot with bochs works rather well. qemu-system-i386 also boots, and NIC (NE2000 ne0) works good, but kernel prints many "ISA strayintr" messages. I got many useful infomations from below 2 sites: "Fun with virtualization" https://virtuallyfun.com/ 386bsd bochs qemu "Computer History Wiki!" https://gunkies.org/wiki/Main_Page Installing 386BSD on BOCHS First time, I tried to compile i386 using 4.4BSD final (1995) source, patching many many pieces from 386BSD, NetBSD, and else.. but then, I felt "Well, we have BSD/OS 2.0, NetBSD 1.0, and FreeBSD 2.0 those are full of good improvements.." So, I changed target, and remebered Pace Willisson's memo in 4.4BSD (and in 4.4BSD-Lite2 also) sys/i386/i386/README: "4.4BSD-alpha 80386/80486 Status" June 20, 1992 that file says "can be compiled into a fairly usable system". yeah, needed chages not so small, though. -mochid

2 years, 8 months

1
0
0 0

PCC Revived is back up

by Arnold Robbins

Hi All. Thanks to Jeremy C. Reed who's email to the maintainer got the PCC Revived website and CVS back up. Thanks to everyone who let me know that it's back up. :-) My github mirror is https://github.com/arnoldrobbins/pcc-revived and there are links there to the website etc. My repo has a branch 'ubuntu18' with diffs for running PCC on Ubuntu, if that interests anyone. Enjoy, Arnold

2 years, 8 months

2
1
0 0

off topic: whither the pcc-revived project?

by arnold＠skeeve.com

Hi. I'm hoping some of the BSD people here may know. I've been keeping a git mirror of the PCC Revived project, but in the past month or so it's gone dark. The website is no longer there, the CVS repos don't answer, and an email to the mailing list went unanswered. Does anyone know anything about it? Did it move to somewhere else? I use pcc for testing, it's much faster than GCC and clang. And in general, I think it's a cool thing. :-) Thanks, Arnold

2 years, 9 months

1
0
0 0

Re: Nice video with Brian Kernighan

by Douglas McIlroy

Brian's tribute to the brilliant regex mechanism that awk borrowed from egrep spurred memories. For more than forty years I claimed credit for stimulating Ken to liberate grep from ed. Then, thanks to TUHS, I learned that I had merely caused Ken to spring from the closet a program he had already made for his own use. There's a related story for egrep. Al Aho made a deterministic regular-expression recognizer as a faster replacement for the non-deterministic recognizer in grep. He also extended the domain of patterns to full regular expressions, including alternation; thus the "e" in egrep. About the same time, I built on Norm Shryer's personal calendar utility. I wanted to generalize Norm's strict syntax for dates to cover most any (American) representation of dates, and to warn about tomorrow's calendar as well as today's--where "tomorrow" could extend across a weekend or holiday. Egrep was just the tool I needed for picking the dates out of a free-form calendar file. I wrote a little program that built an egrep pattern based on today's date. The following mouthful for Saturday, August 20 covers Sunday and Monday, too. (Note that, in egrep, newline is a synonym for |, the alternation operator.) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*20)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*21)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*22)([^0123456789]|$) It worked like a charm, except that it took a good part of a minute to handle even a tiny calendar file. The reason: the state count of the deterministic automaton was exponentially larger than the regular regular expression; and egrep had to build the automaton before it could run it. Al was mortified that an early serious use of egrep should be such a turkey. But Al was undaunted. He replaced the automaton construction with an equivalent lazy algorithm that constructed a state only when the recognizer was about to visit it. This made egrep into the brilliant tool that Brian praised. What I don't know is whether the calendar program stimulated the idea of lazy implementation, or whether Al, like Ken before him with grep, already had the idea up his sleeve. Doug

2 years, 9 months

5
7
0 0

Nice video with Brian Kernighan

by Arnold Robbins

https://www.youtube.com/watch?v=GNyQxXw_oMQ Not quite 30 minutes long. Mostly about the history of awk but some other stuff, including a nice plug for TUHS at the end. Arnold

2 years, 9 months

3
2
0 0

Editor for Mortals History

by Joseph Holsten

Hello everyone! I’ve been digging into text editor history, and I found: “This provided another huge step forward in usability and allowed us to maintain our modeless approach to screen editing, which was, we feel, superior to the Vi approach.” from https://www.coulouris.net/cs_history/em_story/ This makes me want to know em’s history outside the usual precursor-to-vi narrative. Does anyone know much about the timeline of em from 1971 (QMC Unix installation) to 1976 (Intro to W M Joy @ UCB)? And does anyone know of developments to it after 1976-04-29? That’s the last date within text in the https://www.coulouris.net/cs_history/em_story/emsource/ files. (Also grumble grumble broken touch feature detection in that shar, which indicates last mod of 1996-02-18). Anyone other than Coulouris used em in the last 45 years? -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-360-927-7234

2 years, 9 months

1
0
0 0

PCS Munix kernel source

by Paul Ruizendaal

> Message: 4 > Date: Wed, 10 Aug 2022 12:29:24 +0200 > From: Holger Veit <hveit01(a)web.de> > Subject: [TUHS] PCS Munix kernel source > > Hi all, > > I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to > https://github.com/hveit01/pcs-munix. Thank you for sharing this work, most impressive! > MUNIX was an AT&T SVR3.x implementation ... Are you sure? Could it perhaps be SVR2? (I don’t see any STREAMS stuff that one would expect for R3). > The interesting feature of this kernel is the integration of the > Newcastle Connection network One of my interests is Unix (packet) networking 1975-1985 and that includes Newcastle Connection. I’ve so far not dived deep into this, but your work may be the trigger for some further investigation. My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail. I note that the repo Readme says that the kernel only does some basic IP networking as a carrier, but I also see some files in the tree that seem to implement a form of tcp (and that seem unrelated to the early Unix tcp/ip’s that I have seen so far). Or am I reading too much into these files? === Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership? The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership?

2 years, 9 months

3
3
0 0

Re: Documents for UNIX Collections

by Paul Ruizendaal

> And I've received the documents! This is a pastebin with the rough contents of the documentation package. > > https://pastebin.com/jAqqBXA4 <https://pastebin.com/jAqqBXA4> > > Now for some analysis: I’m interested in the journey of SysV IPC. So far I have established that these originated in CBUnix, with a lot of thinking on how to optimize these around the time that Unix 3.0/4.0/5.0 happened. They did not appear in Unix 3.0 / SysIII, and from the Unix 4.0 documentation I gather that it was not included there either. This would make Unix 5.0 / SysV R1 the first release with what is now known as SysV IPC. The PDP11 version of R1 has the CBUnix version of shared memory, as the VAX version did not make sense in the limited address space of the PDP11. From the pastebin summary, it would seem that IPC is not in this documentation either? That would be surprising, and reopens the possibility that IPC was part of Unix 4.0 Paul

2 years, 9 months

4
5
0 0

Re: SNOBOL and RATSNO

by Douglas McIlroy

> I've always believed that pic was so well designed > because it took a day to get the print out (back then), I'm afraid this belief is urban legend. Credit for pic is due 100% to Kernighan, not to the contemporary pace of computing practice. Even in the 1950s, we had one-hour turnaround at Bell Labs. And the leap from batch processing had happened well before pic. Turnaround on modest Unix source files and tests has changed little in the past fifty years. Doug

2 years, 9 months

10
18
0 0

SysIII and SysV Feature Lineage (was: Documents for UNIX Collections)

by segaloco

Thread fork as we're drifting from documentation research specifically. One matter that keeps coming to mind for me is the formal history of the runlevel-based init system. It isn't in Research obviously, nor was it in PWB. The first time it shows up in the wild is System III, but this version is slightly different than what was in CB-UNIX at the time, which is what eventually wound up in System V. The pressing question is whether the version in System III represents an earlier borrowing from CB or if perhaps the runlevel init started in USG, got bumped over to CB and improved, then that improved version came back to supported UNIX in 5.0. As for the notable differences: SysIII init allows for runlevels 1-9. It will call /etc/rc with the current state, the prior state, and the number of times the current state has been entered. If the script is called for instance due to a powerfailure, then the current state is passed suffixed with an 'x'. The inittab entries are in a different format: state:id:flags:process Where state is the runlevel, id is a two-character identifier, flags can be either 'c' (like respawn) or 'o' (like off I think). No flag then indicates to run once. Flags 't' or 'k' will terminate or kill a process before it is started again if a given runlevel is entered and it is already running. This of course is in contrast to SysV init which instead offers runlevels 0-6 as well as a, b, and c. Init itself can be called with runlevels S|s or Q|q additionally and these act as calls to enter single user mode or rerun the current init state if I'm understanding correctly. Neither S nor Q options appear to be valid for the inittab runlevel. Init tab entries here are: id:rstate:action:process Where id and rstate are essentially just the same fields from SysIII swapped. Action replaces the flags field with the more well known respawn, wait, once, initdefault, etc. behaviors. All in all, different enough that inittabs between the two wouldn't be compatible. SysV also includes the telinit command which appears to be able to handle those a, b, and c runlevels. Anywho, that's my understanding of the init changes, with the pertinent question remaining whether the SysIII-style init ultimately started from the same place as SysV, or if the general design idea was there between USG and CB, and they got to a similar answer from different directions. Colon-delimited /etc files aren't uncommon, so while unlikely, it could be entirely possible the two inittab formats arose relatively independently, but the truth remains obscure in my mind at least. I don't really blame Research for not picking up this init system, it seems like there were a few parallel streams of development around the turn of the 80s, and the easier answer was probably to just stay the course. I seem to recall reading in a thread somewhere Rob Pike discussing the resistance in the Research group regarding sucking up each and every little feature USG tried to promulgate as standard, and this init system got specific mention. - Matt G.

2 years, 9 months

1
0
0 0

Re: Documents for UNIX Collections

by segaloco

And I've received the documents! This is a pastebin with the rough contents of the documentation package. https://pastebin.com/jAqqBXA4 Now for some analysis: The User's Manual is branded System V but also displays a Western Electric Bell logo. I've seen Release 5.0 manuals displaying the Bell logo and System V manuals without, but never a System V with. That implies the publication of the manual had to change a few times, one to switch from internal Release 5.0 to commercial System V and another time to remove the Bell logo due to divestiture. I would have to wonder if similar transition can be seen with different revisions of these documents? The Release Description manual has a list of System V relevant documents and they all appear to be accounted for here, so this should represent the wealth of documentation available to a user of System V Gold in 1983. Most documents are traceable to documents in the Unix 4.0 collection. I've suffixed various documents here with the coordinate to the same in the 4.0 collection. Changes of note: - The System V documentation includes instructions for 3B20S machines as well as the instructions for DEC equipment. PDP-11 and VAX guidance have been combined into a single document. - The System V documentation adds documents concerning an "Auto Call" feature. Didn't see this anywhere in 4.0, so should be new circa System V. - This documentation refers to the last version as System III rather than making any mention of 4.0. Given that the specific documents mentioning this are System V-branded, and there are comparable documents that are Release 5.0 branded, this implies there may be a document floating around out there somewhere equivalent to the Release Description manual but that actually covers the transition from 4.0 to 5.0. - The documentation package drops the updated CACM paper, likely because it's available all sorts of other places. - The summary and documentation roadmap documents appear to have been synthesized and combined into the Release Description. - Snyder and Mashey's shell tutorial was either dropped or combined with Bourne's shell introduction - No evidence of an MM foldout like was distributed with 4.0 (and before, there are sources around implying these foldouts started with the PWB group, may have been printed as early as 1977) - Either the original EQN paper is dropped or relevant bits mashed together with the user's guide - EFL documentation seems to be dropped, or is merged into one of the other Fortran documents somewhere down in there. The processor is still in the man pages though. - ADB documentation seems to be dropped, likewise still in the manuals, listed as DEC only. Since System V seems to treat DEC as PDP-11+VAX, does this imply there was a VAX ADB? My understanding is SDB started on 32V and was *the* debugger for VAX. - Unix Virtual Protocol papers are dropped, they were marked as 3.0 only in the 4.0 manuals anyhow, so probably not relevant. - The Standalone I/O Library and SASH (Shell) paper is dropped - None of the internals nor security papers seem to have made it, so no Unix Implemention, I/O Implementation, PDP and Portable C Compiler Tours, Assembler Manual, PDP-11/23 and 11/34, or Password Security papers. These will likely be a slower burn than the 4.0 documents since I purchased them myself and am not in a hurry to get them shipped back to someone. That said, if there's anything in the above pastebin that particularly piques any interest, I can try to move those to the top of the stack and get scans done sooner rather than later. I'll also be doing some analysis between these and the 4.0 docs to try and better determine authorship of various documents, my hope is to have a pretty clear picture of whos work went into each manual by the time I'm done with it all. - Matt G.

2 years, 9 months

3
2
0 0

Re: SNOBOL and RATSNO

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > I still marvel at the productivity and precision of his generatio We noticed the same thing happening in the IETF, as the number of people working on networking went up. The explanation is really quite simple, once you think about it a bit. If you have a very small group, it is quite possible to have a very high level. (Not if it's selected randomly, of course; there has to be some sorting function.) However, as the group gets much larger, it is _necessarily_ much more 'average' in the skill/etc level of its members. This rule applies to any group - which includes the members of TUHS, of course. Noel

2 years, 9 months

9
11
0 0

PCS Munix kernel source

by Holger Veit

Hi all, I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to https://github.com/hveit01/pcs-munix. MUNIX was an AT&T SVR3.x implementation for the German PCS Cadmus workstations in the 80's. They were based on Motorola 68020 CPUs on a DEC QBUS. The interesting feature of this kernel is the integration of the Newcastle Connection network (https://en.wikipedia.org/wiki/Newcastle_Connection) which I found, beyond a tech report https://assets.cs.ncl.ac.uk/TRs/175.pdf, no further references for. The kernel source was reverse engineered and verified (see readme in the distribution who this was done) from the binary tape at ftp.informatik.uni-stuttgart.de/pub/cm/pcs/sw/IS0371P.tap (Computer museum of the University of Stuttgart), and to my knowledge reveals the Newcastle connection code for the first time in a commercial Unix. The Github package includes the kernel sources, i/O drivers, several standard libraries, the disassembled boot ROM and for reference, two of my tools, a partial syscall emulator pcsrun which allowed me to run the C compiler and other native binaries outside the PCS hardware/Unix environment, and a disassembler pcsdis for the specific COFF dialect (note that IDA will produce garbage without a specific patch). Regards Holger

2 years, 9 months

3
2
0 0

Line Numbers Before SysIII nl? BSD num?

by segaloco

I've been looking into the history of the nl command lately, which has gotten me curious as to what facilities folks have used at various points in UNIX history for line numbering. The earliest version of nl I've found is in System III, and it does not derive from Research, PWB, or CB. Neither does it come from BSD, although BSD has the num command which, according to the source commentary, aims to replicate the '#' behavior of ex. Were there any other facilities for printing back arbitrary lines from a file with line numbers? Also, would anyone happen to know if the above appearance of nl might have been from the USG line given none of the others feature it? It neither seems to be in V8-V10. nl has managed to find its way into the POSIX standard, so it definitely has some staying power wherever it came from. - Matt G.

2 years, 9 months

23
36
0 0

Likelihood of Extant Less-Distributed Tapes and Sources

by segaloco

Good morning everyone. Wanted to pose the question since folks here would probably be more likely to know than anyone. What are the chances that there are surviving tapes of some of the UNIX versions that weren't so well publicized. The versions that come to mind are the CB and USG lines especially, with PWB 2.0 and TS 4.0 getting honorable mention. If folks will recall, we did luck out in that Arnold, a member of this mailing list, did have a documentation trove from TS 4.0, but no binary or source code assets. This had me curious on what trying to unearth these would even look like. Has anyone tried to dive deep on this sort of stuff before? Would it look more like trying to find old Bell facilities that might have a tape bumping around in a box in a basement somewhere, or is it more likely that if anything survived it would have been due to being nabbed by an employee or contractor before disposal? Or even just in general, what would folks say is the likelihood that there is a recoverable tape of any of this material just waiting to see the light of day? The closest we have on CB is a paper scan of the kernel sources, and I don't know that any assets from USG-proper have ever percolated up, closest thing to any of that would be the kernel routine description bumping around on the archive somewhere. PWB 2.0 is mentioned in several places, but no empirical evidence has surfaced as far as I know, and with 4.0 of course we have the documents Arnold thankfully preserved, but that's it. Thanks in advance for any insight or thoughts. My concern is that there is a rapidly closing window on ever being able to properly preserve these parts of the UNIX story, although recognition must be paid to all of the hard work folks have done here thus far to keep this valuable part of computing history in the collective consciousness and accessible to researchers and programmers for years and years to come. - Matt G. P.S. Even more honorable mention is the Bell Interdata 8/32 work. I've read several places that never saw outside distribution, but I would have to wonder if any of that work survived beyond the visible portability changes in V7.

2 years, 9 months

3
2
0 0

Re: Documents for UNIX Collections

by segaloco

I didn't expect to have more documents to share this soon, but I've just secured a trove of early System V/5.0 documents, as listed: System V User's Manual System V Administrator's Manual System V Error Message Manual System V Transition Aids System V Release Description User's Guide Operator's Guide Administrator's Guide Programming Guide Graphics Guide Support Tools Guide Document Processing Guide The System V-prefixed ones are very specifically labeled System V, although I know at least of the User's and Administrator's Manuals with "Release 5.0" branding out in the wild as well. I've got two of the User's Manuals exhibiting this difference. I believe I've seen a scan of the Admin's Manual with 5.0 as well, but I would have to go searching for it, it's on bitsavers perhaps? In any case, this is the documentation series for the initial releases of System V, the ones with "UNIX System" in big letters with grid patterns fading out into the background. I don't know if the second set is considered part of the Release 5.0 or System V version of the document package, or if they made that distinction, but as of present I can positively identify the first 5 as being specifically for the System V version of this release. What is particularly curious is there are documents displaying "System V" but with a Western Electric logo on the front. I've seen a scan of a System V gold User's Manual with the logo removed and a disclaimer on the front page explaining that they can't use the Bell logo anymore due to the divestiture, likewise on bitsavers I'm pretty sure, so this may establish that there were at least three revisions: Release 5.0, System V pre-divestiture, and System V post-divestiture. Now for a little plug, just because she's been so incredibly helpful, I bought these from Leslie (last name unknown) known as "oldmaddogshop" on eBay. We got chatting for a little while and her husband was a computing professor at the University of Portland for some time as it sounds, and they're currently starting to go through the decades of literature and hardware he's picked up over the years for sale on eBay and perhaps other avenues. She very specifically mentioned a PDP-8 that he happens to have that he's hoping they can coordinate to donate to a museum or some other way to get it into a relatively publicly accessible space rather than winding up in the closet of a private collector. I told her I'd drop a brief mention in letting folks know about the documents in case they'd want the option of perusing some of what they're going to be offloading. She made mention of a stack of USENIX manuals as well, I have a smattering of 4.2 and 4.3 manuals already, so someone may be lucky enough to snag those soon enough. Up currently are an early SVID and some OSF/Motif stuff, but she said they've got plenty of boxes of books to go through. Anywho, once I receive these documents, I plan on starting the scanning process much like with the UNIX/TS 4.0 stuff, and will be in touch with Warren concerning hosting and a release as time goes on. One bit of input if anyone knows, does the above list represent (aside from Release 5.0 variants) the complete documentation package for System V gold? I can't say I've come across any other titles, and most certainly haven't seen PDFs of anything that isn't included here, but I see plenty of titles I've never seen scanned. If nothing else, I'm hoping that "Release Description" document may have a brief flyover of the published materials, akin to the list of books at the beginning of the SVR4 manuals or the documentation roadmaps of earlier UNIX/TS and PWB releases. - Matt G.

2 years, 9 months

4
6
0 0

Re: LSX issues and musing

by Paul Ruizendaal

> Any ideas on why businesses didn’t pick up the H11 in 1980? > [priced too high for hobbyists] > > Wikipedia says: > > 1978: H11 US$1295 (kit) or US$1595 fully assembled ("4kword base system”) > display advert <http://www.decodesystems.com/heathkit-h11-ad-1.gif> $1295 kit + postage/freight, bare system, 8KB (4kword), 6 Q-bus slots free. ROM ? > > 1981: IBM 5150(PC) US$1,565 for "16 KB RAM, Color Graphics Adapter, and no disk drives.” > ( I only saw 5150’s with 2x 5.25” 360KB floppies included - otherwise, can’t run programs & store files) Note that those are nominal prices. In terms of purchasing power USD 1595 in 1978 equated about USD 2200 in 1981 (https://www.in2013dollars.com/us/inflation/1978?endYear=1981&amount=1595) Otherwise agree with your observation on packaged, off-the-shelf software being the main driver. In small business before the IBM PC, Visicalc drove Apple II uptake; Wordstar, C-Basic 2 and DBase drove CP/M uptake. Would LSI-11 hardware with LSX, ed and nroff have been competitive in small business? The experiences of John Walker (of AutoCAD fame) suggests not: https://www.fourmilab.ch/documents/marinchip/

2 years, 9 months

1
0
0 0

Re: Document on BBN's VAX Unix TCP (Noel Chiappa)

by Paul Ruizendaal

> While looking for something else, I found this: > > VAX-UNIX Networking Support Project Implementation Description > Robert F. Gurwitz; January, 1981 > https://www.rfc-editor.org/ien/ien168.txt > > in a somewhat obscure location. I have no idea if it's already widely known > or not, but here it is anyway. Hi Noel, Thank you for highlighting this document. I had seen it before and the implementation (as found on the tapes from CSRG and now on THUS) follows the plan outlined in IEN168 quite closely. The first snapshot of the code is just a few months after this document. In a way it is modeled after the UoI Arpanet Unix implementation (and thank you again for finding that source!), with a separate (kernel) process for network activity. In my experiments I have found that it is not all that easy to get smooth network data flow as this network process is difficult to schedule just right. I now better understand why Joy moved to "software interrupts” to get better scheduling of kernel network operations. Wbr, Paul

2 years, 9 months

1
0
0 0

Document on BBN's VAX Unix TCP

by jnc＠mercury.lcs.mit.edu

While looking for something else, I found this: VAX-UNIX Networking Support Project Implementation Description Robert F. Gurwitz; January, 1981 https://www.rfc-editor.org/ien/ien168.txt in a somewhat obscure location. I have no idea if it's already widely known or not, but here it is anyway. Noel

2 years, 9 months

1
0
0 0

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

> Also, another problem with trying to 'push' LSX into a previously > un-handled operating regions (e.g. large disks, but there are likely > others) is that there are probably things that are un-tested in that > previously unused operating mode, and there may be un-found bugs that > you trip across. 'Speak of the devil, and hear the sound of his wings.' >> From: Gavin Tersteeg >> Interestingly enough, existing large V6 RK05 images can be mounted, >> read from, and written to. The only limitations on these pre existing >> images is that if enough files are deleted, the system will randomly >> crash. > I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and > alloc.c), but I couldn't quickly find the cause; it isn't obvious. I don't know if the following is _the_ cause of the crashes, but another problem (another aspect of the '100 free inodes cache' thing) swam up out of my brain. If you look at V6's alloc$ifree(), it says: if(fp->s_ninode >= 100) return; fp->s_inode[fp->s_ninode++] = ino; LSX's is missing the first two lines. So, if you try and free more than 100 inodes on LSX, the next line will march out of the s_inode array and smash other fields in the in-core copy of the super-block. Like I said, this is not certain to be the cause of those crashes; and it's not really a 'bug' (as in the opening observation) - but the general sense of that observation is right on target. LSX is really designed to operate only on disks with less than 100 inodes, and tring to run it elsewhere is going to run into issues. How many similar limitations exist in other areas I don't know. > From: Heinz Lycklama <heinz(a)osta.com> > Remember that the LSX and Mini-UNIX systems were developed for two > different purposes. Oh, that's understood - but this just re-states my observation, that LSX was designed to operate in a certain environment, and trying to run it elsewhere is just asking for problems. Noel

2 years, 9 months

1
0
0 0

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

{I was going to reply to an earlier message, but my CFS left me with insufficient energy; I'll try and catch up on the points I was goibf to make here.} > From: Gavin Tersteeg > This leaves me with about 1.9kb of space left in the kernel for > additional drivers I'm curious how much memory you have in your target system; it must not be a lot, if you're targeting LSX. I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a negative way; it's just recognition that LSX has had a lot of corners trimmed, to squeeze it down as much as possible), and some of those trims behind some of the issues you're having (below). At the time the LSI-11 came out, semiconductor DRAM was just getting started, so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 core memory cards :-), to produce the 40KB target for LSX systems, was then a reasonable configuration. These days, one has to really search to find anything smaller than 64KB... It might be easier to just run MINI-UNIX (which is much closer to V6, and thus a known quantity), than add a lot of things back in to LSX to produce what will effectively be MINI-UNIX; even if you have to buy a bit more QBUS memory for the machine. > the LSX "mkfs" was hardcoded to create filesystems with 6 blocks of > inodes. This maxed the number of files on a disk to 96, but even with > the maximum circumvented LSX would only tolerate a maximum of 101 files. And here you're seeing the 'lobotomizing' of LSX come into play. That '101' made me suspicious, as the base V6 'caches' 100 free inodes in the super-block; once those are used, it scans the ilist on disk to refill it. The code in alloc$ialloc in LSX is hard to understand (there are a lot of #ifdef's), and it's very different from the V6 code, but I'm pretty sure it doesn't refill the 'cache' after it uses the cached 100 free inodes. So, you can have as many free inodes on a disk as you want, but LSX will never use more than the first 100. (Note that the comment in the LSX source "up to 100 spare I nodes in the super block. When this runs out, a linear search through the I list is instituted to pick up 100 more." is inaccurate; it probably wasn't updated after the code was changed. ISTR tis is true of a lot of the comments.) Use MINI-UNIX. > A fresh filesystem that was mkfs'd on stock V6 can be mounted on LSX, > but any attempt to create files on it will fail. The V6 'mkfs' does not fill the free inode cache in the super-block. So, it's empty when you start out. The LSX ialloc() says: if(fp->s_ninode > 0) { ... } u.u_error = ENOSPC; return(NULL); which would produce what you're seeing. Also, another problem with trying to 'push' LSX into a previously un-handled operating regions (e.g. large disks, but there are likely others) is that there are probably things that are un-tested in that previously unused operating mode, and there may be un-found bugs that you trip across. Use MINI-UNIX. > Interestingly enough, existing large V6 RK05 images can be mounted, > read from, and written to. The only limitations on these pre existing > images is that if enough files are deleted, the system will randomly crash. I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and alloc.c), but I couldn't quickly find the cause; it isn't obvious. (When unlinking a file, the blocks in the file have to be freed - that's inode 'ip' - and the directory - inode 'pp' - has to be updated; so it's pretty complicated.) Use MINI-UNIX. > The information there about continuous files ... will be extremely > helpful if I ever try to make those work in the future. My recollection is that the LSX kernel doesn't have code to create contiguous files; the LSX page at the CHWiki says "the paper describing LSX indicates there were two separate programs, one to allocate space for such files, and one to move a file into such an area, but they do not seem to be extant". If you find them, could you let me know? Thanks. Noel

2 years, 9 months

6
5
0 0

Documentation on MERT added to TUHS

by Heinz Lycklama

The MERT (Multi-Environment Real-Time) system was developed at Bell Telephone Laboratories in Murray Hill, NJ by myself and Doug Bayer in the mid 1970's on a DEC PDP 11/45 computer. MERT was picked up by the UNIX Support Group (USG) in 1977 and has been distributed and supported throughout the Bell System. The MERT Manual consists of both the MERT Programmer's Manual and the UNIX Programmer's Manual. You can find all of this documentation at: 1. https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/ The hosting of this manual online was made possible by Clem Cole's painstaking efforts to scan in and organize the hundreds of pages in the hard copy MERT Manual. Clem had previously scanned in my Technical Memoranda documenting my work at Bell Labs in the 1970's on MERT, LSX, Mini-UNIX and the Mini-Computer Satellite Processor System: 2. https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/ The monthly UNIX Technology Advisor newsletter published in 1989 and 1990 contains articles written by some of the leading open systems industry pioneers. The first issue is available online here: 3. https://www.tuhs.org/Archive/Documentation/Unix_Advisor/ I want to thank Warren Toomey for providing and maintaining the TUHS.org <https://www.tuhs.org/> platform for the hosting of this historical information on UNIX systems for the community. Heinz Lycklama

2 years, 9 months

2
1
0 0

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > Note that LSX only holds one process in core and swaps other processes > (NPROC = 3) out to floppy. It reportedly took several hours for the > Terak to self-compile LSX from source. If one is working in a simulator, and not a real hardware PDP-11, there's a 'trick' one can use to make life a lot easier - for MINI-UNIX, at least; I'll comment on LSX below. As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX uses the same file system as V6; this allows MINI-UNIX packs to be 'mounted' on V6 systems (either real, or simulated), which is very convenient for working on them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX pack, and away you go. The V6 toolchain can be used to compile/link kernels; to link user commands one will need to import the LSX/MINI-UNIX loader (which, since V6 is source compatible with LSX/MINI-UNIX, is trivial). LSX is potentially more complex, as it supports _two different_ file system formats: the standard V6 one, and a 'contiguous' one which is very similar to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c, though), but is not fully compatible. So non-contiguous LSX file systems can be mounted under V6, but not contiguous ones. Noel

2 years, 9 months

3
4
0 0

RUNCOM and Multics: the origin of "rc" file

by Michelangelo De Simone

Hi, long time lurker here. Today I ended up on an article by Christian Lee Seibold about the origin of shells [1]. Coincidentally the article explained how the “rc” files came to be and why they’re called “rc”: everything started with RUNCOM and Multics. An excerpt from the article: ==== Unix Shells have had a very long history, and it all starts with a program written by Louis Pouzin for the MIT CTSS Operating System, called RUNCOM (which stood for “run commands”). It executed commands from a file, called “a runcom”. According to Kernighan and Ritchie[1], “rc” configuration files from Unix descended from this. Tom Van Vleck also gives origins of Unix’s use of “rc” to RUNCOM [2], and notes that the first time he read the term “shell” was from Multics documentation created by Doug Eastwood. According to Louis Pouzin, he coined the word “shell”. ==== Well, now I know… [1] https://portal.mozz.us/gemini/auragem.space/~krixano/ShellHistory-Unix.pdf — Michelangelo

2 years, 10 months

1
0
0 0

Mailing list archives

by Warner Losh

So where are the mailing list archives? I found one with google on minnie, but it stops a few weeks ago... Warner

2 years, 10 months

2
1
0 0

Line Numbers Before SysIII nl? BSD num?

by Douglas McIlroy

I've not seen an earlier post of mine on this topic; apologies if this is a duplicate. Roff was probably the earliest way to get a line-numbered file listing. Of course it took a bit of chicanery to apply it to a roff input file, but even that was not a big shell script. As has often been told, Joe Ossanna used to promise of line numbers (required by USPTO) to attract the Bell Labs patent department as the first Unix "customer". Doug

2 years, 10 months

1
0
0 0

Re: ed: multiple addresses (with semicolons)

by Douglas McIlroy

> More was I curious about the documentation of address chains in books. It was even discussed in Lomutu and Lomuto, "A Unix Primer", a pleasant book whose level is accurately described in the title. Doug

2 years, 10 months

3
4
0 0

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Ron Natalie > We had NCP running on the JHU kernel Which NCP implementation was that, the one from UIUC, or something else? (I'm curious about the one that someone here - I forget who - mentioned, where IIRC they thought it was a new one, not the UIUC one. I'm a little boggled that with so little use for one - there weren't many NCP sites - someone would have gone to all the work to do another one. But it's possible...) If you all used the UIUC one, what did you call it? I looked through the email about releases from NOSC (who seemed to be the focal point for maintaining it at one point): https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/new/dist.log but it doesn't give a name for it. The documentation: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/doc/IllinoisNCP.nr doesn't either (other than 'Illinois NCP'). It does seem that they were semi-using V7; see e.g.: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/green/c.c but the code looks very V6-ish; see e.g.: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/text.c Noel

2 years, 10 months

1
0
0 0

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh >> What's "net unix" anyway? > I'm referring to the University of Illinois distribution Ah, OK. > I have seen references to it in the ARPAnet census documents running on > both V6 and V7 (though mostly they were silent about which version). Well, V7 came out in January, 1979, and NCP wasn't turned off until January, 1983, so people had a lot of time to get it running under V7. > I thought this was the normal nomenclature of the time, but I may be > mistaken. I'm not sure what it was usually called; we didn't have much contact with it at MIT (although I had the source; I'm the one that provided it to TUHS). The problem was that although MIT had two IMPs, all the ports on them were spoken for, for big time-sharing mainframes (4 PDP-10's running ITS; 1 running TWENEX; a Multics), so there were no ports available to plug in a lowly PDP-11. (We were unable to get an IP gateway (router) onto the ARPANET until MIT got some of the first C/30 IMPs.) So we had no use for the NCP Unix (which I vaguely recall was described as 'the ARPANET Unix from UIll'). Noel

2 years, 10 months

2
1
0 0

Re: Unix V8 Chaosnet, any takers?

by Paul Ruizendaal

Apologies for being off-topic > What did people with PDP-11 V7 who wanted TCP/IP do, anyway? Taking it slightly broader (PDP-11 instead of V7), there is a lot of discussion about that on Mike Meuss’ TCP-digest mailing list: https://ftp.ripe.net/rfc/museum/tcp-ip-digest/ There is a 1985 index of available implementations as well ( https://ftp.ripe.net/rfc/museum/tcp-ip-implementations.txt.1 ). It includes the following options for PDP-11 systems: 1.7.5. UNIX 2.9BSD DESCRIPTION: 2.9BSD TCP/IP is an adaptation of Berkeley's original VAX TCP/IP (running under BSD 4.1B UNIX) which in turn is an offshoot of BBN's VAX TCP/IP. 2.9BSD TCP/IP runs on PDP-11/44s and PDP-11/70s. The 2.8 version from SRI was adapted by Bill Croft (formerly at SRI), then Tektronix adapted it for 2.9. Berkeley took over modification of the software and brought it back to SRI where Dan Chernikoff and Greg Satz adapted it for a later release of 2.9. In addition to TCP/IP, UDP, ARP and the raw packet interface is available. ICMP redirects are not supported. User software implementations include Telnet and FTP, plus Berkeley-developed local net protocols, RWHO, RSH, RLOGIN, and RCP. 2.9BSD with TCP/IP support could probably be made to run on smaller PDP-11s although the address space would be very tight and might present problems. 1.7.6. Venix/11 TCP/IP DESCRIPTION: This is based on the "PDP-11/45" implementation available from the MIT Laboratory for Computer Science. It has been ported to a V7 UNIX system, in particular VenturCom's Venix/11 V2.0. As little of the processing as possible takes place in the kernel, to minimize the code space required. It fits comfortably on I&D machines, but is almost hopeless on the smaller machines. The kernel includes a proNET device driver, IP fragment reassembly, IP header processing, local-net header processing, and simple routing. The rest of the IP processing, and all of the UDP and TCP functions, are in user libraries. The psuedo-teletype driver is also in the kernel, and is used by Server TELNET. User programs handle ICMP processing; User and Server TELNET, SMTP, TFTP, Finger, and Discard. There are User programs for Nicname and Hostname. IEN-116 nameservers are used by all programs, and an IEN-116 nameserver is also provided. The TCP used is very simple, not very fast, and lies about windows. No FTP is available, nor is one currently planned. 1.7.8. BBN-V6-UNIX DESCRIPTION: This TCP/IP/ICMP implementation runs as a user process in version 6 UNIX, with modifications obtained from BBN for network access. IP reassembles fragments into datagrams, but has no separate IP user interface. TCP supports user and server Telnet, echo, discard, internet SMTP mail, and FTP. ICMP generates replies to Echo Requests, and sends Source-Quench when reassembly buffers are full. 1. Hardware - PDP-11/70 and PDP-11/45 running UNIX version 6, with BBN IPC additions. 2. Software - written in C, requiring 25K instruction space, 20K data space. Supports 10 connections (including "listeners"). 3. Unimplemented protocol features: - TCP - Discards out-of-order segments. - IP - Does not handle some options and ICMP messages. 1.7.9. v 3COM-UNET DESCRIPTION: UNET is a communication software package which enables UNIX systems to communicate using TCP/IP protocols. UNET will utilize any physical communications media, from low speed links such as twisted pair RS-232C to high speed coaxial links such as Ethernet. All layers of the UNET package are directly available to the user. The highest layer provides user programs implementing ARPA standard File Transfer Protocol (UFTP), Virtual Terminal Protocol (UVTP), and Mail Transfer Protocols (UMTP). These programs in turn utilize the virtual circuit services of the TCP. The TCP protocol is implemented on top of the IP. Finally, IP can simultaneously interface to multiple local networks. UNET implements 5 of the 7 layers of the International Standards Organization Open Systems Interconnection Reference Model, layers 2 through 6: Link, Network, Transport, Session, and Presentation. Features of TCP 6 not yet implemented are Precedence and Security, End-of-Letter, and Urgent. Feature of IP 4 not yet implemented is Options. Of these, we have 2.9BSD and (a forerunner of) BBN-V6-Unix available on the TUHS Unix Tree. The Venix/11 source and the 3COM source appear lost. These (unfortunately) are the ones that were implemented on top of V7. Also, BBN back-ported the TCP/IP code of BBN VAX-TCP to V7 for their C/70 Unix.

2 years, 10 months

1
0
0 0

Re: V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?)

by Paul Ruizendaal

> Regarding select, I recall that Dennis implemented it and passed it to > Berkeley*, but maybe not. He certainly had a hand in its design; I > distinctly remember talking to him about it after one of his trips out > west. That is an interesting comment. DMR was on the steering committee for what would become 4.2BSD. I once spoke with Kirk McKusick about the origins of the sockets API and I think he told me that there was a lot of debate in the committee whether descriptor readiness API should be stateful (like Haverty’s await() https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken/awaitr.c ) or stateless (like select). According to Sam Leffler (who I think added select() to 4.1c BSD) the select system call was somewhat modelled after the ADA select statement. I am speculating now, but I would not be surprised if dmr favoured the stateless design and contributed to its design. Paul

2 years, 10 months

1
0
0 0

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > V7 could mean a modification of net unix What's "net unix" anyway? I know of the Net releases from CSRG, but this much precedes that. What did people with PDP-11 V7 who wanted TCP/IP do, anyway? Noel

2 years, 10 months

2
1
0 0

Unix V8 Chaosnet, any takers?

by Lars Brinkhoff

Hello, Unix V8 has some code for Chaosnet support. There is a small hobbyist Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes. Is there anyone who would be interested in trying to see if the V8 code is in a workable state, and get it running? Best regards, Lars Brinkhoff

2 years, 10 months

8
12
0 0

V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?)

by segaloco

Re-subject'd as this part of the conversation diverges. Found the quote that I was thinking of when I said that: https://yarchive.net/comp/bsd.html "Research Unix 8th Edition started from (I think) BSD 4.1c, but with enormous amounts scooped out and replaced by our own stuff." - Dennis Ritchie The "I think" adds some murkiness for sure. There's definitely a good chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s in V7 back). Heck, even the main.c between the two kernels are more similar to each other than V7. I would almost opt towards calling that being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I could see it being more beneficial to start with 4BSD and tack on necessary Bell bits rather than take V7/32V and try and shoehorn in the VM implementation for VAX. The 4.1cBSD copy on the archive does appear to be pretty different, so in terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to see if the structure of the source code changed between 4.1 and 4.1c, as 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows folders like cmd, lib, and so on. Not trying to be combative by any means, but I've been doing a bit of research lately into when V8 was snapped from BSD and where Bell and Berkeley then diverged from that last major confluence, especially with a focus on init and other early stages of userland. - Matt G. ------- Original Message ------- On Friday, July 15th, 2022 at 1:51 AM, Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> wrote: > > Message: 6 > > Date: Thu, 14 Jul 2022 17:51:39 +0000 > > From: segaloco segaloco(a)protonmail.com > > > > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. > > > I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base. > > As I currently understand it, the V8 kernel: > > - is a further development from 32V > - retains the code organisation of the V5..32V versions > - adds virtual memory code from BSD > - adds select() from BSD > > and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.) > > In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based). > > Paul

2 years, 10 months

4
4
0 0

Re: Unix V8 Chaosnet, any takers?

by jnc＠mercury.lcs.mit.edu

> From: Lars Brinkhoff > There is a small hobbyist Chaos network going What encapsulation are they using to transmit CHAOS packets (over the Internet, I assume)? I know there was an IP protocol number assigned for CHAOS (16.), but I don't recall if there was ever a spec? (Which is kind of amusing, since in 'Assigned Numbers', the person responsible for 16. is .... me! :-) There was a spec for encapsulating IP in CHAOS, and that actually _was_ implemented at MIT BITD; it was used for a while to get IP traffic to a Unix machine (V7, IIRC) over on main campus, at a stage when only CHAOS hardware (very confusing that the same name was applied to hardware, and a protocol suite) ran across to main campus from Tech Square. > From: Grant Taylor > I wonder if there is an opportunity for something that pretends to be > the remote side locally, sends the data via some other > non-latency-sensitive protocol to a counter part where the counter part > pretends to be the near side. Let's think through the details. The near-end 'invisibility box' (let's call it) is going to have to send acks to the original source machine, otherwise that will time out, abort the connection, etc. The originating machine is its own thing, and this behaviour can't be controlled/stopped. (This, BTW, shows a key difference between 'local' and 'across network' modes, a recent topic here; in a situation where two distinct machines are cooperating across a network, the other machine is its own entity, and can't be expected/guaranteed to do anything in particular at all.) In addition, the near-end invisibility box is going to have to keep a copy of each packet, until the destination machine sends an ack to the invisibility box - because if the packet is lost, the invisibility box is going to have to retransmit it. (The original source is not going to - it's already gotten an ack, so as far as it's concerned, that packet is done and dusted.) And the near-end invisibility box is also going to have to have to have a time-out timer, so that when the ack isn't seen, it will know to retransmit the packet. There's no point to _also_ sending the acks on to the originating machine; they won't do anything useful, and might just confuse it. So, let's see now: the near-end invisibility box buffers the packet, looks for an ack, times out when it doesn't see it, re-transmits the packet - that sounds familiar? Oh, right, it's a reliable connection. And presumably there's an invisibility box at the far end too, so the same can happen for any data packets the destination machine sends. The only question is whether, when doing the detailed design, there's any point to having the destination machine's acks sent to the near-end invisibility box - or just use them at the far-end invisibility box. (I.e. create three reliable connections: i) a CHAOS connection originating machine<->near-end invisibility box; ii) {whatever} near-end invisibility ox<->far-end invisibility box; iii) CHAOS far-end invisibility box<->original destination machine - and glue them together.) That is in some sense simpler than creating an extra-ordinary mechanism to have a 'helper' box in the middle of the connection (to terminate the CHAOS connection from the original machine, and have another CHAOS connection, but with an enhanced time-out mechanism which can cope with larger RTT's, from there to the original destination); and the same in the other direction. The amusing thing is that the CHAOS protocol stack actually already had something very similar to this, BITD. If one were sitting at a machine that only had CHAOS, and one wanted to (say) TELNET to an ARPANET host, there was a CHAOS service which ARPANET hosts on the CHAOSNET provided: open a CHAOS connection to that serrver, and it would open an NCP connection to one's intended ultimate destination, and glue the byte streams together. (The ultimate destination was passed as data over the CHAOS connection, when opening it.) Noel

2 years, 10 months

3
2
0 0

Re: Unix V8 Chaosnet, any takers?

by Paul Ruizendaal

> Message: 6 > Date: Thu, 14 Jul 2022 17:51:39 +0000 > From: segaloco <segaloco(a)protonmail.com> > > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base. As I currently understand it, the V8 kernel: - is a further development from 32V - retains the code organisation of the V5..32V versions - adds virtual memory code from BSD - adds select() from BSD and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.) In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based). Paul

2 years, 10 months

2
1
0 0

Re: LSX issues and musing

by Paul Ruizendaal

> If I can get this working, I have a long laundry list of modifications and > experiments that I want to run with LSX, but as it stands, this is where I > am stuck at. Once upon a time there was a Soviet home computer that was based on the PDP-11, the BK0010: https://en.wikipedia.org/wiki/Electronika_BK (it is actually mostly a copy of the Terak 8510a -- https://en.wikipedia.org/wiki/Terak_8510/a ) The guy that found the surviving floppy with LSX source code (Leonid Broukhis) for the PDP-11 immediately ported it to the BK0010 and created a fair amount of infrastructure around it: https://github.com/ignusius/bkunix He used the 2.11BSD toolchain to create a cross-compiler. As that compiler had progressed significantly from the 5th Edition era compiler, the kernel became smaller and he could squeeze some stripped functionality back in. The repo says that the code there still works on a normal PDP-11. I’ve never communicated with Leonid, but maybe Warren has contact details for him. Also, the person who created LSX unix (Heinz Lycklama) is reading this list -- but of course it has been 40+ years since he last touched the code. Note that LSX only holds one process in core and swaps other processes (NPROC = 3) out to floppy. It reportedly took several hours for the Terak to self-compile LSX from source. At one point I added debugger support to my own port of LSX to a TI-990 with just floppies ... let’s just say, now I understand deeply why the original Unix debug interface was an improvement opportunity :^)

2 years, 10 months

1
0
0 0

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

> From: Gavin Tersteeg > I spent a lot of time getting UNIX V6 working on my PDP-11/23 system. > It took a lot of tinkering with the kernel and drivers to make it work > in the way I wanted to You must have made a lot of changes for it to take "a lot of tinkering". Bringing V6 up on the /23 has been done several times, and when I did it, it only took about 2 dozen lines of code in about 2 files. What all did you wind up changing? > From my research, it seems like there were two different UNIX variants > that could run on a system like this. These variants were LSX and > MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like > a RK05 and some porting to work on an 11/03, while LSX is designed to > work on exactly the hardware specs that I have on hand. Bringing up MINI-UNIX on the /03 has been done at least twice; once historically (now lost, AFAIK), and again recently: http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html I'm not sure what you're basing the "MINI-UNIX seems to require a decent mass-storage device like a RK05" on - it should run as well on whatever you're running LSX on as LSX does. I haven't run LSX myself, but from what I've seen, the only significant difference between the two is that LSX will run with less main memory than MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away with 40KB).That was a significant issue when the LSI-11 was originally released, but these days one has to really work to have a QBUS PDP-11 with less than 56KB. > my EIS-less 11/03 EIS chips can be found on eBait for not much money (I just bought a couple myself), and it's worth investing in one, so on can dispense with the emulator, which takes real memory for which a better use can be found. > The first issue is that the C compiler will randomly spit out a "0: > Missing temp file" when attempting to compile something. This is > annoying, but circumventable by just running the same command over and > over until it works. Schaeffer's Law (from Larry Niven): anything you don't understand might be dangerous. I'd track down why this is happening. Noel

2 years, 10 months

2
1
0 0

Re: LSX issues and musing

by jnc＠mercury.lcs.mit.edu

It would be really appreciated if people replying to messages like this would take 10 minutes (or so - that's about how lonfg it took me to find the actual answer to this person's question) to do some research, instead of just replying off the top of their heads with whatever they happen to think they know. > From: Gavin Tersteeg > I can't seem to get the kernel to actually link together once > everything is compiled. When the final "ld -X" is executed, I always > get the following errors: > "Undefined: > _end > _edata > _decmch" The first two are automagically defined by the linker after a successful read-through of the files+libraries, i.e. when then are no un-defined symbols. Ignore them; they will go away when you fix the problem. The real issue is the missing 'decmch'. That apparently comes from decfd.c, which I assume is the DEC floppy disk driver. Depending on the setting of the EIS conditional compilation flag (a different one for C files, from the PDP-11 assembler files, please note - and I haven't worked out what its definitiion means; whether if defined, it means the machine _does_ have the EIS, or _does not_x), it will be called for. 'decmch' is in low.s (rather oddly; that usualy holds just interrupt vectors and interrupt toeholds), conditionally assembled on: .if DEC .if EIS-1 The first line presumably adds it if there _is_ a DEC floppy disk, the second I don't know _for sure_ the sense of (although I'm guessing that EIS=1 means there _is_ an EIS chip, so this line says 'assemble if there it _not_ an EIS chip'). Although you'd think that whatever calculation it is doing, it would need to do if there's an EIS chip or not, so with an EIS chip it must calculate it some other way; you'll have to read decfd.c and see how it works. Note that you'll have to make sure the EIS flags (note plural) are set to the same sense, when compiling the C and assembler files... Let me send this off, and I'll reply to some other points in a separate message. Noel

2 years, 10 months

1
0
0 0

LSX issues and musing

by Gavin Tersteeg

Hello, and greetings! I guess as this is my first post here, I should give some background on what I have been working on. Last summer I spent a lot of time getting UNIX V6 working on my PDP-11/23 system. It took a lot of tinkering with the kernel and drivers to make it work in the way I wanted to, but in the end I was left with a system that ran well enough to do some demonstrations at VCFMW. This year I want to do more stuff with 1970s era UNIX, but now with even more technical restrictions. I have had a Heathkit H-11 (consumer grade PDP-11/03) for a while now, and I have been looking for something interesting to do with it. From my research, it seems like there were two different UNIX variants that could run on a system like this. These variants were LSX and MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like a RK05 and some porting to work on an 11/03, while LSX is designed to work on exactly the hardware specs that I have on hand. So on to the actual issues I am having at the moment: I have put together a SIMH instance to get the ball rolling in building a kernel that will boot on my EIS-less 11/03, but I am having significant difficulty actually getting the kernel to build. The first issue is that the C compiler will randomly spit out a "0: Missing temp file" when attempting to compile something. This is annoying, but circumventable by just running the same command over and over until it works. The second issue, however, is much more of a road block for me. I can't seem to get the kernel to actually link together once everything is compiled. When the final "ld -X" is executed, I always get the following errors: " Undefined: _end _edata _decmch " (This is from the build script found in the "shlsx" file) https://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/shlsx I am assuming that this is some sort of issue with the object file orderings, but I simply do not know enough about V6 ld to properly debug this issue. I am hoping that somebody here has already run into this issue, and knows what I am doing wrong. If I can get this working, I have a long laundry list of modifications and experiments that I want to run with LSX, but as it stands, this is where I am stuck at. Thank you, Gavin

2 years, 10 months

4
4
0 0

Re: ed: multiple addresses (with semicolons)

by Douglas McIlroy

> I wasn't able to find the ``Multics Condensed Guide'' on multicians.org multicians.org points to http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condens… It also has https://www.multicians.org/mspm/bx-9-06.681115.qed-editor.pdf Amusingly, the "condensed guide" is many pages longer than the MSPM (Multics system programmer's manual--the gospel) Neither tells about extra address fields or semicolons > In ex(1) the " comment command reappeared. And in sed the y command reappeared. Doug

2 years, 10 months

2
1
0 0

ed: multiple addresses (with semicolons)

by Douglas McIlroy

The interpretation of a string of addresses separated by commas and/or semicolons was already defined in the v1 man page for ed. Ed was essentially a stripped-down version of Multics qed. The latter was originally written by Ken. Unfortunately the "Multics Condensed Guide" online at multicians.org describes how strings of addresses were interpreted only by canonical examples for the various editing requests. I have no specific memory of semicolons in qed. I have a vague recollection that semicolons originated in ed, however you should put no trust in this. Maybe Ken remembers. Doug

2 years, 10 months

8
7
0 0

Documents for UNIX Collections

by Warren Toomey

All, Matt e-mailed this to me and the TUHS list, but it doesn't seem to have made it through so I'm punting on a copy ... Warren ----- Forwarded message from Matt Gilmore ----- Subject: Documents for UNIX Collections Good afternoon everyone, my name is Matt Gilmore, and I recently worked with some folks here to help facilitate the scanning and release of the "Documents for UNIX" package as well as a few odds and ends pertinent to UNIX/TS 4.0. I've been researching pretty heavily the history of published memoranda and how they ultimately became the formal documents that Western Electric first published with UNIX/TS 5.0 and System V. Think the User's Guide, Graphics Guide, etc. In my research, I've found that document sets in a similar spirit have been published since at least Research Version 6. I've been able to track down a few that are on the TUHS source archive in original *ROFF format (Links given as path in the tree to avoid hyperlink mangling): Research V6: V6/usr/doc Mini-UNIX: Mini-Unix/usr/doc PWB/UNIX 1.0: PWB1/usr/man/man0/documents (note, I'm not sure where the actual docs are, this is just a TOC, Operators Manual is in op in the base man folder) Wollongong 7/32 Version: Interdata732/usr/doc (only 7/32 relevant docs, allegedly) Research V7: V7/usr/doc UNIX/32V: 32V/usr/doc There are probably others, but these are the ones I'm aware of on the archive for Bell-aligned revisions prior to the commercialization of UNIX/TS as System III. On the note of System III, I seem to have an archive that is slightly different than what is on TUHS, namely in that it has this same documents collection. I can't find it in the System III section on the site, so I'm assuming it isn't hosted anywhere presently. One of the projects I'm working on (slowly) is comparing these documents with the 4.0 docs I scanned for Arnold and making edits to the *ROFF sources with the hopes I could then use them to produce 1:1 clean copies of the 4.0 docs, while providing an easy means for diff'ing the documents as well (to flush out changes between 3.0 and 4.0). Happy to provide this dump to Warren for comparison with what is currently hosted. Usenix also published documentation sets for 4.2 and 4.3BSD in the 80's which served the same purpose for BSD users. There seems to be a 4.4BSD set as well, although I haven't looked at these yet, I've got a random smattering between 4.2 and 4.3 of the comb-bound Usenix manuals, but I assume the 4.4 set is in a similar vein, with reference guides and supplementary documents. Looks like a lot of the same, but with added documents regarding developments at Berkeley. Now for my reasons for mailing, there are a couple: 1. Is anyone aware of whether similar document sets were compiled for MERT, UNIX/RT, USG Program Generic, or CB-UNIX? Or would users of those systems have simply been referred to the collection most closely matching the version they're forked from? 2. Was there ever any such document set published in this nature as "Documents for UNIX" consistent of memoranda for 5.0/System V? Or did USG immediately begin by providing just the published trade manuals? The implication here is if USG published no such documents, then the Documents for UNIX 4.0 represents the last time USG compiled the memoranda as they were written (of course with version-related edits) with original authorship and references as a documentation set. 3. Have there been any known efforts to analyze the history and authorship of these documents, explicitly denote errata and revisions, and map out the evolution of the system from a documentation perspective like this? Thanks for any insight anyone can provide! - Matt G. P.S. I'd be interested in doing more preservation work, if anyone else has documents that need preserving, I'll happily coordinate shipment and scanning. P.P.S. Ccing Warren, I don't know if I'm able to send emails to this list or not, so pardon the extraneous email if not necessary. ----- End forwarded message -----

2 years, 10 months

3
2
0 0

ed: multiple addresses (with semicolons)

by markus schnalke

Hoi, via a recent message from Chris Pinnock to the list I became aware of the book ``Ed Mastery'' by Michael W. Lucas. At once I bought and read it. Although it is not on the mastery level it claims and I would have liked it to be, it still was fun to read. This brought me back to my ed interest. I like ed a lot and despite my young age, I've actually programmed with ed for fun and have prepared the troff slides for a talk on early Unix tools (like ed) with ed alone. I use the Heirloom version of ed. Anyways, I wondered about the possibility to give multiple addresses ... more than two for relative address searches. For example, to print the context of the first occurance of `argv' within the main function, you can use: /^main(/;/\<argv\>/-2;+4n For the last occurance it's even one level more: /^main(/;/^}/;?\<argv\>?-2;+4n (The semicolons mean that the next search or relative addressing starts at the result of the previous one. I.e. in this case: We go to the `main' function, from there go to the function end, then backwards to `argv' minus two lines and print (with line numbers) this line and four lines more.) The manpage of 6th Edition mentiones this possibility to give more than two addresses: Commands may require zero, one, or two addresses. Commands which require no addresses regard the presence of an address as an error. Commands which accept one or two addresses assume default addresses when insufficient are given. If more addresses are given than such a command requires, the last one or two (depending on what is accepted) are used. http://man.cat-v.org/unix-6th/1/ed You can see it in the sources as well: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/ed.c (Search for ';' to find the line. There's a loop processing the addresses.) V5 ed(1) is in assembler, however, which I cannot read. Thus there must have been a complete rewrite, maybe introducing this feature at that point. (I don't know where to find v5 manpage to check that as well.) I wonder how using multiple addresses for setting starting points for relative searches came to be. When was it implemented and what use cases drove this features back in the days? Or was it more an accident that was introduced by the implementation, which turned out to be useful? Or maybe it existed already in earlier versions of ed, althoug maybe undocumented. For reference, POSIX writes: Commands accept zero, one, or two addresses. If more than the required number of addresses are provided to a command that requires zero addresses, it shall be an error. Otherwise, if more than the required number of addresses are provided to a command, the addresses specified first shall be evaluated and then discarded until the maximum number of valid addresses remain, for the specified command. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html Here more explanation rom the rationale section: Any number of addresses can be provided to commands taking addresses; for example, "1,2,3,4,5p" prints lines 4 and 5, because two is the greatest valid number of addresses accepted by the print command. This, in combination with the <semicolon> delimiter, permits users to create commands based on ordered patterns in the file. For example, the command "3;/foo/;+2p" will display the first line after line 3 that contains the pattern foo, plus the next two lines. Note that the address "3;" must still be evaluated before being discarded, because the search origin for the "/foo/" command depends on this. As far as I can see, multiple addresses make only sense with the semicolon separator, because the comma separator does not change the state, thus previous addresses can have no effect on later addresses. The implementation just does not forbid them, for simplicity reasons. meillo

2 years, 10 months

1
1
0 0

Stuart Feldman's EFL

by arnold＠skeeve.com

Hi. EFL was definitely a part of BSD Unix. But I don't see it in the V7 stuff in the TUHS archives. When did it first appear? Was it part of 32V and I should look there? It is definitely in the V8 and V10 stuff. Did anyone actually use it? I have the feeling that ratfor had already caught on and spread far, and that it met people's needs, and so EFL didn't really catch on that much, even though it provided more features on top of Fortran. Thanks, Arnold

2 years, 10 months

4
4
0 0

Re: EFL

by Steve Simon

I remember reading the EFL docs in the paper manuals for a sysv.3.2 honeywell 68k tower machine i worked on circa 1987. i never tried it though.

2 years, 10 months

1
0
0 0

Re.: is networking different?

by Paul Ruizendaal

> On Sun, Jul 3, 2022 at 1:33 PM Marc Donner wrote: > > I've been ruminating on the question of whether networks are different from > disks (and other devices). Here are a couple of observations: [...] From my perspective most of these things are not unique to networks, they happen with disks and/or terminals. Only out-of-order delivery seems new. However, in many early networking contexts (Spider/Arpanet/Datakit/UUCP) this aspect was not visible to the host (and the same holds for a single segment ethernet). To me, in some ways networks are like tty’s (e.g. completing i/o can take arbitrarily long, doing a seek() does not make sense), in other ways they are like disks (raw devices are organised into byte streams, they have a name space). Uniquely, they have two end-points, only one of which is local (but pipes come close). Conceptually, a file system does two things: (i) it organises raw blocks into multiple files; these are the i-nodes and (ii) it provides a name space; these are directories and the namei routine. A network stack certainly does the first: a raw network device is organised into multiple pipe-like connections; depending on the network, it optionally offers a naming service. With the first aspect one could refer to any file by “major device number, minor device number, i-node number”. This is not very different from referring to a network stream by “network number, host number, port number” in tcp/ip (and in fact this is what bind() and connect() in the sockets API do), or “switch / host / channel” in Datakit. For disks, Unix offers a clean way to organise the name spaces of multiple devices into a unified whole. How to do this with networks is not so easy, prior to the invention of the file system switch. Early on (Arpanet Unix), it was tried to incorporate host names into a net directory by name (RFC 681) but this is not scalable. Another way would be to have a virtual directory and include only names for active connections. The simple way would be to use a text version of the numeric name as described above - but that is not much of an improvement. Better to have a network variant of namei that looks up symbolic names in a hosts file or in a network naming service. The latter does not look very performant on the hardware of 40 years ago, but it appears to have worked well on the Alto / PuPs network at Xerox PARC. With the above one could do open(“/net/inet/org.tuhs.www:80”, O_RDWR | O_STREAM) to connect to the TUHS web server, and do open(“/net/inet/any:80”, O_RDWR | O_STREAM | O_CREAT, 0600) to create a ‘listening’ (rendez-vous) socket. Paul

2 years, 10 months

5
6
0 0

Re: Thoughts on Licenses

by Larry McVoy

On Sun, Jul 03, 2022 at 05:55:15PM +1000, steve jenkin wrote: > > > On 3 Jul 2022, at 12:27, Larry McVoy <lm(a)mcvoy.com> wrote: > > > > I love the early Unix releases because they were so simple, processors > > were simple then as well. > > > Bell???s Observation on Computer Classes has brought surprises > - we???ve had some very popular new devices appear at the bottom end of the market and sell in the billions. Yes, and they all run Linux or some tiny OS. Has anyone ported v7 to any of these devices and seen it take off? Of course not, it doesn't have TCP/IP.

2 years, 10 months

7
11
0 0

is networking different?

by Marc Donner

On June 28 Rob Pike wrote: "One of the reasons I'm not a networking expert may be relevant here. With networks, I never found an abstraction to hang my hat on. Unlike with file systems and files, or even Unix character devices, which provide a level of remove from the underlying blocks and sectors and so on, the Unix networking interface always seemed too low-level and fiddly, analogous to making users write files by managing the blocks and sectors themselves." I've been ruminating on the question of whether networks are different from disks (and other devices). Here are a couple of observations: 1 - Two different packets may take two different paths from the sender to the receiver. 1a - The transit time for one packet may vary widely from that of the other. 1b - The two packets may arrive in an order different from the order in which they were transmitted. (Note - recently I have been reading Bob Gezelter's monograph [and PhD dissertation] and I've learned that modern high-performance disk systems behave more like networks in 1a and 1b.) 2 - A packet may never arrive. 3 - Behavior 2 not a sign of hard failure for networks, whereas it is generally considered so for other I/O devices. There is probably more to why networks are weird, but these are some of the big dissonances that seem to me to make Rob's comment resonate so loudly to me. Best, Marc ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

2 years, 10 months

3
3
0 0

Thoughts on Licenses

by Clem Cole

As part of some of simh work, I've been immersed in some licensing discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they are relevant. Anyway, WRT to TUHS, I'm thinking that at least in the case of the Unix style bits, I propose a small change to Waren's top-level directory. Add a new dir called something like 'Legal Docs' or 'Copyrights+Licenses'. Then move the Caldera document and Warren's current note into that area. Then add copies of anything we can collect like the Dan Cross's V8-10, anything WRT to Plan9/Inferno or anything we from the UNIX world - such as something Sun, DEC or HP or like might have added. Maybe add a subdirectory with the AT&T/USL case details. And maybe add a sub-directory with known FOSS licenses used by the UNIX community and add a copy of the 3-clause BSD and maybe even the two GPLs. Then update the README in the current top-level dir. Adding to the contents something like "*the IP contained on this website is covered by different licenses depending on the specific IP. Copies of these can be found with the source code itself, but have also been all collected together in the top-level directory: ...*." I think these all have both historical values, as well as practical values. As I said, I was not sure myself and I think other would be less ignorant if they could find it all easily. In the case of the practical, a for instance, in an email with some lawyers last week, I had pointed them at the Caldera document. I'ld have loved to have been able to say look in this directory. The Caldera and later Nokia Licenses are what we are considering as examples. Thoughts?

2 years, 10 months

6
8
0 0

Research Datakit notes

by Geoff Pool

I've enjoyed reading this thread as networking has always been a passion of mine. Lawrence Livermore had, at one time, their own networking system they called Spider. Is this the same Spider technology that Sandy Fraiser references in his Datakit notes? Geoff

2 years, 10 months

1
0
0 0

Re: "9 skills our grandkids won't have" - Is this a TUHS topic?

by Nelson H. F. Beebe

>> I don't know the answer to Ctrl-D. The Unix command "man ascii" has the answer: Oct Dec Hex Char Oct Dec Hex Char ------------------------------------------------------------------------ 000 0 00 NUL '\0' 100 64 40 @ 001 1 01 SOH (start of heading) 101 65 41 A 002 2 02 STX (start of text) 102 66 42 B 003 3 03 ETX (end of text) 103 67 43 C 004 4 04 EOT (end of transmission) 104 68 44 D .... Ctrl-D signifies end of transmission. Some other O/Ses have used Ctrl-Z for that purpose, presumably because Z is the final letter of numerous alphabets. There is a good book about the history of character sets (pre-Unicode) in the book described at this URL: http://www.math.utah.edu/pub/tex/bib/master.html#Mackenzie:1980:CCS Bob Bemer (1920--2004), known as Dr. ASCII to some of us, was a key person in the standardization of character sets: https://en.wikipedia.org/wiki/Bob_Bemer https://en.wikipedia.org/wiki/ASCII ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

2 years, 10 months

8
12
0 0

"9 skills our grandkids won't have" - Is this a TUHS topic?

by steve jenkin

What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? Whistling into a telephone while the modem is attached, because your keyboard has a stuck key - something I absolutely don’t miss. Having a computer in a grimy wharehouse with 400 days of uptime & wondering how a reboot might go? steve j ========= 9 Skills Our Grandkids Will Never Have <https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/> 1: Using record players, audio cassettes, and VCRs 2: Using analog phones [ or an Analog Clock ] 3. Writing letters by hand and mailing them 4. Reading and writing in cursive 5. Using manual research methods [ this is a Genealogy site ] 6. Preparing food the old-fashioned way 7. Creating and mending clothing 8. Building furniture from scratch 9. Speaking the languages of their ancestors -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

2 years, 10 months

27
34
0 0

Re: Typesetting Mathematics by Kernighan and Cherry, retypeset

by Norman Wilson

Warner Losh: Alcatel-Lucent gave an official grant to V8, V9 and V10. See https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/statement_… ==== Quite so. I believe this was announced on a mailing list called TUHS. Those here who are interested in such things might want to subscribe; I have and find it quite useful and interesting, with occasional disappointment. Norman Wilson Toronto ON (typing this on a train in Texas)

2 years, 10 months

1
0
0 0

Re: Typesetting Mathematics by Kernighan and Cherry, retypeset

by Douglas McIlroy

> I understand UNIX v7 is under this BSD-style license by Caldera Inc. > https://www.tuhs.org/Archive/Caldera-license.pdf The eqn document by Kernighan and Cherry also appears in the v10 manual, copyright by AT&T and published as a trade book. Wouldn't the recent release of v10 also pertain to the manual? Doug

2 years, 10 months

5
4
0 0

Compare, contrast and a "Unixy" networking API

by Paul Ruizendaal

Following an insightful post by Norman Wilson (https://minnie.tuhs.org/pipermail/tuhs/2022-June/025929.html) and re-reading a few old papers (https://minnie.tuhs.org/pipermail/tuhs/2022-June/026028.html) I was thinking about similarities and differences between the various Unix networking approaches in the 1975-1985 era and came up with the following observations: - First something obvious: early Unix was organised around two classes of device: character based and block based. Arguably, it is maybe better to think of these classes conceptually as “transient” and “memoizing”. A difference between the two would be wether or not it makes conceptual sense to do a seek operation on them and pipes and networks are in the transient class. - On the implementation side, this relates two early kernel data structures: clists and disk buffers. Clists were designed for slow, low volume traffic and most early Unix network code creates a third kind: the mbufs of Arpanet Unix, BBN-TCP Unix and BSD, the packets of Chesson's V7 packet driver, Ritchie's streams etc. These are all the same when seen from afar: higher capacity replacements for clists. - Typically devices are accessed via a filter. At an abstract level, there is not much difference between selecting a line discipline, pushing a stream filter or selecting a socket type. At the extreme end one could argue that pushing a TCP stack on a network device is conceptually the same as mounting a file system on a disk device. Arguably, both these operations could be performed through a generalised mount() call. - Another implementation point is the organisation of the code. Is the network code in the kernel, or in user land? Conceptually connection management is different from stream management when connected (e.g. CMC and URP with Datakit, or RTP and BSP in Xerox Pups). In the BSD lineage all is in the kernel, and in the Research lineage connection management is done in a user space daemon. Arpanet Unix (originally based on V5) had a curious solution: the network code was organised in a single process, but with code both in kernel mode and in user mode. The user code would make a special system call, and the kernel code would interact with the IMP driver, manage buffers and deliver packets. Only when a state-changing event happened, it would return to user mode and the user code would handle connection management (followed by a new call into kernel mode). Interestingly, this approach mostly hid the IMP connection, and this carried through to the BSD’s where the network devices were also buried in the stack. Arpanet Unix made this choice to conserve kernel address space and to minimize the amount of original kernel code that had to be touched. - Early Unix has three ways to obtain a file descriptor: open, creat and pipe. Later also fifo. In this context adding more (like socket) does not seem like a mortal sin. Arguably, all could be rolled into one, with open() handling all cases. Some of this was done in 4.2BSD. It is possible to combine socket() & friends into open() with additional flags, much as was done in Arpanet Unix and BBN-TCP Unix. - Network connections have different meta data than disk files, and in sockets this handled via specialised calls. This seems a missed opportunity for unified mechanisms. The API used in BBN-TCP handles most of this via ioctl. However, one could (cheekily!) argue that V7 unix has a somewhat byzantine meta data API, with the functionality split over seek, ioctl, fcntl, stat and fstat. These could all be handled in a generalised ioctl. Conceptually, this could also be replaced by using read/write on a meta data file descriptor, which could for example be the regular descriptor with the high bit set. But this, of course, did never exist. - A pain point in Arpanet Unix was that a listening connection (i.e. a server endpoint) would block until a client arrived and then turn into the connection with the client. This would fork out into a service process and the main server process would open a new listening socket for the next client. In sockets this was improved into a rendez-vous type server connection that would spawn individual client connections via ‘accept’. The V8/V9 IPC library took a similar approach, but also developed the mechanism into a generalized way to (i) create rendez-vous points and (ii) ship descriptors across local connections. - The strict blocking nature of IO in early Unix was another pain point for writing early network code. The first solution to that were BBN’s await and capac primitives, which worked around the blocking nature. With SysIII, non-blocking file access appeared and 4.1a BSD saw the arrival of 'select’. Together these offer a much more convenient way to deal with multiple tty or network streams in a single threaded process (although it did modify some of the early Unix philosophy). Non-blocking IO and select() also appeared in the Research lineage with 8th edition. - The file system switch (FSS) arrived around 1983, during the gestation of 8th edition. This was just 1 or 2 years after the network interfaces for BSD and Datakit got their basic shape. Had the FSS been part of V7 (as it well could have been), probably the networking designs would have been a bit different, using virtual directories for networking connections. The ‘namei hack’ in MIT’s CHAOS network code already points in this direction. A similar approach could have been extended to named pipes (arriving in SysIII), where the fifo endpoint could have been set up through creating a file in a virtual directory, and making connections through a regular open of such a virtual file (and 9th edition appears to implement this.) oOo To me it seems that the V1-V7 abstractions, the system call API, etc. were created with the experience of CTSS, Multics and others fresh in mind. The issues were understood and it combined the best of the ideas that came before. When it came to networking, Unix did not have this advantage and was necessarily trying to ride a bike whilst inventing it. Maybe in a different time line it would have been possible to pick the best ideas in this area as well and combine these into a coherent framework. I concur with the observation that this list should be about discussion of what once was and only tangentially about what might have been, so it is only after considerable hesitation that I write the below. Looking at the compare and contrast above (and having been tainted by what became dominant in later decades), I would say that the most “Unixy” way to add networking to V7/SysIII era Unix would have been something like: - Network access via open/read/write/close, in the style of BBN-TCP - Network namespace exposed via a virtual file system, a bit like V9 - Meta data via a generalised ioctl, or via read/write on a meta data descriptor - Connection rendez-vous via a generalised descriptor shipping mechanism, in the style of V8/V9 - Availability of non-blocking access, together with a waiting primitive (select/poll/etc.), in the style of BSD - Primary network device visible as any other device, network protocol mounted similar to a file system. - Both connection management and stream management located in kernel code, in the style of BSD

2 years, 10 months

1
0
0 0

kernel debugging in analogue

by Steve Simon

i remember a fellow student debugging an lsi11 kernel using a form of analogue vectorscope. i think it had a pair of DACs attached to the upper bits of the address bus. it generated a 2d pattern which you could recognise as particular code - interrupts are here, userspace is there, etc. the brightness of the spot indicated the time spent, so you got a bit of profiling too - and deadlocks became obvious. anyone remember these, what where they called? i think it was an HP or Tek product. -Steve

2 years, 10 months

3
5
0 0

Research Datakit notes

by Paul Ruizendaal

Wanted to post my notes as plain text, but the bullets / sub-bullets get lost. Here is a 2 page PDF with my notes on Research Datakit: https://www.jslite.net/notes/rdk.pdf The main takeaway is that connection build-up and tear-down is considerably more expensive than with TCP. The first cost is in the network, which builds up a dedicated path for each connection. Bandwidth is not allocated/reserved, but a path is and routing information is set up at each hop. The other cost is in the relatively verbose switch-host communication in this phase. This compares to the 3 packets exchanged at the hosts’ driver level to set up a TCP connection, with no permanent resources consumed in the network. In compensation, the cost to use a connection is considerably lower: the routing is known and the host-host link protocol (“URP") can be light-weight, as the network guarantees in-order delivery without duplicates but packets may be corrupted or lost (i.e. as if the connection is a phone line with a modem). No need to deal with packet fragmentation, stream reassembly and congestion storms as in the TCP of the early 80’s. Doing UDP traffic to a fixed remote host is easily mapped to using URP with no error correction and no flow control. Doing UDP where the remote host is different all the time is not practical on a Datakit network (i.e. a virtual circuit would be set up anyway). A secondary takeaway is that Research Datakit eventually settled on a three-level ascii namespace: “area/trunk/switch”. On each switch, the hosts would be known by name, and each connection request had a service name as parameter. In an alternate reality we would maybe have used “ca/stclara/mtnview!google!www” to do a search.

2 years, 10 months

18
25
0 0

Re: Research Datakit notes

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > having the switch do some of the call validation and even maybe > authentication (I'm not sure...) sounds like it takes load off the host. I don't have enough information to express a judgement in this particular case, but I can say a few things about how one would go about analyzing questions of 'where should I put function [X]; in the host, or in the 'network' (which almost inevitably means 'in the switches')'. It seems to me that one has to examine three points: - What is the 'cost' to actually _do_ the thing (which might be in transmission usage, or computing power, or memory, or delay), in each alternative; these costs obviously generally cannot be amortized across multiple similar transactions. - What is the 'cost' of providing the _mechanism_ to do the thing, in each alternative. This comes in three parts. The first is the engineering cost of _designing_ the thing, in detail; this obviously is amortized across muiple instances. The second is _producing_ the mechanism, in the places where it is needed (for mechanisms in software, this cost is essentially zero, unless it needs a lot of memory/computes/etc); this is not amortized across many. The third is harder to measure: it's complexity. This is probably a book by itself, but it has costs that are hard to quantify, and are also very disparate: e.g. more complex designs are more likely to have unforseen bugs, which is very different from the 'cost' that more complex designs are probaly harder to evolve for new uses. So far I haven't said anything that isn't applicable across a broad range of information sytems. The last influence on where one puts functions is much more common in communication systems: the Saltzer/Clark/Reed 'End-to-end Arguments in System Design' questions. If one _has_ to put a function in the host to get 'acceptable' performace of that function, the operation/implementation/design cost implications are irrelevant: one has to grit one's teeth and bear them. This may then feed back to design questions in the other areas. E.g. the Version 2 ring at MIT deliberately left out hardware packet checksums - because it was mostly intended for use with TCP/IP traffic, which provided a pseudo-End-to-End checksum, so the per-unit hardware costs didn't buy enough to be worth the costs of a hardware CRC. (Which was the right call; I don't recall the lack of a hardware checksum ever causing a problem.) And then there's the 'techology is a moving target' point: something that might be unacceptably expensive (in computing cost) in year X might be fine in year X+10, when we're lighting our cigars with unneeded computing power. So when one is designing a communication system with a likely lifetime in many decades, one tends to bias one's judgement toward things like End-to-End analysis - because those factors will be forever. Sorry if I haven't offered any answer to your initial query: "having the switch do some of the call validation ... sounds like it takes load off the host", but as I have tried to explain, these 'where should one do [X]' questions are very complicated, and one would need a lot more detail before one could give a good answer. But, in general, "tak[ing] load off the host" doesn't seem to rate highly as a goal these days... :-) :-( Noel

2 years, 10 months

2
1
0 0

Re: Research Datakit notes

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > Will read those RFC's, though -- thank you for pointing them out. Oh, I wouldn't bother - unless you are really into routing (i.e. path selection). RFC-1992 in particular; it's got my name on it, but it was mostly written by Martha and Isidro, and I'm not entirely happy with it. E.g. CSC mode and CSS mode (roughly, strict source route and loose source route); I wasn't really sold on them, but I was too tired to argue about it. Nimrod was complicated enough without adding extra bells and whistles - and indeed, LSR and SSR are basically unused to this day in the Internet (at least, at the internet layer; MPLS does provide the ability to specify paths, which I gather is used to some degree). I guess it's an OK overview of the architecture, though. RFC-1753 is not the best overview, but it has interesting bits. E.g. 2.2 Packet Format Fields, Option 2: "The packet contains a stack of flow-ids, with the current one on the top." If this reminds you of MPLS, it should! (One can think of MPLS as Nimrod's packet-carrying subsystem, in some ways.) I guess I should mention that Nimrod covers more stuff - a lot more - than just path selection. That's because I felt that the architecture embodied in IPv4 was missing lots of things which one would need to do the internet layer 'right' in a global-scale Internet (e.g. variable length 'addresses' - for which we were forced to invent the term 'locator' because many nitwits in the IETF couldn't wrap their minds around 'addresses' which weren't in every packet header). And separation of location and identity; and the introduction of traffic aggregates as first-class objects at the internet layer. Etc, etc, etc. Nimrod's main focus was really on i) providing a path-selection system which allowed things like letting users have more input to selecting the path their traffic took (just as when one gets into a car, one gets to pick the path one's going to use), and ii) controlling the overhead of the routing. Of course, on the latter point, in the real world, people just threw resources (memory, computing power, bandwidth) at the problem. I'm kind of blown away< that there are almost 1 million routes in the DFZ these days. Boiling frogs... Noel

2 years, 11 months

2
1
0 0

Clem's Law.

by steve jenkin

I thought this comment was very good. I went looking for “Clem’s Law” (presume Clem Cole) and struck out. Any hints anyone can suggest or history on the comment? steve j ========== Larry McVoy wrote Fri Sep 17 10:44:25 AEST 2021 <https://minnie.tuhs.org/pipermail/tuhs/2021-September/024424.html> Plan 9 is very cool but I am channeling my inner Clem, Plan 9 didn't meet Clem's law. It was never compelling enough to make the masses love it. Linux was good enough. ========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

2 years, 11 months

4
3
0 0

Re: Research Datakit notes

by jnc＠mercury.lcs.mit.edu

Just as the topic of TUHS isn't 'how _I_ could/would build a _better_ OS', but 'history of the OS that was _actually built_' (something that many posters here seem to lose track of, to the my great irritation), so too the topic isn't 'how to build a better network' - or actually, anything network-centric. I'll make a few comments on a couple of things, though. > From: steve jenkin > packet switching won over Virtual Circuits in the now distant past but > in small, local and un-congested networks without reliability > constraints, any solution can look good. ... Packet switching > hasn't scaled well to Global size, at least IMHO. The internetworking architecture, circa 1978, has not scaled as well as would have been optimal, for a number of reasons, among them: - pure scaling effects (e.g. algorithms won't scale up; subsystems which handle several different needs will often need to be separated out at a larger scale; etc) - inherent lack of hindsight (unknown unknowns, to use Rumsfeld's phrase; some things you only learn in hindsight) - insufficiently detailed knowledge of complete requirements for a global-scale network (including O+M, eventual business model, etc) - limited personnel resources at the time (some things we _knew_ were going to be a problem we had to ignore because we didn't have people to throw at the problem, then and there) - rapid technological innovation (and nobody's crystal ball is 100% perfect) It has been possible to fix some aspects of the ca. 1978 system - e.g. the addition of DNS, which I think has worked _reasonably_ well - but in other areas, changes weren't really adequate, often because they were constrained by things like upward compatibility requirements (e.g. BGP, which, among numerous other issues, had to live with existing IP addressing). Having said all that, I think your assertion that virtual circuits would have worked better in a global-scale network is questionable. The whole point of networks which use unreliable datagrams as a fundamental building block is that by moving a lot of functionality into the edge nodes, it makes the switches a lot simpler. Contemporary core routers may be complex - but they would be much worse if the network used virtual circuits. Something I suspect you may be unaware of is that most of the people who devised the unreliable datagram approach of the internetworking architecture _had experience with an actual moderately-sized, operational virtual circuit network_ - the ARPANET. (Yes, it was basically a VC network. Look at things like RFNMs, links {the specific ARPANET mechanism referred to by this term, not the general concept}, etc.) So they _knew_ what a VC network would involve. So, think about the 'core routers' in a network which used VC's. I guess a typical core router tese days uses a couple of OC768 links. Assume an average packet size of 100 bytes (probably roughly accurate, with the bimodal distribution between data and acks). With 4 OC768's, that's 4*38.5G/800 = ~155M packets/second. I'm not sure of the average TCP connection length in packets these days, but assume it's 100 packets or so (that's a 100KB Web object). That's still roughly _1 million cicuit setups per second_. If the answer is 'oh, we'll use aggregation so core routers don't see individual connections - or their setup/tear-down' - well, the same can be done with a datagram system; that's what MPLS does. Work through the details - VCs were not preferred, for good reasons. > Ethernet only became a viable LAN technology with advent of Twisted > pair: point to point + Switches. It's really irritating that a lot of things labelled 'Ethernet' these days _aren't_ _real_ Ethernet (i.e. a common broadcast bus allocated via CSMA-CD). They use the same _packet format_ as Ethernet (especially the 48-bit globally-unique address, which can usefully be blown into things at manufacture time), but it's not Ethernet. In some cases, they also retain the host interface<->network physical interface - but the thing on the other side of the interface is totally different (such as the hub-based systems commmon now - as you indicate, it's a bunch of small datagram packet switches plugged together with point-point links). Interfaces are forever; like the screw in light-bulb. These days, it's likely an LED bulb on one side, powered by a reactor on the other - two technologies which were unforseen (and unforseeable) when the interface was defined, well over 100 years ago. Noel

2 years, 11 months

2
1
0 0

Re: forgotten versions

by Paul Ruizendaal

On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote: > I recently stumbled across the existence of datakit > when going through the plan9foundation source archives. > Would be curious to hear more about its involvement > with plan9. There are at least 2 versions of Datakit. I my current understanding there are “Datakit” which is the research version, and “Datakit II” which seems to be the version that was broadly deployed into the AT&T network in the late 80’s -- but very likely the story is more complicated than that. Plan9 is contemporaneous with Datakit II. In short, Sandy Fraser developed the “Spider” network in 1970-1974 and this was actively used with early Unix (at least V4, maybe earlier). Sandy was dissatisfied with Spider and used its learnings to start again. The key ideas seem to have gelled together around 1977 with the first switches being available in 1979 or so. The first deployment into the Bell system was around 1982 (initially connecting a handful of Bell sites). In 1979/1980 there were two Datakit switches, one in the office of Greg Chesson who was writing the first iteration of its control software, and one in the office/lab of Gottfried Luderer et al., who used it to develop a distributed Unix. Datakit at this time is well described in two papers that the ACM recently moved from behind its paywall: https://dl.acm.org/doi/pdf/10.1145/1013879.802670 (mostly about 1980 Datakit) https://dl.acm.org/doi/pdf/10.1145/800216.806604 (mostly about distributed Unix) The Chesson control software was replaced by new code written by Lee McMahon around 1981 (note: this is still Datakit 1). The Datakit driver code in V8 is designed to work with this revised Datakit. Three aspects of Datakit show through in the design the V8-V10 networking code: - a separation in control words and data words (this e.g. comes back in ‘streams') - it works with virtual circuits; a connection is expensive to set up (‘dial’), but cheap to use - it does not guarantee reliable packet delivery, but it does guarantee in-order delivery Probably you will see echoes of this in early Plan9 network code, but I have not studied that.

2 years, 11 months

3
3
0 0

Re: Research Datakit notes

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > it would seem to me that Sandy had figured out a core problem some 30 > years before the TCP/IP world would come up with a similar solution. I > would not even be surprised if I learned that modern telco routers > transparantly set up virtual circuits for tcp traffic. To fully explore this topic would take a book, which I don't have the energy to write, and nobody would bother to read, but... Anyway, I'm not upon the latest and greatest high-speed routers: I saw some stuff from one major vendor under NDA about a decade ago, but that's my most recent - but at that point there was nothing that looked even _vaguely_ like virtual circuits. (The stuff Craig was alluding to was just about connectivity for getting bitts from _interface_ to _interface_ - if you don't have a giant crossbar - which is going to require buffering on each input anyway - how exactly do you get bits from board A to board Q - a single shared bus isn't going to do it...) A problem with anything like VC's in core switches is the growth of per-VC state - a major high-speed node will have packets from _millions_ of TCP connections flowing through it at any time. In the late-80's/early-90's - well over 30 years ago - I came up with an advanced routing architecture called Nimrod (see RFC-1992, "The Nimrod Routing Architecture"; RFC-1753 may be of interest too); it had things called 'flows' which were half way between pure datagrams (i.e. no setup - you just stick the right destination address in the header and send it off) and VCs (read the RFCs if you want to kow why), and it went to a lot of trouble to allow flow aggregation in traffic going to core switches _precisely_ to limit the growth of state in core switches, which would have traffic from millions of connections going through them. I have barely begun to even scratch the surface, here. Noel

2 years, 11 months

7
7
0 0

Early Unix Growth: Number of “Installations” or Licences?

by steve jenkin

I’ve been wondering about the growth of Unix and if there’s any good data available. There’s the Early Unix Epoch, which probably ends with the Unix Support Group assuming the distribution role, plus providing / distributing their version of the code. Later there’s commercial Unix: System III and System V, I guess. BSD, until the lawsuit was resolved, required a Source code license, but their installation count is important in pre-Commercial Unix. Large licensees like SUN, HP & IBM (AIX) may not have published license counts for their versions - but then, were their derivatives “Unix” or something else? Warner Loch’s paper has data to around 1978 [below]. I’ve no idea where to find data for USG issued licences, or if the number of binary & source licences were ever reported in the Commercial Era by AT&T. I’ll not be the first person who’s gone down this road, but my Search Fu isn’t good enough to find them. Wondering if anyone on the list can point me at resources, even a bunch of annual reports. I don’t mind manually pulling out the data I’m interested in. But why reinvent the wheel if the work is already done? steve =============== numbers extracted from Warner Loch’s paper. <https://papers.freebsd.org/2020/FOSDEM/losh-Hidden_early_history_of_Unix.fi…> 2nd Edn June 1972 10 installations 3rd Edn February 1973 16 4th Edn November 1973 >20, or 25 July 74 CACM paper "Unix Time Sharing System” after which external interest exploded 6th Edn 1975 ??? 7th Edn March 1978 600+, >300 inside Bell System, "even more have been licensed to outside users” =============== -- Steve Jenkin, 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

2 years, 11 months

2
1
0 0

Re: forgotten versions

by jnc＠mercury.lcs.mit.edu

> From: Dan Cross > I believe that's actually a menu Hence the "erroneous _impression_" (emphasis added). I'm curious as to how they decided which models to run which editions on. Although V4 _ran_ on the /45, split I+D wasn't supported - for user or kernel - until V6. (I'm assuming a number of things - both in the kernel, and applications - started hitting the 64KB limit, which led to its support.) Speaking of split I+D, there's an interesting little mystery in V6 that at one point in time I thought involved split I+D - but now that I look closely, apparently not. The mystery involves a 'tombstone' in the V6 buf.h: #define B_RELOC 0200 /* no longer used */ I had created (in my mind) an explanation what this is all about - but now that I look, it's probably all wrong! My explanation involves the slightly odd layout of the kernel in physical memory, with split I+D; data below the code, at physical 0. This actually makes a lot of sense; it means the virtual address of any data (e.g. a buffer) is the same as its physical address (needed for DMA). It does require the oddness of 'sysfix', to invert the order of code+data in the system binary, plus odd little quirks in the assembler startup (e.g. copying the code up to make room for BSS). So I thought that B_RELOC was a hangover from a time, at the start of split I+D, when data _wasn't_ at physical 0, so a buffer's virtual and phsyical addresses differed. But that must be wrong (at least in any simple way). B_RELOC was in buf.h as of V4 - the first kernel version in C - with no split I+D. So my theory has to be wrong. However, I am unable to find any code in the V4 kernel which uses it! So unless someone who remembers the very early PDP-11 kernel can enlighten us, its purpose will always remain a mystery! Noel

2 years, 11 months

1
0
0 0

Re: forgotten versions

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > [c] Fifth Edition UNIX PDP-11/40 June 1974 > [d] Sixth Edition UNIX PDP-11/45 May 1975 > [e] Seventh Edition UNIX PDP-11/70 January 1979 This table gives an erroneous impression of which versions supported which PDP-11 models. 4th Edition supported only the /45; 5th Edition added support for the /40; and the /70 appeared in 6th edition. Noel

2 years, 11 months

2
1
0 0

Sandy Fraser

by Douglas McIlroy

Sandy Fraser died June 13. The moving spirit behind Datakit, Sandy served as director then executive director responsible for computing science at Bell Labs in the era of v8, v9, and v10. He became VP at AT&T Shannon Labs after the split with Lucent. Doug

2 years, 11 months

2
1
0 0

forgotten versions

by Rob Pike

Excited as I was to see this history of Unix code in a single repository: https://github.com/dspinellis/unix-history-repo it continues the long-standing tradition of ignoring all the work done at Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, even influential, but to hear this list talk about it - or discussions just about anywhere else - you'd think they never existed. There are exceptions, but this site does reinforce the broadly known version of the story. It's doubly ironic for me because people often mistakenly credit me for working on Unix, but I landed at the Labs after v7 was long dispatched. At the Labs, I first worked on what became v8. I suppose it's because the history flowed as this site shows, with BSD being the driving force for a number of reasons, but it feels to me that a large piece of Unix history has been sidelined. I know it's a whiny lament, but those neglected systems had interesting advances. -rob

2 years, 11 months

19
35
1 0

Tom Lyon's 3270 driver for UTS

by Adam Thornton

While I know that there are people here who like good old ed...I've been playing with UTS under VM/370. This version is from 1981 and I think it's v7. But the important thing is that Tom Lyon wrote a 3270 terminal driver, and it comes with ned, which is a screen editor that feels a lot like XEDIT--which wasn't even in CMS at that point, although EE has been added to the VM370 Community Edition I'm using. And the man pages are fullscreen as well. UTS is very, very usable because of that. This really is a wonderful terminal driver. So, thank you, Tom! Adam

2 years, 11 months

3
2
0 0

Re: RFS (was Re: Re: forgotten versions)

by Paul Ruizendaal

> I don't know the exact history of RFS a la System V, but I > don't think it was Peter Weinberger's stuff, and it certainly > wasn't his code. Peter’s code is available in the V8 and V9 trees on TUHS. The Sys V repositories on Github appear to include RFS code in all of R3.0, R3.1 and R3.2. At first glance, it seems quite different from the V8/V9 code. > Peter, being a self-described fan of cheap hacks, also wasn't > inclined to spend much time thinking about general abstractions; > in effect he just turned various existing kernel subroutines > (when applied to a network file system) into RPCs. The > structure of the file system switch was rather UNIX-specific, > reflecting that. Yes, well put. I’ve back ported his filesystem switch to V6/V7 and it is very light touch: on the PDP11 it added only some 500 bytes of kernel code (after some refactoring). With hindsight it seems such a logical idea, certainly in a context where the labs were experimenting with remote system calls in the mid 70’s (Heinz Lycklama's work on satellite Unix) and early 80’s (Gottfried Luderer et al. on distributed Unix — another forgotten version). It is such a powerful abstraction, but apparently very elusive to invent. Paul

2 years, 11 months

2
1
0 0

Re: forgotten versions

by Douglas McIlroy

> I can think of at least 4 things, some big, some small, where post-V7 > Research Unix was influential Besides streams, file system switch, /proc, and /dev/fd. v8 had the Blit. Though Rob's relevant patent evoked disgruntled rumblings from MIT that window systems were old hat, the Blit pioneered multiple windows as we know them today. On the contemporary Lisp Machine, for example, active computation happened in only one window at a time. V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS mapped UIDS, thus allowing files to be shared among computers in different jurisdictions with different UID lists. Unfortunately, RFS went the way of Reiser paging. And then there was Norman Wilson, who polished the kernel and administrative tools. All kinds of things became smaller and cleaner--an inimitable accomplishment > No clue what was new in V10 This suggests I should put on my to-do list an update of the Research Unix Reader's combined table of man-page contents, which covers only v1-v9. I think it's fair to say, though, that nothing introduced in v10 was as influential as the features mentioned above. Doug

2 years, 11 months

10
10
0 0

Re: RFS (was Re: Re: forgotten versions)

by norman＠oclsc.org

I don't know the exact history of RFS a la System V, but I don't think it was Peter Weinberger's stuff, and it certainly wasn't his code. Nor his name: he called his first version neta and his second netb (he knew it would be changing and allowed for it in the name from the start). I don't remember us ever calling it RFS, or even remote file systems, inside 1127; we called it network file systems (never NFS because the Sun stuff existed by then). For those who don't know it, Peter's goal was quite different from that of NFS. The idea behind NFS seems always to have been to mount a remote file system as if it were local, with a base assumption early on that everything was within the same administrative domain so it was OK to make assumptions about userids matching up, and running code as super-user. Peter described his intent as `I want to be able to use your disks, and that's a lot simpler if I don't have to get you to add code to your kernel, or even to run a program as super-user.' Hence the entirely-user-mode server program, which could use super-user privileges to afford access as any user if it had them, but also worked fine when run as an ordinary user with only that user's file permissions. We did in fact normally run it as super-user so each of our 15 or so VAXes could see the file system tree on each other, but we also occasionally did it otherwise. That was one reason device files worked as they did, accessing the device on the server end rather than acting like a local special file on the client: we didn't care about running diskless clients, but we did occasionally care about accessing a remote system's tape drive. Peter, being a self-described fan of cheap hacks, also wasn't inclined to spend much time thinking about general abstractions; in effect he just turned various existing kernel subroutines (when applied to a network file system) into RPCs. The structure of the file system switch was rather UNIX-specific, reflecting that. That also means Peter's code was a bit ad-hoc and wonky in places. He cleaned it up considerably between neta and netb, and I did further cleanup later. I even had a go at a library to isolate the network protocol from the server proper, converted the netb server to use it, and made a few demo servers of my own like one to read and write raw FILES-11 file systems--useful for working with the console file system on the VAX 8800 series, which was exported to the host as a block device--and a daemon to allow a tar archive to be mounted as a read-only file system. In modern systems, you can do the same sort of things with FUSE, and set up the same I-want-to-use-your-disks (or I want to get at my own files from afar without privileges) scheme with sshfs. I would be very surprised to learn that either of those borrowed from their ancient cousins in Research UNIX; so far as I know they're independent inventions. Either way I'm glad they exist. Norman Wilson Toronto ON

2 years, 11 months

3
2
0 0

Re: early plan9

by Steve Simon

interesting to know the vax was a complete dead end. i do remember jmk (rip) reporting on 9fans, maybe even releasing, the vax plan9 kenc compiler he discovered in a dusty corner of the dump filesystem. I was intrigued and asked if there was anything else, but he said he said there where no kernel or driver fragments to go with it. -Steve

2 years, 11 months

1
0
0 0

Re: forgotten versions

by Paul Ruizendaal

For those interested in a quick feel for V8 and early SysV, I recommend the excellent unix50 stuff: SSH to unix50: "ssh unix50(a)unix50.xn--org-9o0a Password is “unix50” You end up in a menu with: SDF Public Access UNIX System presents ... /~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/ /~/~ H Y S T E R I C A L ~ U N I X ~ S Y S T E M S ~/~/ /~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/ [a] UNICS (Version Zero) PDP-7 Summer 1969 [b] First Edition UNIX PDP-11/20 November 1971 [c] Fifth Edition UNIX PDP-11/40 June 1974 [d] Sixth Edition UNIX PDP-11/45 May 1975 [e] Seventh Edition UNIX PDP-11/70 January 1979 [f] Research UNIX 8 VAX-11/750 1984 [g] AT&T UNIX System III PDP-11/70 Fall 1982 [h] AT&T UNIX System V PDP-11/70 1983 [i] AT&T UNIX System V 3b2/400 1984 [j] 4.3 BSD MicroVAX June 1986 [k] 2.11 BSD PDP-11/70 January 1992 [w] What's running now? [q] QUIT (and run away in fear!) User contributed tutorials are at https://sdf.org/?tutorials/unix50th Want persistent images? networking? more ttys? Join https://sdf.org Don’t to exit from a run, press Ctrl-E to return to sims, type 'exit', type ‘q' I just tried V8 and it still works, although the boot log suggests that an image reset may be in order. Many, many thanks to whoever is maintaining this!

2 years, 11 months

1
0
0 0

Re: Sockets vs Streams (was Re: forgotten versions

by norman＠oclsc.org

As one of the few remaining people who has actually worked with the original dmr stream I/O system, I'd love to dive into the debate here, but I don't have time. I can't resist commenting on a few things that have flown by, though. Maybe I can find time to engage better on the weekend. -- If you think there were no record delimiters in the stream system, you don't know enough about it. A good resource to repair that is Dennis's BSTJ paper: https://www.bell-labs.com/usr/dmr/www/st.pdf It's an early description and some of the details later evolved (for example we realized that once pipes were streams, we no longer needed pseudoterminals) but the fundamentals remained constant. See the section about Message blocks, and the distinction between data and control blocks. Delimiters were one kind of control; there were others, some of them potentially specific to the network at hand. In particular, Datakit (despite being a virtual-circuit network) had several sorts of control words, including message delimiters. Delimiters were necessary even just for terminals, though: how else does the generic read(2) code know to return early, before filling the buffer, when a complete line has arrived? -- It's hard to compare sockets to streams and make much sense, because they are very different kinds of thing. When people talk about sockets, especially when complaining that sockets are a mess, they usually mean the API: system calls like connect and listen and getpeername and so on. The stream system was mainly about the internal structure-- the composable modules and the general-purpose queue interface between them, so that you could take a stream representing an (already set up) network connection and push the tty module on it and have a working remote terminal, no need for user-mode programs and pseudo-terminals. It's not inconceivable to build a system with socket-like API and stream internals. -- Connection setup was initially done with network-specific magic messages and magic ioctls. Later we moved the knowledge of that messy crap into network-specific daemons, so a user program could make a network call just by calling fd = ipcopen("string-destination-name") without knowing or caring whether the network transport was TCP or Datakit or involved forwarding over Datakit to a gateway that then placed a TCP call to the Internet or whatnot. That's what the connection server was all about: https://www.bell-labs.com/usr/dmr/www/spe.pdf Again, the API is not specific to the stream system. It wouldn't be hard to write a connection server that provided the same universal just-use-a-string interface (with the privileged parts or network details left up to daemons) on a system with only socket networking; the only subtle bit is that it needs to be possible to pass an open file descriptor from one process to another (on the same system), which I don't think the socket world had early on but I believe they added long ago. -- There's nothing especially hard about UDP or broadcast. It's not as if the socket abstraction has some sort of magic datagram-specific file descriptor. Since every message sent and every message received has to include the far end's address info, you have to decide how to do that, whether by specifying a format for the data (the first N bytes are always the remote's address, for example) or provide an out-of-band mechanism (some ioctl mess that lets you supply it separately, a la sendto/recvfrom, and encodes it as a control message). There was an attempt to make UDP work in the 9th/10th edition era. I don't think it ever worked very cleanly. When I took an unofficial snapshot and started running the system at home in the mid-1990s, I ended up just tossing UDP out, because I didn't urgently need it (at the time TCP was good enough for DNS, and I had to write my own DNS resolver anyway). I figured I'd get around to fixing it later but never did. But I think the only hard part is in deciding on an interface. -- It's certainly true that the Research-system TCP/IP code was never really production-quality (and I say that even though I used it for my home firewall/gateway for 15 years). TCP/IP wasn't taken as seriously as it ought to have been by most of us in 1127 in the 1980s. But that wasn't because of the stream structure--the IP implementation was in fact a copy of that from 4.2 (I think) BSD, repackaged and shoehorned into the stream world by Robert T Morris, and later cleaned up quite a bit by Paul Glick. Maybe it would have worked better had it been done from scratch by someone who cared a lot about it, as the TCP/IP implementors in the BSD world very much did. Certainly it's a non-trivial design problem--the IP protocols and their sloppy observance of layering (cf the `pseudo header' in the TCP and UDP standards) make them more complicated to implement in a general-purpose framework. Or maybe it just can't be done, but I wish someone had tried in the original simpler setup rather than the cluttered SVr4 STREAMS. Norman Wilson Toronto ON

2 years, 11 months

1
0
0 0

sockets [was Re: forgotten versions]

by Paul Ruizendaal

> Sockets (which btw, totally SUCK PUS) were coded into things > and even (YECHH) made POSIX and IETF spec status. Streams didn't stand > a chance. The question that originally pulled me into researching Unix networking 1975-1985 was more or less “how did we end up with sockets?”. That was 7 years or so ago, I now have a basic feel for how it came to be, and I also have better appreciation of the trade offs. What is the most “Unixy” of networking (as in the API and its semantics) is not something with an easy answer. If I limit myself to the 1975-1985 time frame, I see three approaches: 1. The API used in Arpanet Unix, which was also used by BBN in its first reference implementation of TCP/IP 2. The BSD sockets API, in two flavours: the Joy flavour in BSD4.1a, and the Karels flavour in BSD4.1c and later 3. The Ritchie/Presotto IPC library / API from V8/V9. This evolved into SysV networking, but the original is the clean idea At a high level of abstraction, there is a lot of similarity; close-up they are quite different. I like all three solutions! One thing that struck my attention was that the Ritchie/Presotto IPC library has the concept of “calling” a host and the host/network can reply with a response code (“line busy”, “number unknown”, “not authorised”, etc.). BSD sockets do not cover that. I guess it derives from Spider/Datakit having that functionality, and Arpanet / tcp-ip not having that (resorting to a connection ‘reset’ or dead line instead). Sockets have a more elegant solution for connectionless datagrams (imo), and for the same reason I guess. Sure, sockets has too much of the implementation sticking through the abstractions, but it is IMO not a bad design. That it became dominant I think is in equal measure due to economics and due to being “good enough”. If someone has a proposal for a network API that is cleaner and better than what was out there, and would have worked with the hardware and use cases of the early 80’s, I’m all ears. But maybe better on COFF... Paul

2 years, 11 months

1
0
0 0

Re: forgotten versions

by Paul Ruizendaal

Wholeheartedly agree with the observations on forgotten versions, lack of source and a smaller pool of people back in the day. It is not just the Research versions, also the internal AT&T versions and the base System V versions get little attention. Same reasons I think. Luckily, these days the sources are available (although in the case of SysV of unclear legal status). Part of the problem I think is that it is not well known what innovations are in each version. About 2 years ago I did a lot of spelunking through the V8 source and with the help of this list could come up with a list of highlights for V8 (text is now on the TUHS V8 source web page). Never had the time to do that for V9. I think it was mentioned that it had a new filesystem with a bitmap free list. Also, it seems to have a lot of cleaned-up implementations of things that were new and rough in V8. No clue what was new in V10. Similar with Unix 3, Unix 4 and Unix 5. I’m thrilled that the docs for Unix 4 showed up recently. In these doc’s there is no material on IPC. From this I think that the IPC primitives from CB-Unix did not get merged in Unix 4, but only in Unix 5 (in a reworked form). Personally, I’m still working (off and on) on recreating the Reiser demand paging system. To keep it interesting I’ve now got Sys III running on a small RISC-V board, and when I find another time slot I’ll try to add Reiser paging to it. So the forgotten versions are only mostly forgotten, not totally forgotten :^)

2 years, 11 months

1
0
0 0

Re: Documentation for Unix 4.0

by Norman Wilson

Maybe make www.tuhs.org a CNAME for tuhs.org? Surely a site devoted to the history of UNIX should use a real link, not a symbolic one. Norman `Old Fart' Wilson Toronto ON

2 years, 11 months

5
5
0 0

Re: Source code for SCCS

by Paul Ruizendaal

It would seem that a Spinellis-like exercise for SCCS is possible: PWB1.0 (1978): https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/sccs4 SysIII (1980): https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/sccs SysVr1 (1983): https://www.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/cmd/sccs SysVr2 (1984): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr2-vax/src/cmd/sccs SysVr3 (1987): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr3/301/usr/src/cmd… SysVr4 (1988): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr4/svr4/cmd/sccs Ultrix3.1 (1988): https://www.tuhs.org/cgi-bin/utree.pl?file=Ultrix-3.1/src/cmd/sccs I did not find SCCS sources included with the BSD sources on TUHS, but there is a front-end “sccs” command. For sure, SCCS was used for BSD development. Kirk McKusick’s DVD has a directory "CSRG/historic1/sccscmds”, but I did not look into this further. From here the trail probably continues with Solaris, GNU and Bitmover -- all very much outside my timeframe of research. Paul > The original Marc Rochchild/John Mashey and team code from PWB 1.0 can be > found: http://tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz > In the directory: sys/source/sccs4 > The man pages are in the same archive but mixed with the rest of the > commands in usr/man/man* > > That said, there is Gnu version of same written C++ if IIRC: > https://www.gnu.org/software/cssc/ > > And there's more ... but I'll Larry offer details here other than point out > his: http://www.bitmover.com/bitsccs/ [which is of BitKeeper] is a > more modern implementation still]

2 years, 11 months

3
2
0 0

Documentation for Unix 4.0

by Warren Toomey

Hi all, we have a new addition to the Unix Archive at: https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ This is the documentation for Unix 4.0 which preceded System V. The documents were provided by Arnold Robbins and scanned in by Matt Gilmore. Cheers, Warren

2 years, 11 months

12
21
0 0

blast from the past

by Andrew Hume

this is an old video, new to me, but i’m sure others on this list have seen it. its a little long, but has al aho, jon bentley, bjarne, ken&denis, plan 9 amongst others. https://www.youtube.com/watch?v=IFfdnFOiXUU&t=2s <https://www.youtube.com/watch?v=IFfdnFOiXUU&t=2s>

2 years, 11 months

2
1
0 0

Fwd: [simh] Announcing the Open SIMH project

by Clem Cole

Announcing the Open SIMH project SIMH is a framework and family of computer simulators, initiated by Bob Supnik and continued with contributions (large and small) from many others, with the primary goal of enabling the preservation of knowledge contained in, and providing the ability to execute/experience, old/historic software via simulation of the hardware on which it ran. This goal has been successfully achieved and has for these years created a diverse community of users and developers. This has mapped to some core operational principles: First, preserve the ability to run old/historically significant software. This means functionally accurate, sometimes bug-compatible, but not cycle-accurate, simulation. Second, make it reasonably easy to add new simulators for other hardware while leveraging common functions between the simulators. Third, exploit the software nature of simulation and make SIMH convenient for debugging a simulated system, by adding non-historical features to the environment. Fourth, make it convenient for users to explore old system environments, with as close to historical interfaces, by mapping them to new features that modern host operating systems provide. Fifth, be inclusive of people and new technology. It's serious work, but it should be fun. Previously, we unfortunately never spent the time to codify how we would deliver on these concepts. Rather, we have relied on an informal use of traditional free and open-source principles. Recently a situation has arisen that compromises some of these principles and thus the entire status of the project, creating consternation among many users and contributors. For this reason, a number of us have stepped up to create a new organizational structure, which we call "The Open SIMH Project", to be the keeper and provide formal governance for the SIMH ecosystem going forward. While details of the structure and how it operates are likely to be refined over time, what will not change is our commitment to maintaining SIMH as a free and open-source project, licensed under an MIT-style license as shown on the "simh" repository page. It is our desire that all of the past users and contributors will come to recognize that the new organizational structure is in the best interests of the community at large and that they will join us in it. However, this iproject as defined, is where we intend to contribute our expertise and time going forward. At this point, we have in place the following, although we foresee other resources being added in the future as we identify the need and execute against them: A Github "organization" for the project at https://github.com/open-simh A Git repository for the simulators themselves at https://github.com/open-simh/simh The license for the SIMH simulator code base, found in LICENSE.txt in the top level of the "simh" repository. The "SIMH related tools" in https://github.com/open-simh/simtools. This is also licensed under MIT style or BSD style open source licenses (which are comparable apart from some minor wording differences). A "SIMH Steering Group" -- project maintainers and guides. The conventional git style process is used for code contributions, via pull request to the project repository. The Steering Group members have approval authority; this list is likely to change and grow over time. By formalizing the underlying structure, our operational principles and guidance can best benefit the community. These are being developed and formalized, with a plan to publish them soon. We have used our best judgment in setting up this structure but are open to discussion and consideration of other ideas, and to making improvements. Many of us have been part of different projects and understand that past mistakes are real. We have tried to learn from these experiences and apply the collected wisdom appropriately. We desire to hear from the community as we update and refine the operating structure for the Open SIMH project. We hope for your patience and look forward to your support as we work to refine the organization and be able to provide this wonderful resource for anyone to use as we continue to evolve the technology provided by the SIMH system. The SIMH Steering Group Clem Cole Richard Cornwell Paul Koning Timothe Litt Seth Morabito Bob Supnik ᐧ ᐧ ᐧ

2 years, 11 months

20
56
0 0

Please move the SIMH discussion to COFF

by Warren Toomey

Hi all, I think it's time to move the (no longer) SIMH discussion over to the COFF mailing list. The S/N ratio is dropping and we are straying too far away from the Unix side of things. Many thanks! Warren

2 years, 11 months

1
0
0 0

Re: [TUHS, groff] 1981 edition of AT&T Nroff/Troff User's Manual

by Douglas McIlroy

> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_… Since PDF didn't exist in 1981, the document is either a scan or the result of a recent *roff run on ancient source. If it was made from source, it's an impressive testimonial to the longevity and stability of troff. Most probably it's a scan, in which case we owe many thanks to the public-spirited person who digitized this trove. Was it you, Arnold? Doug

2 years, 11 months

3
2
0 0

Re: Fwd: [simh] Announcing the Open SIMH project

by Bakul Shah

On Jun 3, 2022, at 4:48 PM, Larry McVoy <lm(a)mcvoy.com> wrote: > Um, so there were 3: 386, Net and Free. That's already 2 too many. My recollection matches what Warner is saying. NetBSD & FreeBSD got going *because* 386BSD was effectively frozen. It wasn't dead dead but patches were not being upstreamed (as we say now), and so on. I do agree with you that even two variants were 1 too many. But even one would probably not have mattered as the AT&T lawsuit was a huge cloud on *BSD's popularity. As well as there were other factors. Linus and Linux had a much better story, its development was more nimble, with many younger and much more enthusiastic developers/users etc. Not that anyone really cares at this point except some graybeards! The Open SIMH project sounds great!

2 years, 11 months

1
0
0 0

Historical application software

by Paul Ruizendaal

I came across a website that discusses reviving an old binary for Lotus 1-2-3 for SysV Unix (386 COFF), on the way to making it run on Linux: https://lock.cmpxchg8b.com/linux123.html The audience here may enjoy the read, and maybe it is of use when reviving other old application software for 1980’s and 1990’s Unix. The key part I think is this: Quote: "Yikes - it’s an original unstripped object file from 1-2-3. There are nearly 20,000 symbols including private symbols and debug information. Why would Lotus ship this? It’s so big it must have required them to phyiscally ship an extra disk to every customer? Could it have been a mistake, accidentally left on the final release image? I had so many questions, but I’m not old enough to have any experience with SysV, so I asked the greybeards on alt.folklore.computers if they had seen this before and why this might have happened. The answer was that this is probably deliberate - dlopen() was not widely available on UNIX in the early 90s, so there was no easy way to load native plugins or extensions. To solve this, vendors would ship a bunch of partially linked object files with a script to relink them with your extensions – Clever!"

2 years, 11 months

9
16
0 0

Re: Anyone have an interest in really old analog multimeters and a vacuum tube tested circa 1960s or 1950s?

by Kenneth Goodwin

The party also has a vintage AUTOMOBILE tester If anyone knows of a car collector with a passion for such things interested in a display piece Or if you still have the first car you ever bought sitting in the garage Link to posting attached. https://cnj.craigslist.org/zip/d/hightstown-for-scrap-vintage-eico-888/7489… I am in direct contact with the party offering these items. They are all coming out of basement storage On Sun, May 29, 2022, 8:53 AM Kenneth Goodwin <kennethgoodwin56(a)gmail.com> wrote: > No worries. > > On Sun, May 29, 2022, 12:04 AM John Sambrook <john(a)common-sense.com> > wrote: > >> Hi Kenneth - >> >> Thank you for the pics. >> >> The tube tester appears to be just the meter from a whole tester. >> Usually, a tube tester is about the size of a small suitcase and has a >> number of different sockets on its front panel for testing different types >> of tubes. >> >> One of the meters seems worthwhile, but at this time, I am going to >> decline and hope that at least some of the gear can be salvaged. >> >> Thank you for the consideration. >> >> John >> >> Sent from my iPhone >> >> On May 28, 2022, at 7:18 PM, Kenneth Goodwin <kennethgoodwin56(a)gmail.com> >> wrote: >> >> >> One thing >> >> Sort of looks like the tube checker might be missing a whole lot of the >> rest of it. >> Like an entire cabinet of stuff >> >> See photos >> >> On Sat, May 28, 2022, 10:11 PM Kenneth Goodwin < >> kennethgoodwin56(a)gmail.com> wrote: >> >>> Everyone feel free to inquire around. >>> If it all goes to one private party. Then at least they will know who to >>> passing along to. >>> >>> On Sat, May 28, 2022, 7:45 PM Clem Cole <clemc(a)ccc.com> wrote: >>> >>>> What about the rescue mailing list? >>>> >>>> On Sat, May 28, 2022 at 7:31 PM Ed Cashin <ecashin(a)noserose.net> wrote: >>>> >>>>> If you don't get a response here, I wouldn't mind asking on the >>>>> Heinbach subreddit. Just let me know. >>>>> >>>>> Heinbach is a musician who creates live and recorded music using lab >>>>> equipment. He has a large following of inspired creators who would >>>>> probably love to use this equipment. >>>>> >>>>> >>>>> On Sat, May 28, 2022 at 6:09 PM Kenneth Goodwin < >>>>> kennethgoodwin56(a)gmail.com> wrote: >>>>> >>>>>> Details >>>>>> >>>>>> 1) Knight Allied Radio volt meter 446-06235 >>>>>> 2) Precision Apparatus series 85 volt meter >>>>>> 3) Weston Model 676 Tube checker >>>>>> >>>>>> Useful as display pieces >>>>>> >>>>>> Presumed to all be functional. >>>>>> >>>>>> On Sat, May 28, 2022, 6:06 PM Kenneth Goodwin < >>>>>> kennethgoodwin56(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> I have a party in Hightstown NJ >>>>>>> Looking to donate them. >>>>>>> >>>>>>> Will follow up with specs. >>>>>>> >>>>>>> They already contacted the radio museum in Wall NJ >>>>>>> >>>>>>> I told them to try VCF since they should be a separate organization. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ed Cashin <ecashin(a)noserose.net> >>>>> >>>> -- >>>> Sent from a handheld expect more typos than usual >>>> >>>

2 years, 11 months

1
0
0 0

Why is it always "fast boot" in 2.11BSD?

by Matthias Bruestle

Hi, I have noticed, that 2.11BSD is in all cases where I looked set to "fast boot", which AFAIK means no fsck of at least /. I found nobody talking about this or providing information about how to change it to "slow boot" with a proper check, which is now normal. Is there a reason why it is not possible to deactivate fast boot? Or is it just that nobody bothered to do it? Thanks Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine

2 years, 11 months

2
4
0 0

ACM opens up much of its archives

by Douglas McIlroy

>> If you’re a *current* member of these societies then you should have good access to journal content. >I believe this is true for ACM, but for IEEE not so much. You have to pay for a digital library membership _in addition to_ your standard membership ACM is the same. At $99/year membership is a bargain by ordinary professional society standards. But they charge an additional $99 for access to 21st-century Digital Library.content. Doug

2 years, 12 months

4
3
0 0

ACM opens up much of its archives

by arnold＠skeeve.com

https://associationsnow.com/2022/05/the-way-things-were-why-open-access-to-… cm-digital-library-matters/

2 years, 12 months

7
7
0 0

Fwd: ACM Digital Library now open access

by Richard Salz

From an internal $WORK chat: The ACM Digital Library now offers access to ~50 years of papers/records without paywall or registration: https://associationsnow.com/2022/05/the-way-things-were-why-open-access-to-… This includes Dennis Ritchie & Ken Thompson's seminal 1974 "The UNIX Time-Sharing System" (https://dl.acm.org/doi/pdf/10.1145/357980.358014) an interview with one Steve Jobs from 1989 ( https://dl.acm.org/doi/pdf/10.1145/63334.63336) where he discusses basing NeXTSTEP on "Berkeley UNIX" (aka BSD) + Mach and how the (previous year's) Morris Worm "isn't a really serious problem", and goes all the way back to 1951's paper on the UNIVAC ( https://dl.acm.org/doi/pdf/10.1145/1434770.1434772)

3 years

2
1
0 0

First test e-mail

by Warren Toomey

If I'm lucky, this will be the first e-mail to the TUHS list using the mailman3 software on the new minnie server. Cheers, Warren

3 years

13
18
0 0

Re: Pronunciation

by Norman Wilson

It's spelled TUHS but it's pronounced values of beeta may give rise to dom!

3 years

3
2
0 0

Archives of the TUHS mailing list

by Warren Toomey

All, now that the TUHS list has migrated over to the new mailman3 system, I should point out where the list archives are now available. They are: https://minnie.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/ - new mailman3 format https://minnie.tuhs.org/pipermail/tuhs/ - old mailman2 format https://www.tuhs.org/Archive/Documentation/TUHS/Mail_list/ - same as above, but in a format that makes it easier to download All mail to the TUHS list should, eventually, end up in all three places. Cheers, Warren

3 years

1
0
0 0

Old UNIX file system formats

by norman＠nose.cita.utoronto.ca

I've assembled some notes from old manuals and other sources on the formats used for on-disk file systems through the Seventh Edition: http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html Additional notes, comments on style, and whatnot are welcome. (It may be sensible to send anything in the last two categories directly to me, rather than to the whole list.)

3 years

2
1
0 0

tuhs.org e-mail cutover

by Warren Toomey

Hi all, I'm hoping to cut the tuhs.org e-mail from the old server over to the new server tomorrow, at around 0400 UTC May 18 2002. I'll stop accepting e-mails on the old server first, then cut over and start accepting e-mails on the new server. If something goes pear shaped, you'll be able to contact me on my Gmail address warren.toomey@.... and on my DoctorWkt twitter account. Cheers & fingers crossed :-) Warren

3 years

1
1
0 0

Unix-haters handbook on Kindle for $3

by Richard Salz

Humor is kind of screed-like and may be dated, but some here might find it a fun read. (Disclaimer: I wrote the chapter on Usenet.)

3 years

3
2
0 0

[tuhs] Go programming language

by Nelson H. F. Beebe

List readers may enjoy a new article about the history of the Go programming language published today: Russ Cox, Robert Griesemer, Rob Pike, Ian Lance Taylor, and Ken Thompson The Go programming language and environment Comm. ACM 65(5) 70--78 May 2022 https://doi.org/10.1145/3488716 https://dl.acm.org/doi/10.1145/3488716 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

3 years

2
1
0 0

First Unix-like OSes not derived from AT&T code?

by Andrew Warkentin

What was the first "clone" functional Unix (i.e. an OS not derived from genetic Unix code but highly compatible with genetic Unix)? Idris is the earliest such OS of which I am aware (at least AFAIK it's not a genetic Unix), but was it actually the first? Similarly, which was the first "outer Unix-like" system (i.e. one with strong Unix influence but significantly incompatible with functional Unix)? Off the top of my head the earliest such system I can think of is Thoth (which predates Idris by almost 2 years), but again I'm not sure if it was actually the first.

3 years

34
76
0 0

Document management in Unix, back in the day?

by Will Senn

Today I bit the bullet and dropped my many articles and electronic documents related to my technical explorations into Zotero. I was tired of constantly having to remember where the documents were located and I wanted to be able to curate them better (I tried git for a while, back when, but I'm not a fan of non-text data in my repos, and it wasn't really much better than the base file system approach). I've been using Zotero for years now, for academic works, but not for technical works unrelated to my research. I realized the man-years of effort to clean up the entries that I had created in about 30-40 seconds of exciting drag and drop, just about the time I deleted them from their original locations. I think the work will pay off in due time, but we'll see. Then I thought, surely, I'm not the first person to have had this problem... it occurred to me that y'all must have faced this very problem, a few years in, back in the late 70's, early 80's. That is, document management. What did you do, variously, considering both text and non-text? Will

3 years

8
9
0 0

FTP service is not happy

by Gregg Levine

Hello! As this service is being phased out, I am trying to download the relevant (well relevant to me) bits from it. And as it happens I found that the clients I use are triggering an interesting problem. This is from ncftp on Linux ncftp> open minnie.tuhs.org Server hungup immediately after connect. Stop connecting frequently Sleeping 20 seconds... And I first saw it using FileZilla, I promptly scaled it back from multiple connections for downloads, to one and only one, but it repeated. To put it simply, what am I doing wrong here? ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

3 years

1
0
0 0

Re: [TUHS] Capitalization question: UNIX/Unix and MULTICS/Multics?

by Douglas McIlroy

The main FJCC 1964 papar, by Vyssotsky, Corbato, and Graham, spelled Multics with an initial cap. By contrast, Ken transcribed the aural pun as UNIX. The lawyers did their best to keep it that way after most of us had decided it looks better as a proper noun. As I recall, there was an acronymic reading of Multics, but it wasn't taken seriously enough to drag the word into all caps. Nobody proposed an acronymic reading of UNIX. So both words defy the convention of rendering acronyms in upper-case. Doug

3 years

2
1
0 0

Re: [TUHS] Capitalization question: UNIX/Unix and MULTICS/Multics?

by jnc＠mercury.lcs.mit.edu

> From: Dan Cross > In Kernighan's Unix memoir, on page 9, he touches briefly on the > typography of "Unix": > "(Multics was originally spelled MULTICS ..." > Here, he is talking about interning at MIT in 1966. bwk would certainly > know better than me, but I can find no historical reference to this > "MULTICS" spelling; is anyone familiar with that? I looked at my early Multics stuff, and it's "Multics" almost everywhere: - "GE-645 System Manual", GE, 1968 - "The Multics Virtual Memory", GE, 1970 - "Introduction to Multics", MIT MAC TR-123, 1973 However, in my "A New Remote-Access Man-Machine System", on the title papge it says "Reprints of the MULTICS system presented at the" [FJCC, 1965]. No clue as to who printed it, or when - and all the FJCC papers themselves use "Multics". I have yet to ask Jerry Saltzer, but I suspect that if it ever was 'MULTICS', it was at a _very_ early stage, and was formally changed even before the FJCC papers (which were themselves very early). BTW, ISTR hearing that it was 'Unix' originally, and the 'UNIX' spelling was adopted at the insistence of Bell lawyers. So I went looking for an early (i.e. PDP-7 era) scanned document, to see what it was then, and all I could find was: https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZ… which seems to be from just after the PDP-7 -> PDP-11/20 transition, and it uses 'UNIX'. Would the Bell lawyers have already been involved at that stage? Noel

3 years

1
0
0 0

Capitalization question: UNIX/Unix and MULTICS/Multics?

by Dan Cross

This is tangentially related to Unix, and came up randomly at work yesterday. In Kernighan's Unix memoir, on page 9, he touches briefly on the typography of "Unix": "(Multics was originally spelled MULTICS, but the lower-case version is less visually jarring; as with UNIX versus Unix and some other all-caps words, I’ll use the nicer-looking form even though it’s not historically accurate.)" Here, he is talking about interning at MIT in 1966. bwk would certainly know better than me, but I can find no historical reference to this "MULTICS" spelling; is anyone familiar with that? The earliest reference I can find (the 1965 paper from the FJCC: https://dl.acm.org/doi/pdf/10.1145/1463891.1463912) uses the more "Multics" styling, but it may have been typeset later. Alternatively, could someone send me Brian's email address? - Dan C.

3 years

2
1
0 0

Re: [TUHS] Armando plate

by Clem Cole

I did not realize Shannon must have had it first. Armando had it on his Nisson and he passed it to John Hall (Maddog) when he moved. Somewhere I have a picture of Armando’s car and my then Black Jetta with the MA plate together. On Tue, May 10, 2022 at 9:53 PM Tom Lyon <pugs(a)ieee.org> wrote: > Bill Shannon had the actual NH UNIX plates.Upgraded to VMUNIX for > California. > > On Tue, May 10, 2022 at 6:03 PM Clem Cole <clemc(a)ccc.com> wrote: > >> Ultrix plates were much later. The original Unix plates were there for a >> few years. >> >> On Tue, May 10, 2022 at 8:58 PM Kenneth Goodwin < >> kennethgoodwin56(a)gmail.com> wrote: >> >>> As I recall, The UNIX plates were the first in the series and >>> distributed at a USENIX conference AT THE DEC booth The next year, they >>> came out with the ULTRIX plates. >>> >>> On Tue, May 10, 2022, 8:54 PM Steve Bourne <srb(a)acm.org> wrote: >>> >>>> Armando also responsible for the UNIX "live free or die" plates. I >>>> still have a few. >>>> >>>> Steve >>>> >>> -- >> Sent from a handheld expect more typos than usual >> > > > -- > - Tom > -- Sent from a handheld expect more typos than usual

3 years

2
2
0 0

Re: [TUHS] {TUHS] Interesting Commentary on Unix from Multicians

by Douglas McIlroy

> Single Level Storage is an awesome concept and removes so many ugly > hacks from algorithms that otherwise have to process data in files. This was Vic Vyssotsky's signature contribution to Multics, though in typical Vyssotsky fashion he never sought personal credit for it. Other awesome Vyssotsky inventions: BLODI (block diagram), the first data-flow language, for sample-data systems. Parallel flow analysis (later reinvented and published by John Cocke). Vic installed this in Fortran to produce diagnostics such as, "If the third branch of IF statement 15 is ever taken, then variable E will be used before being set". Darwin, the original game of predation and self-reproduction among programs. Corewars.org keeps a descendant version going 60 years later. A minimum-spanning-tree algorithm quite different from the well-known methods due to his colleagues Bob Prim and Joe Kruskal, again unpublished. Not long ago on TUHS, Andrew Hume told how Vic found the same isolated bug in dc by mathematically generating hard cases that Andrew stumbled on by accident, As you may infer, Vic is one of my personal computing heroes. Doug

3 years

9
11
0 0

Armando plate

by Steve Bourne

Armando also responsible for the UNIX "live free or die" plates. I still have a few. Steve

3 years

4
3
0 0

conventions around zero padding in ip4

by ron minnich

I first learned in the 80s that 127.1 meant 127.0.0.1. I always assumed zero padding was defined in a standard *somewhere*, but am finding out maybe not. I talked to the IP OG, and he tells me that padding was not in any standard. [side note: it's weird and wonderful to still have so many people "present at the creation" of computing as we know it still around, and to find they are so willing to answer naive questions!] Padding is a standard in ip6, possibly because the addresses are so long. :: is your friend. IP4 padding came up recently: the ip command interprets 10.2 as 10.2.0.0, whereas most things (golang libraries, ping, ...) interpret it as 10.0.0.2. The latter interpretation accords with what I learned 40y ago. But, I find myself wondering: where was the first use of the IP4 zero padding convention?

3 years

7
13
0 0

TUHS web server has changed

by Warren Toomey

Hi all, I've just changed the DNS CNAME record of www.tuhs.org from minnie.tuhs.org (45.79.103.53) to newmin.tuhs.org (50.116.15.146). Minnie is running Ubuntu 18.04LTS and is getting a bit long in the tooth. Newmin is running 22.04LTS. So far I've got the web service up and running on newmin. Doing the e-mail migration will be fun :-) Let me know if you spot anything wrong with the new web server. I've also set up oldwww.tuhs.org which points at minnie, so you can still get to things on the old server. Cheers, Warren

3 years

12
18
0 0

Re: [TUHS] conventions around zero padding in ip4

by jnc＠mercury.lcs.mit.edu

> There were other ways of specifying a IP address numerically, initially; I decided to set the Way-Back Machine to as close to 0 as I could get, and looked to see what the Terminal Interface Unit: https://gunkies.org/wiki/Terminal_Interface_Unit whose source I recently recovered, did. This is an interesting implementation, because it was definitely one of the first 4 TCP implementations done (before any UNIX ones); likely one of the first two, along with the TENEX one. (Actually, they both likely originally predate the split of TCP and IP into separate protocols, although this version post-dates that split.) The manual: http://ana-3.lcs.mit.edu/~jnc/tech/mos/docs/tiunv1.lpt (in "B. TELNET Commands") and the source: http://ana-3.lcs.mit.edu/~jnc/tech/mos/tiu/telnet-1.mac disagree on how the user gave addresses in numeric form in an 'open' command; both agree that it was '@O <rest>,<net>,<socket>', but the manual claims that 'rest' "may be specified symbolically, or numerically in decimal", but the code shows that '#xxx' could also be used, to give it in hex. (Although if hex were used, the number could be a max of 16 bits; decimal alloweded up to 42 bits.) > From: Michael Kjörling > Looks like [A/B/C addresses] happened in 1978 or thereabouts? > https://www.rfc-editor.org/ien/ien46.txt No; it post-dates the IEN era; "Assigned Numbers" of September 1981 (RFC-790) is the first mention I could find of it. (That Dave Clark IEN is talking about what later became 'IP subnets' - which ironically long pre-date A/B/C - see IEN-82, February 1979.) The Internet Protocol spec of September 1981 (RFC-791) also has A/B/C; my memory is that this change was _not_ discussed in the INWG, Postel just sprung it on us in these two RFCs. I suspect what happened is that Jon (as keeper of the network numbers) realized that there was an increasing demand for network numbers, and 256 would only last so long, so he sprung into action and did the A/B/C thing. (If this topic is of more interest, it should get moved to the 'internet-history' list, it's off-topic here.) Interestingly, RFC-790 says: "One notation for internet host addresses commonly used divides the 32-bit address into four 8-bit fields and specifies the value of each field as a decimal number with the fields separated by periods." Note the "one notation", implying that it wasn't any kind of standard at that point. Noel

3 years

1
0
0 0

Re: [TUHS] conventions around zero padding in ip4

by jnc＠mercury.lcs.mit.edu

> From: Ron Minnich > I first learned in the 80s that 127.1 meant 127.0.0.1. I always assumed > zero padding was defined in a standard *somewhere*, but am finding out > maybe not. I talked to the IP OG, and he tells me that padding was not > in any standard. I don't think it was very standardized; I've been working on the Internet since 1977, and this is the very first I ever recall hearing of it! :-) > From: Bakul Shah > The converse question is who came up with the a.b.c.d format where each > of a,b,c,d is in 0..255? Again, that was not standardized at an early stage, but was, as best I can now recall, just adopted by general usage (i.e. without any formal discussion). There were other ways of specifying a IP address numerically, initially; e.g. for a while at MIT we were using w,x,y,z (with w-z in octal - note the ','s, which were a syntatic tag for the octal form), which was easier to interpret when looking at a packet dump on a PDP-11. Here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/arc/tftp.c.1 is the source for a user command (from July, 1979) which allowed host addresses to be given in that form. I'm not sure who came up with the dotted decimal form; I suspect you'd need to find some really old email archives, and look in that. There was, early on, a list called "tcp-ip", used by people who were getting their machines ready for the NCP->TCP/IP conversion. However, I suspect the 'dotted quad' predates that; there was an even earlier mailing list, used in early experimental work, by the group working on internet technology, whose name escapes me (it was something like "internet working group"). It's possible that an IEN: https://www.rfc-editor.org/ien/ien-index.html might mention the 'dotted quad' syntax; TCP and IP meeting minutes would be a good place to start. Noel PS: The A/B/C addresses are actually a moderately late stage of IP addresses. At the very start, they were all '8 bits network numbers, and 24 bits of 'rest''.

3 years

2
1
0 0

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

by jnc＠mercury.lcs.mit.edu

> From: Tom Lyon > there were a few icustomer nstallations. Bell Labs Indian Hill was one > - so that's why TSS was the base of their UNIX port. "A UNIX System Implementation for System/370" (by W. A. Felton, G. L. Miller, and J. M. Milner): https://www.bell-labs.com/usr/dmr/www/otherports/ibm.html says "code to support System/370 I/O, paging, error recording and recovery, and multiprocessing already existed in several available operating systems, we investigated the possibility of using an existing operating system, or at least the machine-interface parts of one, as a base to provide these functions for the System/370 implementation ... Of the available systems, TSS/370 came the closest to meeting our needs and was thus chosen as the base for our UNIX system implementation". Alas, it doesn't say which other systems were also considered. >> On May 6, 2022, at 09:39, arnold(a)skeeve.com wrote: >> So, why, given the letter from these folks, including DMR, did they go >> ahead and use the TSS solution anyway? That paper says: "We initially thought about porting the UNIX operating system directly to System/370 with minimal changes. Unfortunately, there are a number of System/370 characteristics that, in the light of our objectives and resources, made such a direct port unattractive. The Input/Output (I/O) architecture of System/370 is rather complex; in a large configuration, the operating system must deal with a bewildering number of channels, controllers, and devices, many of which may be interconnected through multiple paths. Recovery from hardware errors is both complex and model-dependent. For hardware diagnosis and tracking, customer engineers expect the operating system to provide error logs in a specific format; software to support this logging and reporting would have to be written. ... Finally, several models of System/370 machines provide multiprocessing, with two (or more) processors operating with shared memory; the UNIX system did not support multiprocessing." Presumably these factors outweighed the factors listed in the Haley/London/Maranzaro/Ritchie letter. Noel

3 years

2
1
0 0

Alternative Implementation Proposal for Unix/370 (BTL, 1979)

by Tom Lyon

I was (re?)introduced to Chuck Haley recently and discovered he had a copy of a Bell Labs memo from himself, London, Maranzaro, and Ritchie. They suggest that the path pursued to get UNIX running in/under TSS/370 was the hard way to go. Enjoy: http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_… -- - Tom

3 years

6
6
0 0

tuhs hiccups?

by Tom Lyon

For some reason, against my wishes, I'm not getting TUHS messages as they happen, but in batches (not digest) after 5-7 days. Last I've received right now is from May 2. Anyone know why? -- - Tom

3 years

2
1
0 0

Bob Widlar Poster

by Janek Gál

Hey folks, there is a cool poster by Bob Widlar, which we would like to have as a big poster in the hackspace: https://august.sax.de/widlar.jpg This is already a high resolution scan (2048 × 3048) but we are looking for something better (for A0 paper). Does anyone have something like this maybe still in his collection? greetings, Janek :) -- Janek Gál <janek(a)sax.de> Dresden, Germany http://www.sax.de

3 years

1
0
0 0

Re: [TUHS] First Unix-like OSes not derived from AT&T code?

by John Foust

At 04:17 PM 5/2/2022, Dan Cross wrote: >I vaguely remember Metaware being somewhat religiously extreme, but again the details are fuzzy now. Was there some kind of ecclesiastical reference in the man page? I have the manuals around somewhere, and that rings a bell. I used Metaware High C and the Pharlap extender in the early 1990s in the odd 32-bit DOS enviroment to make 3D import/export plugins for Autodesk's 3D Studio. - John

3 years

1
0
0 0

Re: [TUHS] First Unix-like OSes not derived from AT&T code?

by Ronald Natalie

We got in on the W4 from the IBM Federal Systems guy (later dealt out to Loral, Martin Marietta, and then Lockheed-Martin). I started with those guy doing a contract job to craft the second nework interface into Secure Xenix (Jacob Recter I think was responsible for the first) to provide a secure downgrading system for some government entity. Then Intel developed the i860- and IBM came up with the Wizard card. This was only designed to be.a coprocessor card and was done down in Boca Raton. The fun and games with that one is that we were on early steppings of the processor chips and spent a lot of time coding around chip bugs (mostly with regard to interrupts). IBM/Intel had developed this thing called hostlink that was supposed to be useful, but we decided to port AIX to it. When IBM Owego came up with the W4, we were asked to port AIX again to it. We had one non-functional W4 kicking around for demo purposes that had 4 “delidded” i860 chips in it. I swapped one for an early stepping (useless) chip and kept one of the delidded ones which I still have in a box somewhere.

3 years

1
0
0 0

In case you haven't heard yet

by Wesley Parish

I went googling for "Thoth operating system source code" while reading the discussion on Unix-like OSes and found the following: https://securitronlinux.com/debian-testing/nextstep-operating-system-source… which led to https://www.nextcomputers.org/forums/index.php?topic=4690.0 which led to various NeXTStep fragments that might be of interest. Share and Enjoy! Wesley Parish

3 years

2
1
0 0

2.9BSD with MSCP Support

by Warren Toomey

[ This also in from Peter Klapper. The files are at: https://www.tuhs.org/Archive/Distributions/UCB/2.9BSD_MSCP/ ] This is a 2.9BSD kernel with a backported MSCP driver from 2.10BSD I tried to make a clean integration of the driver into the 2.9BSD source tree in order to be able use the standard procedures to configure and build the kernel. To try it, rename the original directories /usr/include/sys and /usr/src/sys and unpack the two tar archives into your /usr directory. Then change into /usr/src/sys/conf and just do a ./config for the kernel you want. I made some configurations for: MSCP23 (MSCP enabled kernel for the PDP11/23) MSCP73 (MSCP enabled kernel for the PDP11/73) FLOP23 (MSCP enabled 11/23 kernel for a boot floppy) FLOP73 (MSCP enabled 11/73 kernel for a boot floppy) MSCPSH (MSCP enabled kernel for an extended SIMH environment) You may need to adapt the kernel configurations for the correct timezone and maybe the line frequency. This is probably the most recent BSD system which runs on the PDP11/23. Read the full story about this here: https://forum.vcfed.org/index.php?threads/scientific-micro-systems-sms-1000… There is NO root password in this distribution. For installation on real hardware, at least a Maxtor XT-1085 (RD53) or larger is recommended. My SMS1000 system currently has a Maxtor XT-1140 installed. Original was an XT-1085 in the system. The disk layout for these two disks during installation is as follows: Maxtor XT-1085 / DEC RD53 ========================= 1024/8/18 interleave 1,4 --- layout --- root = ra(0,0), size 3200 swap = ra(0,6400), size 1920 usr = ra(0,10240), size 64180 Maxtor XT-1140 ============== 918/15/18 interleave 1,4 --- layout ---- root = ra(0,0), size 3200 swap = ra(0,6400), size 1920 usr = ra(0,10240), size 114880 I've split the data into 4 parts in order to not get too much when downloading: 1.) 29bsd-simh.tgz: A SIMH image including configuration file. "pdp11 sms1123.ini" 2.) 29bsd-smstape.tgz: A Linux dump of the QIC24 installation tape which was generated with my SMS1000 system. You can write this under Linux to a 60MB QIC tape with: "dd if=29bsd-sms-tape.dd of=/dev/st0" The SMS1000 generated format is not compatible with Linux, but the Linux dd'ed tape can be read by the SMS1000 system. 3.) 29bsd-tapefiles.tgz: The files to create a SIMH tape image, or real tape for another system. 4.) 29bsd-vtserver.tgz: The version of the vtserver and the corresponding configuration file with which I performed the successful initial installation. I worked with 19200bps, which is the maximum my SMS1000 supports on the console, under 2.9BSD only 9600bps works anyway. Have fun with it, if you find bugs, they may of course be mine. ;) I wish you and the community also a lot of fun with this version of 2.9BSD. // Peter

3 years

1
0
0 0

Pro/Venix 2.0: reconstructed

by Warren Toomey

Hi all, I just received this in the e-mail a few days ago: [ now at https://www.tuhs.org/Archive/Distributions/DEC/Venix/ProVenix_2.0/ ] From: Peter Klapper Subject: PRO/VENIX 2.0 reconstructed ... ... and tested, for your collection ;-) Probably the best OS for the Pro, see the benchmark: PRO380 - PRO/VENIX V2.0: ======================== pk$ dryr Dhrystone(1.1) time for 50000 passes = 86 This machine benchmarks at 581 dhrystones/second pk$ drynr Dhrystone(1.1) time for 50000 passes = 95 This machine benchmarks at 526 dhrystones/second The four additional floppy disks contain also the source code which I used to rebuild the missing binaries. I wish you and the community much fun with the "new" resurrected PRO/VENIX V2.0.

3 years

1
0
0 0

whereis command

by ron minnich

can someone point me at the earliest version of whereis? I first saw it in 4.1, but maybe it came sooner. Also, if you've got a link to man pages, thanks in advance. I'm trying but failing to find it. My daughter says I suck at web search, which, given where I work, is a bid sad :-)

3 years

6
8
0 0

Re: [TUHS] Interesting commentary on Unix from Multicians.

by jnc＠mercury.lcs.mit.edu

> From: Rich Morin <rdm(a)cfcl.com> > I'd love to hear from some folks who have used both Multics and > Unix(ish) systems about things that differ and how they affect the > user experience. {This is a bit behind the flow of the conversation, because I wanted to ponder for a while what I was going to say on this, to me, important topic.} Technicaly, I don't quite qualify (more below), but I do have an interesting perspective: I was the very first Unix person in the 'Multics' group at MIT-LCS - the Computer Systems Group, which contained Corby and Jerry Saltzer. The interesting thing, which may surprise some people, is that I _never_ got any 'anti-Unix' static from anyone in the group, that I can remember. (Maybe one grad student, who was a bit abrasive, but he and I had a run-in that was mostly? caused by my fairly rapid assumption, as an un-paid undergrad, of a significant role in the group's on-going research work. So that may have bled across a bitt, to Unix, which was 'my' baby.) I'm not sure what _they_ all made of Unix. None of us knew, of course, where it was going to go. But I don't recall getting any 'oh, it's just a toy system' (an attitude I'm _very_ familiar with, since it was what the TCP/IP people got from _some_ members of what later became the ISO effort). Of course, our Unix was a tiny little PDP-11/40 - not a building-sized multi-processor 'information utility' mainframe - so they may well have not thought of it in the same frame as Multics. Also, by the time I arrived the group was doing nothing on Multics (except below); everyone was focused on networks. So OS's were no longer a topic of much research interest, which may also have contributed. Anyway, technically, I don't count for the above, because I never actualy wrote code on Multics. However, I had studied it extensively, and I worked very closely with Dave Clark (a younger Multics light, later a leading figure in the early TCP/IP work) on projects that involved Multics and my machine, so I got to see up close what Multics was like as a system environment, as he worked on his half of the overall project. I've also pondered Multics in the decades since; so here's my take. I really, really liked Unix (we were running what turns out to have been basicaly a PWB1 system - V6, with some minor upgrades). I learned about it the way many did; I read the manuals, and then dove into the system source (which I came to know quite well, as I was tasked with producing a piece that involved a major tweak - asynchronous 'raw' DMA I/O directly to user processes). Unfortunately, one of the two (to me) best things about Unix, is something it has since lost - which is its incredible bang/buck ratio - to be more precise, the functionality/complexity ratio of the early versions of the system. (Its other important aspect, I think, was that its minimal demands of the underlying hardware [unlike Multics, which was irretrievably bound to the segmentation, and the inter-segment data and code connection] along with its implementation in what turned out to be a fairly portable language (except for the types; I had to make up what amounted to new ones.) So, what was Multics' major difference from other systems - and why was it good? I'd say that it was Multics' overall structuring mechanisms - the single-level store, with the ability to have code and data pointers between segments - and what that implied for both the OS itself, and major 'applications' (some of them part of the OS, although not the 'kernel' - like networking code). Unix had (and still may have, I'm not up on Linux, etc) a really major, hard boundary beween 'user' code, in processes,and the kernel. There are 'instructions' that invoke system primitives - but not too many, and limited interactions across that boundary. So, restricted semantics. Which was good in that it helped keep the system simple and clear - but it limited the flexibilty and richness of the interface. (Imagine building a large application which had a hard boundary across the middle of it, with extremely limited interactions across the boundary. Just so with the interface in Unix between 'user' code, and the kernel.) Multics is very different. The interface to the OS is subroutine calls, and one can easily pass complex data structures, including pointers to other data, any of which can be in the 'user's' memory, as arguments to them. The _exact_ same _kind_ of interface was available to _other_ major subsystems, not just the OS kernel. As I've mentioned before, Dave's TCP/IP for Multics was not in the kernel - it was ordinary user code! And he was able to work on it, test and install new versions - while the system was up for normal useage! Dave's TCP/IP subsystem included i) a process, which received all incoming ackets, and also managed/handled a lot of the timers involved (e.g. retransmission timeouts); ii) data segment(s), which included things like buffered un-acknowledged data (so that if a retransmission timer went off, the process would wake up and retransmit the data); iii) code segment(s): iiia) some for use by the process, like incoming packet processing; iiib) some which were logically part of the subsystem, but which were called by subroutine calls from the _user_'s process; and iiic) some which were commands (called by the user's shell), which called those iiib) procedures. (There were issues in security because Multics didn't have the equivalent of 'set-user-id' on a cross-subsystem subroutine calls - although I think there had been plans early on for that. When Dave's code was taken over by Honeywell, for 'production' use, whole whole thing was moved into a lower ring, so the database didn't have to be world-writeable in the user ring.) This is typical of the kind of structure that was relatively easy to build in Multics. Yes, one can do similar application without all those underlying mechanism; but Turing-completeness says one doeesn't need stacks to compute anything - but would any of us want to work in a system that didn't have stacks? We have stacks because they are useful. True, simple user applications don't need all that - but as one builds more and more complex support subsytems, that kind of environment turns out to be good to have. Think of a window system, in that kind of environment. Those 'tools' (inter-segment subroutine calls, etc) were created to build the OS, but they turned out to be broadly useful for _other_ complicated subsystems. I'm not sure I've explained this all wel, but I'm not sure I can fully cover the topic with less than a book. Noel

3 years, 1 month

3
2
0 0

Sad News - we last two wonderful people in the past few weeks.

by Clem Cole

I personally lost two friends and former colleagues recently that these list probably wants to know about. I just heard from Lynne Jolitz, Bill's wife. It seems he passed away about a month ago after a long illness. Most of you know he was the original force behind the BSD 386 development. I know little more than what I have just reported at this time, but will pass on any info as I learn it. Also in other news, not Unix related, but PDP-11 and the computer graphics world. We lost Jack Burness a few weeks ago. Jack was the author of the original "Moonlander" for the PDP-11 with which many of us wasted many hours trying to pick up "a Big Mac with fries" at "Mare Assabet." [Note: There was no WWW/Wikipedia in those days to find it, but to look up Assabet River, so many people naively thought it was a legitimate lunar landmark - its the River that the DEC Maynard bldg sits]. He was a larger than life person [his joke's mailing list was a whos-who of the computer industry - it was an honor to be on it]. We all have a passel of stories about Jack. I have written separately about Jack a number of times and if you have never looked at the source to Moonlander, you own it yourself to read it. Remember he wrote it as a throw-away demo for the GT-40 for trade show [his integer transcendental funcs are quite instructive]. As one of the folks on the Masscomp Alumni list put it, 'Jack was someone that just does not deserve to die.' This is the announcement Maureen published in the DEC Alumni list. ************************** January 20, 2022 ******************************** Our sincere condolences to Maureen Burness and all friends in CXO and elsewhere on the passing of her husband, *Jack Burness*, 75, Colorado Springs, who left us on January 20, 2022. Maureen said: With his bigger than life personality, humor, and intellect, he was loved and respected by so many people, including his devoted family. Born in Brooklyn, NY in 1946, he received his Engineering Degree from Brooklyn Polytechnic Institute and was employed by DEC, Maynard in the early days and then here in Colorado Springs. Many of you knew he had a huge appetite for the outdoors of Colorado and Martha’s Vineyard and joined him in his sometimes-disastrous adventures.

3 years, 1 month

11
16
0 0

Interesting commentary on Unix from Multicians.

by Dan Cross

I came across this talk that, apparently, was meant to be part of a documentary about timesharing systems at MIT: https://www.youtube.com/watch?v=KZPYBDA6XVo This "episode" features McCarthy, Corbato, Fano, Fredkin, and Philip Morse talking about Multics. Starting at ~12:15m they talk about the triumvirate of MIT, GE and Bell Labs and some of the challenges with distributed work. Around the 14 minute mark, they talk about Bell Labs exiting the project, and touch briefly on the development of Unix. Interesting quotes include Fano talking about different objectives from the different organizations, Corby saying, "they [Bell Labs] dropped out three-quarters of the way through the race" (referring to Multics), Fano asserting that BTL left after the _research_ part of the project was essentially completed, and Corbato talking about the influence of Multics on Unix design (Corby refers to Multics as Ken and Dennis's "prototype" and calls Unix a "second generation Multics"). This was all shot in the early 1980s. The rest is interesting, but mostly unrelated to Unix. - Dan C. (PS: As an aside, Fano lighting up a cigarette at about 19:20 was particularly striking: my, how times have changed.)

3 years, 1 month

10
15
0 0

Re: [TUHS] Why does shell write to stderr?

by Douglas McIlroy

How would you wish to interact with /bin/bash >file Doug

3 years, 1 month

6
8
0 0

Re: [TUHS] Interesting commentary on Unix from Multicians.

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Not to put too fine a point on it, It seems like it would be fair to > say Multics was 'complete' by the time Organick published his book This is a pretty ill-judged claim, IMO - but not for any particulars about the Organick book, etc. The problem is more global. When was UNIX 'complete' - when the first people were able to do real work on the PDP-7? When non-programmer clerks from the patent group were able to use the assembler UNIX on the PDP-11 to format parent documents? When it was re-written in C for the 4th Edition (since the _portability_ of UNIX was IMO perhaps the greatest factor in its eventual domination)? Etc, etc, etc. The exact same problem applies to the question of 'when was Multics 'complete''. > don't know when it first appeared and can not seem to find it. ... I > bet I have the 3rd printing. ... Anyone have a first edition around > with the publication date? The third printing _is_ the first edition. Anyway, it doesn't matter - see above. And of course even if the book _wriring_ was finished at time T, it wouldn't have been printed until some unknown time later. So that's really pretty useless as a temporal marker; we have much better ones availablw. > From: Dan Cross > I can't see any indication that this is anything other than the first > printing. My 3rd printing says 3rd was 1980, 2nd in 1976, and copyright 1972. > Organick's book is often said to describe an earlier version of the > system Yes; I'm not sure if the version described in it was ever available for general usege (which could be my definition of 'complete') - or even usage my Multics system programmers. I don't remember all the details of the differences (it's been way too long since I read it, and I don't know the details of the 'first operational' Multics well enough), but for instance: ISTR that it describes a version which had a linkage segment (holding intermediate locations in outbound links - since segment >a>b>c might well have different segment numbers assigned to it in the address spaces of processes X and Y, so one copy of >a>b>c, shared between X and Y, couldn't contain direct outbound links) _per segment_ (data or code) - but operational Multics (I don't know if this is from 'first available to users', or 'first available to Multics system programmers', or what) collapsed all the linkage info into a 'combined linkage segment', in which the linkage info from all the segments in a process' address space were combined (by copying) into a single linkage segment. Etc, etc, etc. > I understand that Multics got much better after the move to the 6180 I'm not sure that the 6180 made that big a difference to the environment the average use saw. My understanding (not having been there) was that the big _architectural_ difference was that cross-ring inter-segment references were done and monitored in hardware, so a host of security holes caused by insufficient checking of cross-ring inter-segment pointers were caught automatically. (The 6180 was also built out of SSI chips, unlike the 645 which was individual transistors, like a KA10.) Noel

3 years, 1 month

1
0
0 0

Re: [TUHS] Why does shell write to stderr?

by Paul Ruizendaal

> If you never ring the bell in the editor, the issue never comes up As natural language ambiguity was brought up: it makes the code less noisy :^)

3 years, 1 month

1
0
0 0

Why does shell write to stderr?

by Richard Salz

Looking at https://unix.stackexchange.com/questions/380012/why-does-bash-interactive-s…, in particular the first answer which has a link to http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/main%E2%80%8… Made me wonder: why?

3 years, 1 month

1
0
0 0

Long term software archive

by Jon Steinhart

So this is weird. My publisher contacted me this week asking for permission to send a copy of my book to these folks: https://archiveprogram.github.com/ Hadn't heard of them before. Looks like they're filling their archive with stuff from github which means that most of the stuff being preserved by TUHS is likely not there. Might be a good idea to see if it can be included. I have no contact with these folks but can probably get a contact from my publisher if this is something that y'all think is worth doing. Jon

3 years, 1 month

1
0
0 0

Re: [TUHS] A Reiser tour do force

by Paul Ruizendaal

> A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c > It appears to be a pre-Reiser bitblt, not what was asked for. The Reiser code is in the V8 jerq tarball that Dan Cross donated: v8jerq.tar.bz2 <https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar…> It is in file blit/src/libj/bitblt.s (attached below for convenience). It is 750 lines of 68K assembler. It does not appear to have been ported to the Bellmac 32 CPU. Maybe it did not make sense in that context. Paul ===== # # bitblt(sm,r,dm,p,fc) # Bitmap *sm,*dm; # Rectangle r; # Point p; # int fc; # # by John F. Reiser summer 1982 # # Depending on the case at hand, generate very good code and execute it. # # offsets in a Point set x,0 set y,2 # offsets in a Rectangle set origin,0 set corner,4 # offsets in a Bitmap set base,0 set width,4 set rect,6 # parameter offsets from %fp set sm,8 set r,12 set dm,20 set p,24 set fc,28 set NREG,11 global bitblt bitblt: movm.l &0x3f3e,-(%sp) # save C registers movm.l NREG*4-4+sm(%sp),&0x001f # d1=r.o.x,,r.o.y; d2=r.c.x,,r.c.y; d4=p.x,,p.y; mov.l %d0,%a4 # sm mov.l %d3,%a5 # dm mov.w NREG*4-4+fc(%sp),%a6 # a6.w == fc movm.l rect(%a4),&0x9 # d0=sm.o.x,,sm.o.y; d3=sm.c.x,,sm.c.y; movm.l rect(%a5),&0x60 # d5=dm.o.x,,dm.o.y; d6=dm.c.x,,dm.c.y; lea.l $L50(%pc),%a0 L5: # clip r.y to sm.y mov.w %d0,%d7 # sm.o.y sub.w %d1,%d7 # - r.o.y ble.b L10 mov.w %d0,%d1 # r.o.y = sm.o.y; /* r.o.y was above sm.rect */ add.w %d7,%d4 # p.y parallels r.o.y L10: cmp.w %d2,%d3 # r.c.y : sm.c.y ble.b L20 mov.w %d3,%d2 # r.c.y = sm.c.y; /* bottom of r was below sm.rect */ L20: # clip (r.y at p.y) to dm.y mov.w %d5,%d7 # dm.o.y sub.w %d4,%d7 # -p.y ble.b L30 mov.w %d5,%d4 # p.y = dm.o.y; /* p.y was above dm.rect */ add.w %d7,%d1 # r.o.y parallels p.y L30: mov.w %d1,%d7 # r.o.y add.w %d6,%d7 # + dm.c.y sub.w %d4,%d7 # - p.y /* == max y that dm.rect allows in r */ cmp.w %d2,%d7 # r.c.y : limit ble.b L40 mov.w %d7,%d2 # r.c.y = limit L40: mov.w %d2,%d7 # r.c.y sub.w %d1,%d7 # - r.o.y sub.w &1,%d7 # /* == h-1 in bits */ blt.b ret jmp (%a0) retgen: lea.l gensiz(%sp),%sp ret8: add.l &8,%sp ret: movm.l (%sp)+,&0x7cfc rts L50: # mirror in pi/4 and reuse same code to clip x swap.w %d0; swap.w %d1; swap.w %d2; swap.w %d3 swap.w %d4; swap.w %d5; swap.w %d6; swap.w %d7 lea.l $L55(%pc),%a0 br.b L5 L55: mov.l %d1,%a1 mov.l %d4,%d6 # # So far # %d7 == h-1,,w-1 # %d6 == p.y,,p.x # %a6.w == fc # %a5 == dm # %a4 == sm # %a1 == r.o.y,,r.o.x # # Compute masks, and width in words # mov.w %d6,%d0 # p.x /* left endpoint of dst */ mov.w %d7,%d1 # w-1 add.w %d6,%d1 # right endpoint mov.l &-1,%d3 mov.l &15,%d2 and.w %d0,%d2 lsr.w %d2,%d3 # mask1 mov.l &-1,%d5 mov.l &15,%d2 and.w %d1,%d2 add.w &1,%d2 lsr.w %d2,%d5 not.w %d5 # mask2 swap.w %d5 mov.w %d3,%d5 # mask2,,mask1 asr.w &4,%d0 asr.w &4,%d1 sub.w %d0,%d1 sub.w &1,%d1 # inner-loop width in words mov.l &0,%d4 # assume LtoR mov.w width(%a5),%d3 add.w %d3,%d3 mov.w width(%a4),%d2 add.w %d2,%d2 # # So far # %d7 == h-1,,w-1 in bits # %d6 == p.y,,p.x # %d5 == mask2,,mask1 # %d4 == 0 (LtoR) # %d3.w == dm width in bytes # %d2.w == sm width in bytes # %d1.w == inner-loop width in words # %a6.w == fc # %a5 == dm # %a4 == sm # %a1 == r.o.y,,r.o.x # # If necessary, compensate for overlap of source and destination # cmp.l %a4,%a5 bne.b L80 # overlap not possible mov.l %d6,%d0 # p.y,,p.x mov.w %a1,%d0 # p.y,,r.o.x cmp.l %a1,%d0 # r.o.y : p.y bge.b L60 # if (r.o.y < p.y) mov.l %d7,%d0 # h-1,,w-1 clr.w %d0 # h-1,,0 add.l %d0,%a1 # r.o.y += h-1; add.l %d0,%d6 # p.y += h-1; neg.w %d3 # wdst = -wdst; neg.w %d2 # wsrc = -wsrc; L60: cmp.w %d7,&16 blt.b L70 # l<->r swap not needed for narrow cmp.w %d6,%a1 # p.x : r.o.x ble.b L70 # if (r.o.x < p.x) mov.l %a1,%d0 add.w %d7,%d0 mov.l %d0,%a1 # r.o.x += w-1; add.w %d7,%d6 # p.x += w-1; mov.l &-1,%d4 # RtoL swap.w %d5 # masks in other order L70: L80: # # Locate actual starting points # mov.l %d6,%d0 # p.y,,p.x swap.w %d0 mov.l %d0,-(%sp) # p mov.l %a5,-(%sp) # dm mov.l &15,%d0 lea.l $L82(%pc),%a0 # assume narrow cmp.w %d7,%d0 # w-1 : 15 ble.b L81 # guessed correctly lea.l $L85(%pc),%a0 # wide L81: mov.l %a0,-(%sp) # on return, go directly to wide/narrow code add.w %a6,%a6; add.w %a6,%a6 # with 4*fc mov.w %d1,%d7 # h-1 in bits,,inner width in words and.l %d0,%d6 # 0,,bit offset of p.x mov.l %a1,%d1 # r.o.y,,r.o.x and.w %d1,%d0 # bit offset of r.o.x sub.w %d0,%d6 # BO(p.x) - BO(r.o.x) /* amount of right rotation */ swap.w %d1 # r.o.x,,r.o.y mov.l %d1,-(%sp) # r.o mov.l %a4,-(%sp) # sm lea.l addr,%a3 jsr (%a3) mov.l %a0,%a2 # src = addr(sm,r.origin); add.l &8,%sp jmp (%a3) # %a0 = addr(dm,p); L82: mov.l &0,%d4 mov.w %d5,%d4 # 0,,mask1 swap.w %d5 # mask1,,mask2 (proper long mask; maybe 16 bits too wide) and.w %d5,%d4 # check for overlap of mask1 and mask2 beq.b L83 # no overlap ==> %d5 already correct mov.l %d4,%d5 # overlap ==> reduce %d5 by 16 bits swap.w %d5 # and put it in the proper half L83: swap.w %d7 # ,,height-1 lea.l $nrwtab(%pc,%a6.w),%a6 # -> optab tst.w %d6 # amount of right rotation bge.b L84 neg.w %d6 add.l &2,%a6 L84: add.w (%a6),%a6 jmp (%a6) nrwtab: short opMnwr-nrwtab- 0, opMnwl-nrwtab- 2 short opSnwr-nrwtab- 4, opSnwl-nrwtab- 6 short opCnwr-nrwtab- 8, opCnwl-nrwtab-10 short opXnwr-nrwtab-12, opXnwl-nrwtab-14 opMnwr: mov.l (%a2),%d0 mov.l (%a0),%d1 ror.l %d6,%d0 eor.l %d1,%d0 and.l %d5,%d0 eor.l %d1,%d0 mov.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opMnwr br ret8 opMnwl: mov.l (%a2),%d0 mov.l (%a0),%d1 rol.l %d6,%d0 eor.l %d1,%d0 and.l %d5,%d0 eor.l %d1,%d0 mov.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opMnwl br ret8 opSnwr: mov.l (%a2),%d0 ror.l %d6,%d0 and.l %d5,%d0 or.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opSnwr br ret8 opSnwl: mov.l (%a2),%d0 rol.l %d6,%d0 and.l %d5,%d0 or.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opSnwl br ret8 opCnwr: mov.l (%a2),%d0 ror.l %d6,%d0 and.l %d5,%d0 not.l %d0 and.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opCnwr br ret8 opCnwl: mov.l (%a2),%d0 rol.l %d6,%d0 and.l %d5,%d0 not.l %d0 and.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opCnwl br ret8 opXnwr: mov.l (%a2),%d0 ror.l %d6,%d0 and.l %d5,%d0 eor.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opXnwr br ret8 opXnwl: mov.l (%a2),%d0 rol.l %d6,%d0 and.l %d5,%d0 eor.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opXnwl br ret8 set DBR,0x51c8 set MOVLI,0x2000+074 # mov.l &..., set MOVWI,0x3000+074 # mov.w &..., set ADDWI,0x0640 # add.w &..., set FDFRAG,16 # first destination is a fragment set LDFRAG,17 # last destination is a fragment set NSHF1,18 set FD2D,19 # first destination should store 2 words set LD2D,20 # last destination should store 2 words set FSTORE,21 set DST1L,24 # dst inner count is 0 set SRC1L,25 # Nsrc is 2 set gensiz,80 widtab: mov.w %d0,(%a0)+; short 0 or.w %d0,(%a0)+; short 0 and.w %d0,(%a0)+; not.w %d0 eor.w %d0,(%a0)+; short 0 # # So far # %d7 == h-1 (bits),,w (words) # %d6 == 0,,rotate count # %d5 == mask2,,mask1 # %d4 == -RtoL # %d3.w == wdst (bytes) # %d2.w == wsrc (bytes) # %a6.w == 4*fc # %a2 -> src # %a0 -> dst # L85: lea.l $widtab(%pc,%a6.w),%a6 tst.w %d4; bpl.b L300; bset &31,%d6 L300: mov.w %d7,%d0 # inner word count bne.b L304; bset &DST1L,%d6 L304: add.w &1,%d0 # Nsrc = 1+Ninner mov.w %d0,%a1 # + ... add.w &1,%d0 # Ndst = 1+Ninner+1 add.w %d0,%d0 # magnitude of dst addressing side effects tst.l %d6; bpl.b L310 neg.w %d0; add.l &2,%a0 # RtoL L310: sub.w %d0,%d3 # compensate dst for autoincrement mov.w %d5,%d4 # mask1 swap.w %d5 # mask2 cmp.w %d4,&-1; beq.b L320; bset &FDFRAG,%d6 L320: cmp.w %d5,&-1; seq.b %d1; beq.b L330; bset &LDFRAG,%d6 L330: tst.w %d6; bne.b L360 # not NOSHIFT add.w &1,%a1 # Nsrc = 1+Ninner+1 mov.l %d6,%d0; swap.w %d0; ext.w %d0 # 0,,flag bits asr.w &1,%d7; roxl.w &1,%d0 # account for inner words odd mov.b $nstab(%pc,%d0.w),%d0 bpl.b L340; add.w &1,%d7 L340: add.b %d0,%d0 bpl.b L350; sub.w &1,%d7 L350: swap.w %d0; eor.l %d0,%d6 # the bits btst &DST1L,%d6; bne.b L355 btst &FD2D,%d6; beq.b L410 L355: ext.l %d4; bmi.b L410; swap.w %d4; not.w %d4 # NOSHIFT mask1 .l br.b L410 # NOSHIFT mask2 .l nstab: byte 0x82,0x80,0x04,0x80 # 0x80: +1 inner; 0x40: -1 inner byte 0x02,0x00,0x44,0x00 # 0x04: FD2D; 0x02: NSHF1 no first word L360: ext.w %d1; sub.w %d1,%d7 # extend inner loop mov.l &0xf,%d0 # 0 1 7 8 9 e f add.w &8,%d6 # 8 9 f 0 1 6 7 and.w %d0,%d6 sub.w &8,%d6 # 0 1 7 -8 -7 -2 -1 X=C= sign mov.w %d6,%d1; bge.b L367 # X unchanged neg.w %d1 # 8 7 2 1 X=C= 1 L367: roxl.w &1,%d1 # 0 2 e 11 f 5 3 and.w %d0,%d1 # 0 2 e 1 f 5 3 lsl.w &8,%d1 # magic position short ADDWI+001 ror.l &8,%d0 mov.w %d1,%a3 # the rotate instruction mov.l &0,%d1; not.w %d1 # 0,,-1 ror.l %d6,%d1 # where the bits are after a rotate mov.w %d1,%d0; and.w %d4,%d0; beq.b L370 # 1 src word covers dst frag not.w %d1; and.w %d4,%d1; beq.b L370 add.w &1,%a1; br.b L390 # fragment needs another src word L370: sub.w &1,%d7 # .l takes an inner word bset &FD2D,%d6 ext.l %d4; bmi.b L390 swap.w %d4; not.w %d4 # mask1 .l L390: swap.w %d1 mov.w %d1,%d0; and.w %d5,%d0; beq.b L400 # 1 src word covers dst frag not.w %d1; and.w %d5,%d1; beq.b L400 add.w &1,%a1; br.b L420 # fragment needs another src word L400: dbr %d7,L405 # .l takes an inner word clr.w %d7; br.b L420 # nothing there to take L405: L410: bset &LD2D,%d6 ext.l %d5; bmi.b L420 swap.w %d5; not.w %d5 # mask2 .l L420: tst.w NREG*4-4+fc+8(%sp); bne.b L430; bset &FSTORE,%d6 L430: mov.w %a1,%d0 # Nsrc add.w %d0,%d0 # magnitude of src addressing side effects tst.l %d6; bpl.b L431 neg.w %d0; add.l &2,%a2 # RtoL L431: sub.w %d0,%d2 # compensate src for autoincrement lea.l -gensiz(%sp),%sp mov.l %sp,%a5 swap.w %d3 swap.w %d2 cmp.w %a1,&2; bgt L445 short MOVWI+00000 mov.l (%a2)+,%d0 tst.l %d6; bpl.b L432; add.w &010,%d0 # RtoL L432: mov.w %d0,(%a5)+ mov.l &0,%d1; mov.w &-0x1000,%d2; mov.w &0100,%d3 lea.l $L438(%pc),%a1 mov.l &-1,%d0 # prepare bits to decide on "swap" tst.w %d6; bpl.b L432d; neg.w %d6 lsl.l %d6,%d0; br.b L432e L432d: lsr.l %d6,%d0 L432e: btst &DST1L,%d6; beq.b L434 bset &FD2D,%d6; bne.b L432a ext.l %d4; bmi.b L432a; swap.w %d4; not.w %d4 # mask1 .l L432a: bset &LD2D,%d6; bne.b L432b ext.l %d5; bmi.b L432b; swap.w %d5; not.w %d5 # mask2 .l L432b: and.l %d5,%d4; mov.l %d4,%d5 # single .l does it all add.l &1,%d4; beq L730 # all 32 bits sub.l &1,%d4 # need an "and" and.l %d5,%d0 cmp.l %d5,%d0 beq.b L432c short MOVWI+05300 swap.w %d0 L432c: tst.w %d6; bne L690 # and a rotate br.b L437 # NOSHIFT L434: mov.w %a3,(%a5)+ # the rotate instr short MOVWI+05300 mov.l %d0,%d1 # copy after rotate and.l %d4,%d0 cmp.l %d4,%d0 seq.b %d0; neg.b %d0; ext.w %d0 short ADDWI+000 swap.w %d0 mov.w %d0,(%a5)+ lea.l $L436(%pc),%a1 br.b L437 L436: and.w %d4,%d0 mov.w &01001,%d1; clr.w %d2; clr.w %d3 lea.l $L438(%pc),%a1 L437: br L700 L438: and.w %d5,%d0 br L545 L445: # # During compilation # %d7 == h-1,,w # %d6 == flags,,rotate count # %d5 == mask2 # %d4 == mask1 # %d3 == dst_dW,,bits for xxx.[wl] # %d2 == src_dW,,bits for mov.[wl] # %d1.w == parity # %a6 -> optab # %a5 -> next generated instruction # %a4 -> top of inner loop # %a3.w == rotate instruction # %a2 -> src # %a1 -> fragment "and" instruction # %a0 -> dst # tst.w %d6; bne.b L480 # not NOSHIFT ==> always need first word btst &NSHF1,%d6; bne.b L485 # interplay of NOSHIFT, odd, FDFRAG L480: mov.l &1,%d1 and.w %d7,%d1 # parity of inner word count lsl.w &2,%d1 # even ==> frag in %d0, odd ==> frag in %d1 bsr genwid # generate for first word and.w %d4,%d0 L485: cmp.w %d7,&2; ble.b L490 # inner dbr always falls through btst &FSTORE,%d6; beq.b L490 # no conflict "mov field" vs. %d6 short MOVWI+05300 # init inner count mov.w %a4,%d6 L490: mov.l %a5,%a4 # top of inner loop asr.w &1,%d7 # check inner word count blt.b L540 # single .l does it all bcc.b L500 # even beq.b L520 # 1 short MOVWI+05300 br.b L500 # jump into middle of inner loop add.l &1,%a4 # remember to fixup "br.b" add.w &1,%d7 # middle entry ==> no dbr offset L500: beq.b L530 # no inner words at all mov.l &4,%d1 # use %d1 in bsr.b genwid # even half of inner loop short 0 L510: mov.w %a4,%d0; neg.w %d0 bclr &0,%d0; beq.b L520 add.w %a5,%d0; mov.b %d0,(%a4)+ # fixup "br.b" into middle L520: mov.l &0,%d1 # use %d0 in bsr.b genwid # odd half of inner loop short 0 sub.w &1,%d7 # offset for inner dbr loop ble.b L530 # dbr always falls through mov.w &DBR+6,(%a5)+ sub.l %a5,%a4; mov.w %a4,(%a5)+ # dbr displacement L530: btst &LDFRAG,%d6; beq.b L540 # omit "and" for full last word mov.l &4,%d1 bsr.b genwid and.w %d5,%d0 L540: tst.w %d7; ble.b L545 # no inner loop btst &FSTORE,%d6; bne.b L545 # possible conflict "mov field" vs. %d6 short MOVWI+05300 # init inner count mov.w %a4,%d6 L545: swap.w %d3; tst.w %d3; beq.b L546 # wdst is full width of bitmap mov.w %d3,%a1 # dst_dW short MOVWI+05300 add.w %a1,%a0 L546: swap.w %d2; tst.w %d2; beq.b L547 # wsrc is full width of bitmap mov.w %d2,%a3 # src_dW short MOVWI+05300 add.w %a3,%a2 L547: mov.w &DBR+7,(%a5)+ mov.l %sp,%a4 # top of outer loop cmp.b (%a4),&0x60; bne.b L548 # not br.b mov.b 1(%a4),%d0; ext.w %d0; lea.l 2(%a4,%d0.w),%a4 # collapse branches L548: sub.l %a5,%a4; mov.w %a4,(%a5)+ # dbr displacement short MOVWI+05300 jmp (%a5) mov.w %d7,%a4 # init inner count mov.w %d7,%d6 # init inner count, 2nd case swap.w %d7 # h-1 lea.l $retgen(%pc),%a5 jmp (%sp) genwid: mov.l (%sp)+,%a1 # -> inline parameter mov.l $genget(%pc,%d1.w),%d0 tst.w %d1; beq.b L550; mov.w &01001,%d1; swap.w %d1 # parity bits L550: clr.w %d2; clr.w %d3 # .[wl] bits default to .w tst.l %d6; bpl.b L560; add.w &010,%d0 # RtoL L560: tst.w %d6; bne.b L569 # not NOSHIFT bclr &9,%d0 # NOSHIFT always %d0 mov.w (%a1),%d1; bne.b L564 # not inner loop btst &FSTORE,%d6; beq.b L562 # not "mov" mov.l &070,%d1; and.w %d0,%d1 lsl.w &3,%d1; or.w %d1,%d0 # copy RtoL mode add.w &-0x1000,%d0 # .w ==> .l mov.w %d0,(%a5)+ L561: jmp 2(%a1) genget: swap.w %d0; mov.w (%a2)+,%d0 swap.w %d1; mov.w (%a2)+,%d1 L562: mov.w &-0x1000,%d2; mov.w &0100,%d3 # .w +=> .l add.w %d2,%d0 L563: mov.l &0,%d1 # NOSHIFT always %d0 br L698 # assemble the fetch, then do the op L564: lsr.w &1,%d1; bcs.b L562 # NOSHIFT always LD2D btst &FD2D,%d6; bne.b L562 br.b L563 # alas, .w L569: mov.w (%a1),%d1; beq.b L630 # inner loop L570: lsr.w &1,%d1; bcs.b L580 # last word add.w &-0x1000,%d0 # force fetch .l mov.w %d0,(%a5)+ # the fetch .l short MOVLI+00000 mov.l %d0,%d1 swap.w %d0 clr.w %d1; eor.l %d1,%d0 # parity for mov.l %d[01],%d[10] tst.l %d1; sne.b %d1; sub.b %d1,%d0 # parity for swap.w %d[01] mov.l %d0,(%a5) # ran out of registers mov.l &0x4c80ec,%d0 # microcoded bits tst.l %d6; bpl.b L572; ror.l &1,%d0 # RtoL L572: tst.w %d6; bpl.b L574; ror.l &2,%d0 # rol L574: btst &FD2D,%d6; beq.b L576; ror.l &4,%d0 # first op .l mov.w &-0x1000,%d2; mov.w &0100,%d3 # .w +=> .l corrections L576: ror.l &1,%d0; bpl.b L578 # "swap" not needed add.l &2,%a5 ror.l &8,%d0; bpl.b L577 # existing "swap" parity OK eor.w &1,(%a5) L577: ror.l &8,%d0; bpl.b L578 # existing order OK sub.l &2,%a5 mov.l (%a5),%d0; swap.w %d0; mov.l %d0,(%a5) add.l &2,%a5 L578: add.l &2,%a5 swap.w %d1 # junk,,parity br.b L690 L580: btst &LD2D,%d6; beq.b L630 # operator .w mov.w &-0x1000,%d2 # mov.w +=> mov.l mov.w &0100,%d3 # xxx.w +=> xxx.l L630: tst.l %d6; smi.b %d1 eor.b %d6,%d1; bpl.b L650 # rotation in same direction as scan swap.w %d0 # interchange "swap" and "mov" L650: mov.l %d0,(%a5)+ swap.w %d1 # junk,,parity mov.w (%a1),%d0; lsr.w &1,%d0; bcs.b L660 # last word short MOVWI+000 mov.l %d0,%d1 eor.w %d1,%d0 mov.w %d0,(%a5)+ br.b L690 L660: tst.l %d6; bmi.b L690 # RtoL btst &LD2D,%d6; beq.b L690 # not .l tst.w %d6; bpl.b L670 # ror sub.l &2,%a5; br.b L690 # no "swap" L670: mov.w -4(%a5),(%a5)+ # extra "swap" L690: mov.w %a3,%d0 eor.b %d1,%d0 L698: mov.w %d0,(%a5)+ # the rotate instruction L700: mov.w (%a1),%d0; beq.b L730 # inner loop btst &0,%d0; bne.b L705 # last word btst &FDFRAG,%d6; beq.b L730 # no "and" L705: add.w %d3,%d0; add.w %d1,%d0; sub.b %d1,%d0 # and.[wl] %d[45],%d[01] btst &FSTORE,%d6; beq.b L720 # "mov" partial word swap.w %d0 # save the "and" short MOVWI+00000 # ,%d0 mov.w (%a0),%d6 add.w %d2,%d0 # mov.[wl] tst.l %d6; bpl.b L710; add.w &020,%d0 # RtoL; "(%a0)" ==> "-(%a0)" L710: mov.w %d0,(%a5)+ # instr to fetch memory part of word short MOVWI+00000 # ,%d0 eor.w %d6,%d0 add.w %d3,%d0; add.b %d1,%d0 # eor.[wl] %d6,%d[01] swap.w %d0; mov.l %d0,(%a5)+; swap.w %d0; mov.w %d0,(%a5)+ mov.w %d2,%d0; add.b %d1,%d0 # mov.[wl] %d[01], mov.l &-0100,%d1 # RtoL correction, if necessary br.b L770 L720: mov.w %d0,(%a5)+ # "and" for non-mov operators L730: mov.w 2(%a6),%d0; beq.b L740 # not F_CLR add.w %d3,%d0; add.b %d1,%d0 # not.[wl] %d[01] mov.w %d0,(%a5)+ L740: btst &FSTORE,%d6; beq.b L790 # non-"mov" mov.w %d2,%d0; add.b %d1,%d0 # mov.[wl] %d[01], mov.l &0100,%d1 # RtoL correction, if necessary L770: add.w (%a6),%d0 tst.l %d6; bpl.b L780 add.w %d1,%d0 # RtoL correction L780: mov.w %d0,(%a5)+ jmp 2(%a1) L790: mov.w %d1,%d0; clr.b %d0; add.w %d3,%d0 # xxx.[wl] %d[01] mov.l &010,%d1 # RtoL correction, if necessary br.b L770 # # During execution # %d[01] == rotator # %d2 [reserved for texture bits] # %d3 [reserved for texture index] # %d4 == mask1 # %d5 == mask2 # %d6.w == inner count # %d7.w == outer count # %a0 -> dst # %a1 == dst_dW # %a2 -> src # %a3 == src_dW # %a4.w == inner count init # %a5 -> retgen # %a6 [reserved for -> texture] #

3 years, 1 month

2
1
0 0

Re: [TUHS] A Reiser tour de force

by Paul Ruizendaal

>> A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c >> It appears to be a pre-Reiser bitblt, not what was asked for. > > > The Reiser code is in the V8 jerq tarball that Dan Cross donated: > v8jerq.tar.bz2 <https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar…> > > It is in file blit/src/libj/bitblt.s (attached below for convenience). It is 750 lines of 68K assembler. It does not appear to have been ported to the Bellmac 32 CPU. Maybe it did not make sense in that context. > > Paul There also is a file “bitblt.C” in that same directory (dated May 82, versus Aug 82 for the assembler file) that seems to have a similar approach coded up in C, with a big switch where each case has a lot of “asm()” statements. It is about 400 lines long. No author is mentioned. I have not investigated deeply, but at first glance it is possible that the approach was first coded up as a kind of threaded code in C (with inline asm) and later that Summer redone as fully hand coded assembler. Just a guess. Paul ==== #include <jerq.h> #define LEFTDIR 8 #define NOSHIFT 4 #define DAMMIT 4 /* you'll see why */ #undef sw bitblt(sm,r,dm,p,fc) Bitmap *sm,*dm; Rectangle r; Point p; int fc; { register Word *source,*dest,*_source,*_dest; /* %a2-%a5 */ register UWord m,mask1,mask2; /* %d2,%d3,%d4 */ register int a,b,i; /* %d5,%d6,%d7 */ int j,h,w,dx1,sw,dw; /* clip to the destination Bitmap only */ #define rp dest #define pp source rp = (int *) &(dm->rect); pp = (int *) &p; if ((a = *rp++ - *pp++) > 0) { *(pp-1) += a; r.origin.x += a; } if ((a = *rp++ - *pp) > 0) { *pp += a; r.origin.y += a; } if ((a = r.origin.x + *rp++ - *(pp-1)) < r.corner.x) r.corner.x = a; if ((a = r.origin.y + *rp - *pp) < r.corner.y) r.corner.y = a; i = r.corner.y - r.origin.y; /* going to be h */ a = r.corner.x - r.origin.x - 1; /* going to be dx1 */ if (i <= 0 || a < 0) return; if (a < 16) goto narrow; h = i; dx1 = a; /* i and b are regs, avoid work! */ sw = sm->width << 1; /* sleazy hack to avoid shift */ dw = dm->width << 1; /* in outer, inner loops */ w = ((p.x+dx1) >> 4) - (p.x >> 4) - 1; /* inner loop */ mask1 = ~topbits[p.x & 15]; mask2 = topbits[((p.x+dx1) & 15) + 1]; if (sm == dm) { /* may have to mess with loop order */ if (r.origin.y < p.y) { /* swap top with bottom */ r.origin.y += h-1; p.y += h-1; sw = -sw; dw = -dw; } if (r.origin.x < p.x) { /* swap left with right */ fc |= LEFTDIR; r.origin.x += dx1; p.x += dx1; } } _dest = addr(dm,p); _source = addr(sm,r.origin); a = (p.x&15) - (r.origin.x&15); if (a < 0) a += 16; else /* a == 0 means no shift, remember that */ _source--; /* else grab long and shift right */ b = 16 - a; if (a == 0) fc |= NOSHIFT; source = _source; dest = _dest; switch (fc) { case F_STORE | NOSHIFT: b = w; _source++; source = _source; a = h; /* a is free => use it */ do { *dest++ = (~mask1 & *dest) | (mask1 & *source++); if ((i = b>>2) > 0) do { *((long *)dest)++ = *((long *)source)++; *((long *)dest)++ = *((long *)source)++; } while (--i > 0); if ((i = b&3) > 0) do { *dest++ = *source++; } while (--i > 0); *dest = (~mask2 & *dest) | (mask2 & *source); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--a > 0); break; case F_STORE: do { asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); asm(" ror.l %d5,%d2 # rotate m right by a"); *dest++ = (~mask1 & *dest) | (mask1 & m); asm(" ror.l %d6,%d2 # rotate m right by b"); if ((i = w) > 0) do { m = *source++; asm(" ror.l %d5,%d2 # m >> a"); *dest++ = m; asm(" ror.l %d6,%d2 # m >> b"); } while (--i > 0); m = *source; asm(" ror.l %d5,%d2 # m >> a"); *dest = (~mask2 & *dest) | (mask2 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_STORE | NOSHIFT | LEFTDIR: b = w; _source++; source = _source; a = h; do { *dest = (~mask2 & *dest) | (mask2 & *source); if ((i = b>>2) > 0) do { *--((long *)dest) = *--((long *)source); *--((long *)dest) = *--((long *)source); } while (--i > 0); if ((i = b&3) > 0) do { *(--dest) = *(--source); } while (--i > 0); dest--; *dest = (~mask1 & *dest) | (mask1 & *(--source)); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--a > 0); break; case F_STORE | LEFTDIR: do { asm(" mov.l (%a2),%d2 # (long) m = *source"); asm(" ror.l %d5,%d2 # m >> a"); *dest = (~mask2 & *dest) | (mask2 & m); asm(" rol.l %d5,%d2 # m << a"); if ((i = w) > 0) do { m = *(--source); asm(" rol.l %d6,%d2 # m << b"); *(--dest) = m; asm(" rol.l %d5,%d2 # m << a"); } while (--i > 0); m = *(--source); asm(" rol.l %d6,%d2 # m << b"); dest--; *dest = (~mask1 & *dest) | (mask1 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_OR: case F_OR | NOSHIFT: do { asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); asm(" ror.l %d5,%d2 # rotate m right by a"); *dest++ |= (mask1 & m); asm(" ror.l %d6,%d2 # rotate m right by b"); if ((i = w) > 0) do { m = *source++; asm(" ror.l %d5,%d2 # m >> a"); *dest++ |= m; asm(" ror.l %d6,%d2 # m >> b"); } while (--i > 0); m = *source; asm(" ror.l %d5,%d2 # m >> a"); *dest |= (mask2 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_OR | LEFTDIR: case F_OR | NOSHIFT | LEFTDIR: do { asm(" mov.l (%a2),%d2 # (long) m = *source"); asm(" ror.l %d5,%d2 # m >> a"); *dest |= (mask2 & m); asm(" rol.l %d5,%d2 # m << a"); if ((i = w) > 0) do { m = *(--source); asm(" rol.l %d6,%d2 # m << b"); *(--dest) |= m; asm(" rol.l %d5,%d2 # m << a"); } while (--i > 0); m = *(--source); asm(" rol.l %d6,%d2 # m << b"); dest--; *dest |= (mask1 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_CLR: case F_CLR | NOSHIFT: do { asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); asm(" ror.l %d5,%d2 # rotate m right by a"); *dest++ &= ~(mask1 & m); asm(" ror.l %d6,%d2 # rotate m right by b"); if ((i = w) > 0) do { m = *source++; asm(" ror.l %d5,%d2 # m >> a"); asm(" not.w %d2 # m = ~m"); *dest++ &= m; asm(" ror.l %d6,%d2 # m >> b"); } while (--i > 0); m = *source; asm(" ror.l %d5,%d2 # m >> a"); *dest &= ~(mask2 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_CLR | LEFTDIR: case F_CLR | NOSHIFT | LEFTDIR: do { asm(" mov.l (%a2),%d2 # (long) m = *source"); asm(" ror.l %d5,%d2 # m >> a"); *dest &= ~(mask2 & m); asm(" rol.l %d5,%d2 # m << a"); if ((i = w) > 0) do { m = *(--source); asm(" rol.l %d6,%d2 # m << b"); asm(" not.w %d2 # m = ~m"); *(--dest) &= m; asm(" rol.l %d5,%d2 # m << a"); } while (--i > 0); m = *(--source); asm(" rol.l %d6,%d2 # m << b"); dest--; *dest &= ~(mask1 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_XOR | NOSHIFT: b = w; _source++; source = _source; a = h; do { *dest++ ^= (mask1 & *source++); if ((i = b>>2) > 0) do { *((long *)dest)++ ^= *((long *)source)++; *((long *)dest)++ ^= *((long *)source)++; } while (--i > 0); if ((i = b&3) > 0) do { *dest++ ^= *source++; } while (--i > 0); *dest ^= (mask2 & *source); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--a > 0); break; case F_XOR: default: do { asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); asm(" ror.l %d5,%d2 # rotate m right by a"); *dest++ ^= (mask1 & m); asm(" ror.l %d6,%d2 # rotate m right by b"); if ((i = w) > 0) do { m = *source++; asm(" ror.l %d5,%d2 # m >> a"); *dest++ ^= m; asm(" ror.l %d6,%d2 # m >> b"); } while (--i > 0); m = *source; asm(" ror.l %d5,%d2 # m >> a"); *dest ^= (mask2 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_XOR | NOSHIFT | LEFTDIR: b = w; _source++; source = _source; a = h; do { *dest ^= (mask2 & *source); if ((i = b>>2) > 0) do { *--((long *)dest) ^= *--((long *)source); *--((long *)dest) ^= *--((long *)source); } while (--i > 0); if ((i = b&3) > 0) do { *(--dest) ^= *(--source); } while (--i > 0); dest--; *dest ^= (mask1 & *(--source)); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--a > 0); break; case F_XOR | LEFTDIR: do { asm(" mov.l (%a2),%d2 # (long) m = *source"); asm(" ror.l %d5,%d2 # m >> a"); *dest ^= (mask2 & m); asm(" rol.l %d5,%d2 # m << a"); if ((i = w) > 0) do { m = *(--source); asm(" rol.l %d6,%d2 # m << b"); *(--dest) ^= m; asm(" rol.l %d5,%d2 # m << a"); } while (--i > 0); m = *(--source); asm(" rol.l %d6,%d2 # m << b"); dest--; *dest ^= (mask1 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; } return; narrow: /* * width is 16 bits or less, so we can do it by reading and * writing 32 bits at a time */ _source = (Word *) sm; _dest = (Word *) dm; mask1 = ((Bitmap *) _source)->width; /* source increment */ mask1 <<= 1; /* hack to add to an address register */ mask2 = ((Bitmap *) _dest)->width; /* dest increment */ mask2 <<= 1; if (_source == _dest && r.origin.y < p.y) { /* swap top with bottom */ r.origin.y += i-1; p.y += i-1; mask1 = -mask1; mask2 = -mask2; } asm(" mov &0,%d6 # (long) b = 0"); b = topbits[a+1]; a = (16 - (p.x & 15)); /* hocus pocus to get long mask */ asm(" rol.l %d5,%d6 # (long) b <<= a"); a = 16 - a - (r.origin.x & 15); /* shift constant */ if (a < 0) { /* guess what! -1 == 63 to the 68000!!! */ fc |= DAMMIT; /* not fatal, just slow */ } source = addr(_source,r.origin); dest = addr(_dest,p); switch (fc) { case F_STORE: case F_STORE | DAMMIT: asm(" mov.l %d6,%d1 # prepare inverse mask"); asm(" not.l %d1 "); do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" ror.l %d5,%d2 # rotate m right by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" mov.l (%a3),%d0 # m |= *dest&~b"); asm(" and.l %d1,%d0 "); asm(" or.l %d0,%d2 "); asm(" mov.l %d2,(%a3) # *dest = m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; case F_OR: case F_OR | DAMMIT: do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" ror.l %d5,%d2 # rotate m right by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" or.l %d2,(%a3) # *dest |= m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; case F_CLR: case F_CLR | DAMMIT: do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" ror.l %d5,%d2 # rotate m right by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" not.l %d2 # m = ^m"); asm(" and.l %d2,(%a3) # *dest &= m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; case F_XOR: do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" ror.l %d5,%d2 # rotate m right by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" eor.l %d2,(%a3) # *dest ^= m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; case F_XOR | DAMMIT: a = -a; do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" rol.l %d5,%d2 # rotate m left by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" eor.l %d2,(%a3) # *dest ^= m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; } return; }

3 years, 1 month

2
1
0 0

Re: [TUHS] A Reiser tour do force

by Douglas McIlroy

> Does {Reiser's bitblt replacement] exist for the rest of us to study? A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c It appears to be a pre-Reiser bitblt, not what was asked for. But weighing in at over 800 lines of C, it vivifies the challenge that Reiser met in half the space. Doug

3 years, 1 month

1
0
0 0

LSI-11

by Jon Steinhart

Someone on another list is getting rid of one of these. Lemme know if you want it and I'll put you in touch.

3 years, 1 month

1
0
0 0

A Reiser tour de force

by Douglas McIlroy

The recent discussion about Research choosing BSD's paging over Reiser-London's brought to mind a stunning program by Reiser that Research did adopt. A critical primitive in the Blit terminal was bitblt (block transfer of a rectangular area). It was used ubiquitously, for example to refresh data when window-stacking changed, to move data within a window, or to pop up a menu.. The display memory was word-oriented, so bitblt was fraught with niggling details about bit alignment and overlap of source and destination. A general bitblt subroutine was a rats' nest of conditionals--grossly inefficient for important special cases like scrolling. Bitblt got refined (i.e. elaborated) several times before Reiser did away with it entirely. Instead he wrote a just-in-time generator of optimal code. Thousands of distinct variants, which varied in size from 16 to 72 bytes, could be produced by the same 400 lines of assembler code. Doug

3 years, 1 month

5
6
0 0

Alive?

by Warren Toomey

Just checking that the TUHS list hasn't gone belly up, as it's been pretty quiet for a week :-) Cheers, Warren

3 years, 1 month

20
31
0 0

Re: [TUHS] Old screen editors

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Ward had a nice history here: TecoEditor > <http://c2.com/wiki/remodel/?TecoEditor> - worth reading Yeah, pretty good. A couple of minor points: "TECO Madness -- a moment of convenience, a lifetime of regret" - I have seen this attributed to Dave Moon. "the [ITS] version of TECO was used by Richard Stallman to implement the original Emacs Editor" - accurate if read _just_ the right way, but incorrect in the 'naive' reading. Stallman didn't _originate_ the body of stuff that eventually turned into ITS EMACS, although he did take over maintenance of it once it was rolling; and later wrote Gnu Emacs from scratch himself. The mostly accurate one-line history is the one given in Dan Weinreb's blog "the original (TECO-based) Emacs was created and designed by Guy L. Steele Jr. and David Moon. After they had it working, and it had become established as the standard text editor at the AI lab, Stallman took over its maintenance", to which Moon added "in all fairness I have to say that Stallman greatly improved Emacs after he 'liberated' it from Guy and me". More people were involved than Moon, Steele and Stallman, though; a lot of people were writing stuff before Stallman took over; and even after that, others (like Eugene Ciccarelli, a member of the CSR group) helped a lot with ITS EMACS. Stallman's EMACS paper ("sEMACS: The Extensible, Customizable, Self-Documenting Display Editor") contains _many_ statements that are _demonstrably_ wrong, e.g. "it is simply impossible to implement an extensible system in [languages like PASCAL or C]" ... "This eliminates most popular programming languages except LISP, APL and SNOBOL." Given that I've been using a heavily customized Epsilon for decades, which is written completely in EEL (a dialect of C enhanced with editing primitives like buffers, etc), that's clerly very confused. Noel

3 years, 1 month

5
4
0 0

Re: [TUHS] Old screen editors

by jnc＠mercury.lcs.mit.edu

> From: George Michaelson > Teco was painful. Some of us can recall when the _only_ choices for editing on UNIX (on the PWB1 systems at MIT) were 'ed' and TECO! But to add some real history (not just the usual low S/N flaming about people's opinions of various relatively recent software, which is way too common on this list), the guys at MIT in DSSR/RTS (the group which later did the 68K version of PCC), who had done the port of PDP-11 TECO (in MACRO-11) from the Delphi system at MIT (which preceded adoption of UNIX there) - a comment in one source file alludes to Delphi, so that's where it came from, to UNIX (I think this TECO was written there, and was not a port of a DEC one, since it's all in lower case, and doesn't have other DEC stylisms), after the port, added a '^R mode' similar to the one added to the PDP-10 ITS TECO and used there to write EMACS (in TECO's usual 'line noise' code - historical aside: at one point there was a whole 'Ivory' package for ITS TECO which could 'purify' ITS TECO code so that one copy in core [actual, real core!] could be shared by multiple processes). That was used to write an EMACS-like package for the PDP-11 UNIX TECO (but much simpler than real EMACS), which we used for quite a while before Montgomery EMACS for UNIX showed up. The full dump of the MIT-CSR PWB1 UNIX system which I retrieved has all the sources and documentation for that TECO, and the ^R-mode code, etc. If anyone is interested in seeing it (or maybe even playing with it, which will need the UNIX MACRO-11), let me know, and I'll upload it. Noel PS: Speaking of the full dump of the MIT-CSR PWB1 UNIX system, I was poking around it a couple of days ago, and I found V6 'multiplexor' kernel drivers - mpio.c and mpx.c, etc - I think thay 'fell off the back of a truck' at Bell, like a lot of other stuff we weren't supposed to have, like the circuit design tools, etc. I'm not sure if I have the user programs to go with them; I think I may have found some of them for Paul Ruizendaal a while back, but the memory has faded. Again, if interested, let me know.

3 years, 1 month

5
4
0 0

Re: [TUHS] Old screen editors

by Steve Simon

I never really used it but i do remember an editor called le on the v7 interdata/Perkin Elmer i used at Leeds poly. I read electronics and we all used vi, the computer science people at a different campus used le on their Interdata; no idea why. anyone any background on le? ihave not seen sight nor sound of it since. -Steve

3 years, 1 month

3
2
0 0

NetBSD VMs from 1.0 to present

by Chris Pinnock

Evening all, Seeing as our leader is worried about aliveness, I felt it fitting to send a link to a part-time project I’m working on. A couple of weeks ago, I fired up Virtualbox and installed NetBSD/i386 1.0 from floppy images. Virtualbox can be persuaded to read 1.2MB floppies - I’ve had less luck on Qemu with this. But after I setup the VM, I quickly converted it to one that Qemu could use. Then I loaded all the source floppies for 1.1 and 1.2 onto the VM, then upgraded the VM to 1.1 then 1.2 by compiling from source. By which time the pcnet network interface worked reliably. NetBSD still provides a pserver CVS method, so I was able then to CVS update, upgrade to 1.3.3 onwards. 1.4.3 -> 1.5.4 involves a change of binary format from a.out -> ELF. From 1.6 onwards, life becaomes simpler because of the build.sh system, but I spent the time to go all the way up to 9.2 via sources between each release. (I managed to build 9.2 from 6.1 as well.) The VMs can be found on this landing page: https://chrispinnock.com/stuff/netbsd/ I’m working on a write-up which I will publish at some point and I’m also working on OpenBSD branching off at NetBSD 1.1 - I’ve build a OpenBSD 2.0 VM from the NetBSD 1.1 VM on the page above. amnesiac# ls -l /ne* -rwxr-xr-x 1 root wheel 19089180 Mar 26 02:47 /netbsd -rwxr-xr-x 1 root wheel 659600 Mar 13 22:09 /netbsd.10 -rwxr-xr-x 1 root wheel 1332275 Mar 13 22:09 /netbsd.11 -rwxr-xr-x 1 root wheel 1477949 Mar 13 16:13 /netbsd.12 -rwxr-xr-x 1 root wheel 1530049 Mar 13 17:47 /netbsd.121 -rwxr-xr-x 1 root wheel 2211878 Mar 14 02:23 /netbsd.133 -rwxr-xr-x 1 root wheel 3407541 Mar 14 05:12 /netbsd.143 -rwxr-xr-x 1 root wheel 4941157 Mar 14 05:50 /netbsd.154.aout -rwxr-xr-x 1 root wheel 5048054 Mar 14 09:20 /netbsd.154.elf -rwxr-xr-x 1 root wheel 6182687 Mar 14 11:53 /netbsd.162 -rwxr-xr-x 1 root wheel 7447216 Mar 14 14:35 /netbsd.203 -rwxr-xr-x 1 root wheel 7476202 Mar 15 01:12 /netbsd.21 -rwxr-xr-x 1 root wheel 8577892 Mar 15 11:50 /netbsd.31 -rwxr-xr-x 1 root wheel 10343742 Mar 15 23:47 /netbsd.4 -rwxr-xr-x 1 root wheel 12002769 Mar 16 05:31 /netbsd.52 -rwxr-xr-x 1 root wheel 13116694 Mar 16 14:53 /netbsd.61 -rwxr-xr-x 1 root wheel 17143555 Mar 17 04:50 /netbsd.72 -rwxr-xr-x 1 root wheel 19695304 Mar 20 09:12 /netbsd.82 -rwxr-xr-x 1 root wheel 19089180 Mar 28 10:46 /netbsd.92 All the best Chris

3 years, 1 month

1
0
0 0

Re: [TUHS] Old screen editors

by jnc＠mercury.lcs.mit.edu

> From: Angelo Papenhoff > By 'upload it' do you mean the full dump or TECO only? At this point in time, not the full dump (below for why). I have previously uploaded lots of other bits, e.g. (looks quickly): the TCP/IP that was written for it (with the TCP in the 'user process', making for a small system, good for -11/23's and -11/40's); Montgomery EMACS; TECO (already done - along with the MACRO-11, but I still need to do the linker, and the BCPL compiler one needs for the linker). > That system sounds very interesting and I'd love to see the whole thing. Unfortunately, the dump includes _everything_ on the system, including personal email, etc, etc. So I have to curate it anything I upload. I suppose I should put together an 'index page', which lists (and links to) everything that has been uploaded? Noel

3 years, 1 month

1
0
0 0

Re.: Alive?

by Paul Ruizendaal

> Just checking that the TUHS list hasn't gone belly up, as it's been pretty > quiet for a week :-) > > Cheers, Warren Not relevant to a sudden dip, but overall my observation is that retro computing interest tends to focus on a period 30-40 years ago. For example, in the late 80’s people were going retro on the LGP-30, the story of Mel, etc. Probably this matches with people retracing their formative years in the industry when they retire. If correct, we should see a rise in interest around early Linux in the upcoming years, with interest in 80’s Unix and early networking declining. We’re probably already past peak for interest in 1970’s Unix. The historical log of this mailing list is important. Documenting historical events will get much harder after the "40 year window" has closed. Paul

3 years, 1 month

2
1
0 0

Paging code in SysV R2

by Paul Ruizendaal

I did not have a lot of time to work on documenting the evolution of paging / virtual memory code in 32V, Sys III and early SysV in the past months, but I did get some more background information that seems worth sharing. My understanding of the virtual memory story at USG is now as follows: Somewhere in 1981/82 a project plan for Unix 5 / System V was made and evolving John Reiser’s virtual memory code for 32V-r3 was part of that plan. “Evolving” in this context meant making it more maintainable and more hardware independent. John’s code assumed a memory page, a disk block and a file block all to be the same size, and it needed to be more general. It was also designed around the VAX MMU and this too needed to be generalised. The person assigned to that job was Bob (Robert) Baron, reporting to Tom Raleigh. The project involved quite a bit of re-architecting and progress was slowish. On top of that Bob left for CMU to work on Mach. Tom Raleigh tried to pick up where Bob had left off, but progress remained slowish. In parallel, Keith Kelleman and Steve Burroff were working on Unix for the 3B20 Unix. They did paging code from scratch around the 3B20 MMU (which used a more or less ‘modern’ page table design) and developed their idea for the “regions” abstraction to support large, non-contiguous address spaces. It seems that they built on the main working set ideas/concepts in the Reiser/Baron/Raleigh code base, combined these with their “regions” idea, made it multi-processor capable and made it all work on the 3B20. Around that time Tom Raleigh seems to have transferred to Bellcore, and the VAX code base got orphaned. Two young engineers appear to have picked up the work on the VAX code base: Dean Jagels and Jim McCormick. My understanding is that they essentially back ported the 3B20 work to the VAX, falling back on the Reiser/Baron/Raleigh work where necessary. They got it working, and as far as I can tell, this is what got released in 1984 as part of SysV R2.4 for the VAX (the oldest surviving source code for this that I could find). This somewhat tortuous birth may in part explain why Research chose to use the 4BSD virtual memory code for 8th edition.

3 years, 1 month

5
5
0 0

Re: [TUHS] Alive?

by jnc＠mercury.lcs.mit.edu

> From: Bakul Shah > My impression is that there is much less traffic on pretty much all the > mailing lists I am on and I am wondering why. Ukraine? That's certainly been absorbing a lot of my attention (but it seems like it's going to go on for quite a while now). Noel

3 years, 1 month

1
0
0 0

Re: [TUHS] Alive?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > Just checking that the TUHS list hasn't gone belly up, as it's been > pretty quiet for a week :-) Thank goodness! That's one way to improve the S/N ratio. Noel

3 years, 1 month

1
0
0 0

Re: [TUHS] [tuhs] PDP-11 and early Unix

by jnc＠mercury.lcs.mit.edu

Oops: > Instructions had a 4-bit opcode ('000'-'054') '060' was JMP. > ('060'opcodes were for the optional EAE.) '064'. Noel

3 years, 2 months

1
0
0 0

Re: [TUHS] [tuhs] PDP-11 and early Unix

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > I'm thrilled to see the 11 kept alive. Ditto. The most elegant archtecture ever, IMO. > I was under the impression ??Ken?? had created them for B > independently (which, of course, was first on the PDP-7). "The Development of the C Language", by Dennis M. Ritchie: https://www.bell-labs.com/usr/dmr/www/chist.html says: The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1. Note the "probably"; unless Ken remembers, and says something, that's probably the best we are going to get. > I did not think the PDP-7 ISA includes addressing modes in the same > manner as the 11. .. I thought PDP-7 is a very simple instruction (and > small) with an AC, Link/Indirection and a PC - it reminded me of the > PDP-8 more than anything else The PDP-4, -7 and -9 are all the same architecture (very similar to the PDP-1, but simplified a bit), differing only in implementation. (Most PDP-7 code will run on a -9, un-modified.) Basic instructions look like: Instructions had a 4-bit opcode ('000'-'054'), 1 bit of indirect, and 13 bits of address. It was a load-store architecture, with a single accumulator. So, yes, similar to an -8. There are other opcodes for non-memory operations ('074' opcode), and I/O ('070'), using bits in the 'address' field. ('060' opcodes were for the optional EAE.) All of the -4/-7/-9 had the 'auto-increment on locations 010-017' when indirecting through them' feature. Bitsavers has fairly complete docs on them all: http://www.bitsavers.org/pdf/dec/pdp4/ http://www.bitsavers.org/pdf/dec/pdp7/ http://www.bitsavers.org/pdf/dec/pdp9/ Noel

3 years, 2 months

1
0
0 0

Re: [TUHS] [tuhs] PDP-11 and early Unix

by jnc＠mercury.lcs.mit.edu

> From: "Nelson H. F. Beebe" > there is a nice compact history of the PDP-11 and early Unix at this > new article: Not a bad artcle, but it had a number of minor errors, which I found irritating. They should have gotten an expert to proof it. Here are some: registers could access any other register - as well as memory or direct data - using one of the six different addressing modes I think 'instruction' may have been meant for the first "register"; as written it makes on sense. (Unlike the PDP-10, in the PDP-11, a register can't address another register.) Oh, and there are eight addressing modes. use of labels instead of hard-coded addresses makes it easier to program and makes the code relocatable in memory I'm not sure whether the writer knows the difference between 'PC-relative addressing' (a PDP-11 feature; code that will run at any address, without _any_ changes to the binary) and 'relocatable binary (which uses labels, as he describes). - but is not PDP-11 specific. The program counter can be accessed like any of the other registers ... The program counter is intended to support jump, branching, and other control flow instructions. Uh, no. It's not clear _exactly_ what was meant here, but... having the PC as a general register is for PC-relative addressing of operands, immediate data, and absolute addressing of operands. Jumps, branches, etc don't use the fact that the PC is a general register. These are the key advantages of assembly programming over high-level languages - assembler code always runs faster and uses less memory. Not really, with modern compilers. The number above represents -2. A commenter caught this one. Just use a $ to represent a decimal number In UNIX assembler, "$" means 'immediate data'; a trailing "." means decimal. And a tip of the hatly hat for getting this: Although the ++ and - operators in C are equivalents of DEC and INC instructions, they were inspired by an addressing mode in the PDP-7. right. Noel

3 years, 2 months

3
2
0 0

[tuhs] PDP-11 and early Unix

by Nelson H. F. Beebe

Although the story is well known to members of this list, there is a nice compact history of the PDP-11 and early Unix at this new article: A brief tour of the PDP-11, the most influential minicomputer of all time https://arstechnica.com/gadgets/2022/03/a-brief-tour-of-the-pdp-11-the-most… It describes PDP-11 assembly language, and shows the booting of a Unix system on a simh instance. It also includes the famous picture of Dennis and Ken at a PDP-11 console, and concludes with a link to an online text of a book about PDP-11 assembly language programming. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

3 years, 2 months

3
2
0 0

Documenter's Workbench versions

by Kevin Bowling

I am reading some UNIX text processing books and am interested in the lineage of Documenter's Workbench. I see documentation of 1.0 (i.e https://archive.org/details/sysv-dwb/page/n5/mode/2up) I see a copy of 2.0 for 3B2 (i.e. https://archives.loomcom.com/3b2/software/Documenters_Workbench/) >From there things get a little less clear, it seems like we jump to 3.2 with SysVR3.2? Then there is a 3.3 version https://github.com/n-t-roff/DWB3.3 One of my books from the late 80s references 3.4 available as a source code purchase independent of UNIX. Then it appears SGI might have had a 4.x strain? (i.e. https://archive.org/details/sgi_Documenters_Workbench_4.1.3) Heirloom is derived from OpenSolaris which is derived from? Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what (I extracted the image, the relnotes inside might as well not exist). Regards, Kevin

3 years, 2 months

7
11
0 0

Re: [TUHS] [PiDP-11] Fun with Fortran on the PiDP-11

by Adam Thornton

> On Mar 12, 2022, at 2:02 PM, Rob Pike <r(a)golang.org> wrote: > > Indeed. Be careful about the code Numerical Recipes if you are doing > important numerical work. > For simple stuff it's fine, of course, but floating point is a > minefield that requires expert navigation. > > -rob That's the seductive trap of floating-point numbers, isn't it? They invite us to think about them as if they were the real numbers, but they are very, very much *not* the real numbers. And yet, most of the time, for most applications, if you treat them as if they were, you get plausible results. Adam

3 years, 2 months

1
0
0 0

pcc struct return quirk

by Alexander Monakov

Hello, I'm trying to understand a quirk in 32-bit x86 code generation conventions: on Linux, when returning a structure from a function by value: struct S { int i, j; }; struct S f(int x) { return (struct S){x, sizeof(void*)}; } the caller reserves space for the returned structure and passes a pointer to that space as an 'invisible' extra argument, which is prepended to the argument list; the callee returns this pointer (although the caller knows it anyway); it's as if the function is transformed to struct S *f(struct S *ret, int x) { ret->i = x; ret->j = sizeof(void*); return ret; } with one essential difference: the function 'f' itself is responsible for popping the extra argument off the stack (the 'x' argument is popped by its caller). This necessitates using the return-with-immediate ('ret 4') instruction instead of the normal 'ret'; this is the only instance where this variant of the 'ret' instruction is used in code generation for C programs on Linux normally. I wonder how this exception came to be. Early versions of GCC (e.g. gcc-1.27) did not implement this convention, i.e. the caller was responsible for popping the invisible pointer similar to the normal arguments. The "callee-pops" variant was implemented later for "compatibility with other compilers", and the option that controls this is called -fpcc-struct-return, which also disables returning small structures in registers (in the example above GCC would return the value in EDX:EAX register pair). Operating systems differ on following this convention. For example, FreeBSD and OpenBSD do not, and neither does Windows. Looking at 386BSD tree in unix-history-repo, I see that it used GCC, not PCC. Where can I look at the history of x86 code generation development in PCC? Do I understand correctly that i386 code generation in PCC evolved in parallel with GCC, and at some point GCC was convinced to adopt the (less efficient) PCC calling convention by default? Did PCC prefer to do this stack adjustment for the invisible pointer on the callee side for some other platform, and the behavior was merely carried over to the i386 port? Thank you. Alexander

3 years, 2 months

1
0
0 0

Re: [TUHS] Documenter's Workbench versions

by Douglas McIlroy

> The Documenter's Workbench is sort of the unsung hero > of Unix. It is why Unix exists, Unix was done to write patents and > troff and the Documenter's Workbench was all about that. My response along the following lines seems to have gone astray. The prime reason for Unix was the desire of Ken, Dennis, and Joe Ossanna to have a pleasant environment for software development. The fig leaf that got the nod from Multics-burned management was that an early use would be to develop a "stand-alone" word-processing system for use in typing pools and secretarial offices. Perhaps they had in mind "dedicated", as distinct from "stand-alone"; that's what eventuated in various cases, most notably in the legal/patent department and in the AT&T CEO's office. Both those systems were targets of opportunity, not foreseen from the start. When Unix was up and running on the PDP-11, Joe got wind of the legal department having installed a commercial word processor. He went to pitch Unix as an alternative and clinched a trial by promising to make roff able to number lines by tomorrow in order to fulfill a patent-office requirement that the commercial system did not support. Modems were installed so legal-department secretaries could try the Research machine. They liked it and Joe's superb customer service. Soon the legal department got a system of their own. Joe went on to create nroff and troff. Document preparation became a widespread use of Unix, but no stand-alone word-processing system was ever undertaken. Doug

3 years, 2 months

2
1
0 0

"Applications for UnixWare" available online

by Greg 'groggy' Lehey

Decades ago (mid 1993) I produced a CD-ROM with free software for Novell's UnixWare entitled "Applications for UnixWare". This was at Novell's request, and they distributed the CDs at trade shows. There's nothing very special in the CD, but I recently received a request for it, so I put it up with a minimal description at http://www.lemis.com/grog/Software/Applications-for-UnixWare.php Feel free to copy it (with attribution). Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php

3 years, 2 months

1
0
0 0

Brenda Baker's Struct Memo

by Warren Toomey

All, I've just placed this document at https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstru… Many thanks to Doug for passing it on! Cheers, Warren ----- Forwarded message from Douglas McIlroy ----- Warren, Someone asked if Brenda Baker's original technical memorandum about struct is available. I scanned my copy and passed it on, secure in my belief that the Labs won't care since it is essentially the same as her journal publication. For the memo to be genuinely available, I'd like to send it to TUHS. With that in mind I redacted information about corporate organization and distribution channels. However the memo still bears the AT&T logo and the words "not for publication". Doug ----- End forwarded message -----

3 years, 2 months

2
1
0 0

Re: [TUHS] Brenda Baker's Struct Memo

by Nelson H. F. Beebe

Thanks to Doug and Warren for getting Brenda Baker's memo on struct online at https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstru… She later published a formal article about that work in An Algorithm for Structuring Flowgraphs Journal of the Association for Computing Machinery 24(1) 98--120 January 1977 https://doi.org/10.1145/321992.321999 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

3 years, 2 months

1
0
0 0

Pipes and PRISM

by Paul Winalski

Last week there was a bit of discussion about the different shells that would eventually lead to srb writing the shell that took his name and the command syntax and semantics that most modern shells use today. Some of you may remember, VMS had a command interpreter called DCL (Digital Command language), part of an attempt to make command syntax uniform across DEC's different operating systems (TOPS-20 also used DCL). As DEC started to recognize the value of the Unix marketplace, a project was born in DEC's Commercial Languages and Tools group to bring the Unix Bourne shell to VMS and to sell it as a product they called DEC Shell. I had been part of that effort and one of the issues we had to solve is providing formal UNIX pipe semantics. They of course needed to somehow implement UNIX style process pipelines. VMS from the beginning has had an interprocess communications pseudo-device called the mailbox that can be written to and read from via the usual I/O mechanism (the QIO system service). A large problem with them is that it is not possible to detect the "broken pipe" condition with a mailbox and that feature deficiency made them unsuitable for use with DEC Shell. So the team had me write a new device driver, based closely on the mailbox driver, but that could detect broken pipes lines UNIX-style. Shortly after I finished the VMS pipe driver, the team at DECwest had started work on the MICA project, which was Dave Culter's proposed OS unification. Dave's team had developed a machine architecture called PRISM (Proposed RISC Machine) to be the VAX follow-on. For forward compatibility purposes, PRISM would have to support both Ultrix and VMS. Dave and team had already written a microkernel-based, lightweight OS for VAX called VAXeln that was intended for real-time applications. His new idea was to have a MACH-like microkernel OS which he called MICA and then to put three user mode personality modules on top of that: P.VMS, implementing the VMS system services and ABI P.Ultrix, implementing the Unix system calls and ABI P.TBD, a new OS API and ABI intended to supersede VMS So I wrote the attached "why pipes" memo to explain to Cutler's team why it was important to implement pipes natively in P.TBD if they wanted that OS to be a viable follow-on to VMS and Ultrix. In the end, Dick Sites's 64-bit RISC machine architecture proposal, which was called Alpha, won out over PRISM. Cutler and a bunch of his DECwest engineering team went off to Microsoft. Dave's idea of a microkernel-based OS with multiple personalities of course saw the light of day originally as NT OS/2, but because of the idea of multiple personalities, when Microsoft and IBM divorced Dave was able to quickly pivot to the now infamous Win32 personality, as what would be called Windows NT. It was also easy for Softway Systems to later complete the NT POSIX layer for their Interix product, which now a few generations later is called WSL by Microsoft. -Paul W.

3 years, 2 months

5
7
0 0

Re: [TUHS] Memory on Lion's v6

by jnc＠mercury.lcs.mit.edu

> You made a comment that MINI-UNIX wasn't available outside of Bell... No, I didn't say that. What I _actually_ said was: "don't think they were in wide use outside Bell". Noel PS: Can I appeal to people to please take a few seconds of their time and trim messages they are replying to? Thank you.

3 years, 2 months

1
0
0 0

Re: [TUHS] Memory on Lion's v6

by jnc＠mercury.lcs.mit.edu

> From: Andrew Hume > the actual configuration of Lions; PDP 11/40 was > 128 Kbytes of core memory > ... > but note that because ... of addressing weirdness (the top 8KB were > memory-mapped to I/O registers), Lions' PDP actually had 112KB of main > memory I think that '112KB' must be an error; the 8KB for the 'I/O page' (as DEC eventually named ir, long after the rest of the world had started using the term :-) were deducted from the _UNIBUS_ address space, meaning a UNIBUS -11 (the 'pure' UNIBUS -11's, i.e. other than the -11/70, -11/44, etc) could have a maximum of 248KB of main memory (which is on the UNIBUS). A pure UNIBUS -11 with 128KB of main memory (like Lions') has... 128KB of main memory. The 'small memory management model' -11's (like the /40, /60, /23, etc) can use at most 64KB of that _at any moment in time_ for user processes (i.e. directly accessible by the CPU, in 'user' mode). (The kernel on such machines is basically retricted to 56KB at any moment in time, since one 'segment/page' - the terminology changed over time - has to be dedicated to the I/O page: the memory management control registers are in that, so once the CPU can no longer 'see' them, it's stuck. Long, potentially interesting digression about, and ways to semi-work around that, elided, unless people want to hear it.) > From: Noel Chiappa > The -11/40 (as it was at first) that I had at LCS had, to start with, > I'm pretty sure, 3 MM11-L units .. - i.e. 48KB. I know this sounds > incredible, and I'm having a hard time believing it myself, wondering > if my memory is failing with age It is: # size /lib/c0 13440+2728+10390=26558 (63676) ('c1' takes 14848+6950+2088=23886, FWIW.) So 'my' -11/40 must have had more than 48KB. MINI-UNIX provides, on an -11/05 type machine with the maximum of 56KB of addressable main memory (if you plugged in 64KB worth, the /05 CPU couldn't 'see' the top 8KB of that), up to 32KB for a user process. So that will just hold the stock V6 C compiler. I'm not now sure how much memory my -11 _did_ have initially, but it's not important. Noel

3 years, 2 months

2
1
0 0

Lorinda Cherry

by Brian Walden

I enjoy this dc(1) discussion. I am a daily dc user, and since my fisrt calculator was an HP-45 (circa 1973) RPN felt right. However I think dc pre-dates ALL HP calculators, since there was one in the 1st Edition written in assembly. I extened my version of dc (way before gnu existed) based on common buttons I used from HP calculators: CMD WHAT # comment, to new line ~ change sign of top of stack (CHS key) | 1/top of stack (1/x key) e push 99 digits of e (2.718..) on the stack @ push 99 digits of pi on the stack (looks like a circle) r reverse top of stack (x<>y key) I had been fascinated with pi stemimg from the Star Trek epsiode Wolf in the Fold where Spock uses it to usa all computing power "Computer, this is a Class A compulsory directive. Compute to the last digit the value of pi." "As we know, the value of pi is a transcendental figure without resolution. The computer banks will work on this problem to the exclusion of all else until we order it to stop." As it was supposed to be "arbitrary precision" here was my tool. So I wrote Machin formula in dc slowing increasing the scale and printing the results. In the orginal dc, yes the whole part was arbitrary, but the decimal part (scale) was limited to 99. Well that became a disappiontment. (this program is lost to time) So I decided to rewrite it but increasing pi as a whole numbers instead of increasing scale (ex. 31415, 314159, 3141592, ... etc) I still have that program which is simply this -- [sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ 1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx if you run it you'll notice the last 1 to 2 digits are wrong due to precision. The next problem became small memory. I still have thes saved output before it crashed at 1024 digits. No idea what specs of the machine it was run on anymore its really old -- 3141592653589793238462643383279502884197169399375105820974944592307816\ 4062862089986280348253421170679821480865132823066470938446095505822317\ 2535940812848111745028410270193852110555964462294895493038196442881097\ 5665933446128475648233786783165271201909145648566923460348610454326648\ 2133936072602491412737245870066063155881748815209209628292540917153643\ 6789259036001133053054882046652138414695194151160943305727036575959195\ 3092186117381932611793105118548074462379962749567351885752724891227938\ 1830119491298336733624406566430860213949463952247371907021798609437027\ 7053921717629317675238467481846766940513200056812714526356082778577134\ 2757789609173637178721468440901224953430146549585371050792279689258923\ 5420199561121290219608640344181598136297747713099605187072113499999983\ 7297804995105973173281609631859502445945534690830264252230825334468503\ 5261931188171010003137838752886587533208381420617177669147303598253490\ 4287554687311595628638823537875937519577818577805321712268066130019278\ 76611195909216420198938095257201065485862972 out of space: salloc all 8587356 rel 8587326 headmor 1 nbytes -28318 stk 71154 rd 125364 wt 125367 beg 125364 last 125367 83 11 0 30 IOT trap - core dumped But I was much happier with that. On a side note: programming dc is hard. There was no comment character. And it's a pain to read, and it's a pain to debug. When I discovered the Chudnovsky algorithm for pi, of course I implemented it in dc -- [0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP 7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx At 99 digits of scale it ran out in 7 rounds, but now with that limitation removed and large memeories it just goes on and on..... -Brian PS: Thanks for the fast OpenBSD version of dc, Otto. Otto Moerbeek wrote: > On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote: > > > On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave at horsfall.org> wrote: > > > > > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote: > > > > > >> Watching the prime number generator (from the Wikipedia page on dc) > > >> running on the 11/23 is much more entertaining than doing it on the > > >> modern workstation I'm typing this on: > > >> > > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x > > > > > > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient > > > FreeBSD box. > > > > That may be because FreeBSD continues computing primes while the MacOS > > dc gives up after a while! > > > > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while > > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > > ^C 11.93 real 11.79 user 0.13 sys > > $ wc xxx > > 47161 47161 319109 xxx > > $ size `which dc` > > text data bss dec hex filename > > 238159 2784 11072 252015 0x3d86f /usr/bin/dc > > > > MacOS (m1 pro, prob. 2Ghz) > > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > > time: command terminated abnormally > > 1.00 real 0.98 user 0.01 sys > > [2] 37135 segmentation fault command time dc <<< > xxx > > $ wc xxx > > 7342 7342 42626 xxx > > $ size `which dc` > > __TEXT __DATA __OBJC others dec hex > > 32768 16384 0 4295016448 4295065600 100018000 > > > > MacOS uses the GNU implementation which has a long standing issue with > deep recursion. It even cannot handle the tail recursive calls used > here and will run out of its stack. > > -Otto

3 years, 2 months

3
2
0 0

ok-labs.com is not OK

by Dave Horsfall

Someone on one of these lists seems to be at ok-labs.com; well... aneurin% host ok-labs.com ;; connection timed out; no servers could be reached aneurin% Houston, we have a problem... Could whoever is responsible please sprinkle some fairy dust somewhere? Thanks. -- Dave

3 years, 2 months

1
0
0 0

Memory on Lion's v6

by Will Senn

Does anybody know how much memory was configured on the PDP-11 that Lion's used for the commentary system. Here's what the book says about the system: ; from lions, page 1 ; The code selection presumes a "model" system consisting of: ; PDP11/40 processor; ; RK05 disk drives; ; LP11 line printer; ; PC11 paper tape reader/punch; ; KL11 terminal interface. I usually add the mag tape, too ; TM10 magnetic tape - not in lions, but super handy It seems like he must have had an MMU and 128k memory, but I don't know. I'm hoping y'all remember, know, or can otherwise divine the correct value. I've run with no MMU - crash on boot. I've also run with less memory, but then cc won't build mkconf, when I have the TM10 enabled kernel loaded. As a reminder, his book was published in 1977. Thanks, Will

3 years, 2 months

5
5
0 0

Re: [TUHS] Memory on Lion's v6

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > Does anybody know how much memory was configured on the PDP-11 that > Lion's used for the commentary system. Here's what the book says about > the system: > .. > ; PDP11/40 processor; > ... > It seems like he must have had an MMU V6 absolutely requires an MMU; the need for it is all throughout basic attributes of the system - e.g. user processes start their address space at 0. (BTW, there are V6 descendants, MINI-UNIX: http://gunkies.org/wiki/MINI-UNIX and LSX, which don't use/need an MMU, and run on -11 models without memory managament, such as -11/05's, but I don't think they were in wide use outside Bell.) > and 128k memory The -11/40, as originally released, only supported the MM11-L, which came in multiples of 16KB (for a 3-board set). Use of the later MM11-U (32KB units) required a new main power harness, which only came in on higher-serial-numbered -11/40's. The -11/40 (as it was at first) that I had at LCS had, to start with, I'm pretty sure, 3 MM11-L units (i.e. one MM11-L backplane full) - i.e. 48KB. I know this sounds incredible, and I'm having a hard time believing it myself, wondering if my memory is failing with age; but it definitely had extraordinarily little. I just looked on my V6 (running in a simulator), and it appears that by trimming all parameters (e.g. number of disk buffers) to the absolute bone, the kernel could be trimmed to about 36KB. (I haven't actually tried it, since I don't feel like recompiling all the kernel modules, but one can estimate it - take the current system size [44KB], delete 10 buffers @ .5KB gives 39KB, etc, etc.) That would allow a maximum user process of 12KB on a 48KB machine - and MINI-UNIX, which runs basically stock V6 user code, can manage with user processes that small. I see Andrew's email which reports that the Lions machine had more main memory, 128KB (maybe 4 MM11-U's - two MM11-U backplanes full); that woould have made their life a lot easier. Noel

3 years, 2 months

1
0
0 0

Re: [TUHS] run commands at login in v6 and stty

by Douglas McIlroy

> The X11 tree was a heavily ifdef-ed. And it needed to be, I don't have > an answer as to how you would reuse all that code on different hardware > in a better way. Plan 9 did it with #include. The name of the included file was the same for every architecture. Only the search path for include files changed. Done with care, this eliminates the typical upfront #ifdefs.that define constants and set flags. Other preprocessor conditionals can usually be replaced by a regular if, letting the compiler optimize away the unwanted alternative. This makes conditionals obey the scope rules of C. Doug

3 years, 2 months

8
8
0 0

Re: [TUHS] run commands at login in v6 and stty

by Brian Walden

6th Edition used the Thompson shell as /bin/sh. I don't think it had those capabilities. Sometimes you could find an early version of the Bourne shell in /bin/nsh (new shell) in v6. The 7th Edition made the Bourne shell /bin/sh. And there sometimes you could find the Thompson shell in /bin/osh (old shell). Will Senn wrote: > Login commands question: > > I'm sure it's simple, but I can't figure it out. How do I get something > to run at login in v6? Right now, I use ed to create a file 'setprof' > that contains: > > stty erase[space][backspace][return] > stty nl0 cr0 > > Then after logging in: > > sh setprof > > It works, but, it is pretty clunky. > > stty question: > > So, I looked at stty.c and it looks like the following should work, if > the terminal is sending ^H for backspace: > > #define BS0 0 > #define BS1 0100000 > > modes[] > ... > "bs0", > BS0, BS1, > > "bs1", > BS1, BS1, > > > but: > > stty bs0 > or > stty bs1 > > don't result in proper backspace handling.. > > but: > > stty[space][^h][return] > > > works... > > Thoughts?

3 years, 2 months

3
2
0 0

run commands at login in v6 and stty

by Will Senn

Login commands question: I'm sure it's simple, but I can't figure it out. How do I get something to run at login in v6? Right now, I use ed to create a file 'setprof' that contains: stty erase[space][backspace][return] stty nl0 cr0 Then after logging in: sh setprof It works, but, it is pretty clunky. stty question: So, I looked at stty.c and it looks like the following should work, if the terminal is sending ^H for backspace: #define BS0 0 #define BS1 0100000 modes[] ... "bs0", BS0, BS1, "bs1", BS1, BS1, but: stty bs0 or stty bs1 don't result in proper backspace handling.. but: stty[space][^h][return] works... Thoughts?

3 years, 2 months

5
6
0 0

Re: [TUHS] run commands at login in v6 and stty

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > what I don't remember was it in v5 Your memory is going! :-) We discussed this recently (well, recently in _our_ timescale :-); it's built into in 'cc' in V5: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c see "expand(file)". Noel

3 years, 2 months

1
0
0 0

Re: [TUHS] CSR in V6

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > My question is - how did y'all run things - with CSR zero and no kernel > messages ... or with CSR non-zero and kernel messages. On the -11/45 V6+ at MIT, we didn't have a printing terminal on the console, just a VT52. We had a tool at MIT called 'dmesg': http://ana-3.lcs.mit.edu/~jnc/tech/unix/man8/dmesg.8 which made up for that a bit. We normally ran with the CSR set to 173030 - the 'boot in single-user' setting. That's because at one point the machine was in the 9th floor machine room, but the console VT52 was on the 5th floor (where our offices were - the famous print of the GE-645 Multics was on the hallway wall outside mine :-), and I'd added a 'reboot()' system call (nothing fancy, it just jumped to the bootstrap ROM), so we could reboot the machine without going up in the elevator (not if it had crashed, of course). Later on, after we'd done with kernel hacking (adding a network interface, and IP), and the machine stayed up for long periods, we moved the console up next to the machine (since if it crashed, you had to use the front panel to restart it, so you had to be up there anyway); we stayed with the default CSR setting, though. (If it panic'd, you could see the reason why when you went to reboot it.) > Oh, BTW, I know I've seen this noted elsewhere, but I can't remember > where. Maybe at: https://gunkies.org/wiki/UNIX_Sixth_Edition#Distros which discusses it? Noel

3 years, 2 months

1
0
0 0

CSR in V6

by Will Senn

I noticed in v6 source that putch in prf.c - the system kernel printf's character routine, only prints to the console if the Console Switch Register is non-zero. My question is - how did y'all run things - with CSR zero and no kernel messages (seems dangerous to me, being naive and all) or with CSR non-zero and kernel messages. On my FreeBSD instance, I value the messages that show up on console as they've alerted me to big problems in the past, but on my Mac, not as much (sure you can run Console and see them, but they aren't immediate). Oh, BTW, I know I've seen this noted elsewhere, but I can't remember where. Dennis's v6 doesn't have the Western Electric message: mem = 435 RESTRICTED RIGHTS Use, duplication or disclosure is subject to restrictions stated in Contract with Western Electric Company, Inc. It was a bit of a head scratcher as I was trying to read from the Dennis version of the distro on my mac while running Wellsch's tape on simh. I spent quite a while spinning my wheels looking for "Western" in the files to no avail. I thought something was screwy with the files or my mac.

3 years, 2 months

1
0
0 0

Lions v6 source code pdf

by Will Senn

All, I got sick of poring over my Peer-to-Peer communications version of Lion's commentary - trying to read it while digging around in v6 was getting annoying. Of course, if you don't already own, rush out and by a copy. It's great stuff. Anyhow, the problem is that it's perfect bound, landscape and it's not searchable. Hunting around the internet, I found pdfs that were searchable, but they were based on v7 being back-engineered to v6 code. So, I located a decent source of electronically readable Lion's source at https://warsus.github.io/lions-/ and off I went. I took the code and did a bit (quite a bit) of tweakage on it to get it formatted in pdf, and created a version in letter format that I find pretty useful. It can be read from a printout while messing around in v6. I've done some proofing, but I don't claim it's perfect. If you find any issues with it, let me know and I'll try to fix them (thanks, Clem for early suggestions). Here's what's in the letter sized pdf: Tweaked Cover Page Improved Table of Contents Lion's version of V6 Source Code Appendices Source File Sheets Alphabetical List Source File Locations in Running V6 System What isn't in the pdf: Original Forewords, Prefaces, or Letters (not needed for coding) Symbol Lists, Cross references, or Indexes (beyond my skills at the moment) All in all, I have found it quite readable and useful for my own work. I don't claim any ownership or contribution, other than in improving the readability of the work for modern readers. If the cross reference thing kills you, just use gnu ctags on the source directories and ctags -x for the line numbers. Here's the link to the posting: http://decuser.blogspot.com/2022/02/tweaked-version-of-lions-v6-source-code… - will

3 years, 2 months

1
0
0 0

Lorinda Cherry

by Douglas McIlroy

Lorinda Cherry, a long-time member of the original Unix Lab died recently. Here is a slightly edited reminiscence that I sent to the president of the National Center for Women and Information Technology in 2018 when they honored her with their Pioneer in Tech award. As Lorinda Cherry's longtime colleague at Bell Labs, I was very pleased to hear she has been chosen for the NCWIT Pioneer Award. At the risk of telling you things you already know, I offer some remarks about her career. I will mainly speak of things I saw at first hand when our offices were two doors apart, from the early '70s through 1994, when Lorinda left Bell Labs in the AT&T/Lucent split. Most of the work I describe broke new ground in computing; "pioneer" is an apt term. Lorinda, like many women (including my own mother and my wife), had to fight the system to be allowed to study math and science in college. She was hired by Visual and Acoustics Research at Bell Labs as a TA--the typical fate of women graduates, while their male counterparts were hired as full members of technical staff. It would take another decade for that unequal treatment to be rectified. Even then, one year she received a statement of benefits that explained what her wife would receive upon her death. When Lorinda called HR to confirm that they meant spouse, they said no, and demanded that the notice be returned. (She declined.) It seemed that husbands would not get equal treatment until AT&T lost a current court case. The loss was a foregone conclusion; still AT&T preferred to pay lawyers rather than widowers, and fought it to the bitter end. Lorinda moved to my department in Computing Science when the Unix operating system was in its infancy. Initially she collaborated with Ken Knowlton on nascent graphics applications: Beflix, a system for producing artistically pixillated films, and an early program for rendering ball-and-stick molecular models. She then joined the (self-organized) Unix team, collaborating on several applications with Bob Morris. First came "dc", an unlimited-precision desk calculator, which is still a Unix staple 45 years on. Building on dc, she would later make "bc", which made unlimited precision available in familiar programming-language notation and became the interface of choice to dc. Then came "form" and "fed", nominally a form-letter generator and editor. In fact they were more of a personal memory bank, a step towards Vannevar Bush's famous Memex concept--an interesting try that didn't pay off at that scale. Memex had to sleep two more decades before mutating into the Worldwide Web. Lorinda had a hand in "typo", too, a Morris invention that found gross spelling mistakes by statistical analysis. Sorting the words of a document by the similarity of their trigrams to those in the rest of the document tended to bring typos to the front of the list. This worked remarkably well and gained popularity as a spell-checker until a much less interesting program backed by a big dictionary took over. Taken together, these initial forays foretold a productive computer science career centered around graphics, little languages, and text processing. By connecting a phototypesetter as an output device for Unix, Joe Ossanna initiated a revolution in document preparation. The new resource prompted a flurry of disparate looking documents until Mike Lesk brought order to the chaos by creating a macro package to produce a useful standard paper format. Taking over from Lesk, Lorinda observed the difficulty of typesetting the mathematics (which the printing industry counted as "penalty copy") that occurred in many research papers, and set out to simplify the task of rendering mathematical formulas, Brian Kernighan soon joined her effort. The result was "eqn", which built on the way people read formulas aloud to make a quite intuitive language for describing display formulas. Having pioneered a pattern that has been adopted throughout the industry, eqn is still in use forty years later. Lorinda also wrote an interpreter to render phototypesetter copy on a cathode-ray terminal. This allowed one to see typeset documents without the hassle of exposing and developing film. Though everyone has similar technology at their fingertips today, this was genuinely pioneering work at the time. You are certainly aware of Writers Workbench, which gained national publicity, including Lorinda's appearance on the Today Show. It all began as a one-woman skunk-works project. Noticing the very slow progress in natuaral-language processing, she identified a useful subtask that could be carved out of the larger problem: identifying parts of speech. Using a vocabulary of function words (articles, pronouns, prepositions and conjunctions) and rules of inflection, she was able to classify parts of speech in running text with impressive accuracy. When Rutgers professor William Vesterman proposed a style-assessing program, with measures such as the frequencies of adjectives, subordinate clauses, or compound sentences, Lorinda was able to harness her "parts" program to implement the idea in a couple of weeks. Subsequently Nina MacDonald, with Lorinda's support, incorporated it into a larger suite that checked and made suggestions about other stylistic issues such as cliches, malapropisms, and redundancy. Another aspect of text processing that Lorinda addressed was topic identification. Terms (often word pairs) that occur with abnormal frequency are likely to describe the topic at hand. She used this idea to construct first drafts of indexes. One in-house application was to the Unix manual, which up until that time had only a table of contents, but no index. This was a huge boon for a document so packed with detail. In her final years at Bell Labs, Lorinda teamed up with AT&T trouble-call centers to analyze the call transcripts that attendants recorded on the fly--very sketchy prose, replete with ad-hoc contractions and misspellings. The purpose was to identify systemic problems that would not be obvious from transcripts considered individually. When an unusual topic appeared at the same time in multiple transcripts, those transcripts were singled out for further study. The scheme worked and led to early detection of system anomalies. In one case, it led AT&T to suspend publication of a house organ that rubbed customers the wrong way. Lorinda was not cut from the same mold as most of her colleagues. First she was a woman, which meant she faced special obstacles. Then, while there were several pilots among us, there was only one shower of dogs and only one car racer--moreover one who became a regional exec of the Sports Car Club of America. For years she organized and officiated at races as well as participating. Lorinda was always determined, but never pushy. The determination shows in her success in text analysis, which involves much sheer grit--there are no theoretical shortcuts in this subject. She published little, but did a lot. I am glad to see her honored. Doug McIlroy

3 years, 3 months

34
55
0 0

Re: [TUHS] v7 source code for sh

by Brian Walden

The one I remember using in the 80s was called "fep" written by Kazumasa Utashiro of Software Research Associates. It was probbaly posetd posted to comp.sources.unix usenet group. -Brian Chet Ramey wrote: > On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Chet Ramey writes: > > > >> It always seemed like it would have been just the thing to implement as a > >> tty streams module, but research Unix went in a different direction. > > > > I'm really surprised nobody has implemented a basic readline as a > > tty line discipline by now. I was poking around the OpenBSD NMEA > > line discipline code a few weeks ago and thinking it shouldn't be > > that hard to do. > > It's not that hard. The complexity is in how sophisticated you want to get > with redisplay and whether you want to allow user-specified key bindings. > > > Did anyone think about doing this in the past? If yes, what made you > > decide against doing it? (Or a streams implementation, for that matter.) > > There have been several implementations (I never did one). I suspect that > the people who were in a position to integrate that functionality into > distributed kernels were not supportive, or the code didn't get to them > at the right time. > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

3 years, 3 months

3
2
0 0

Re: [TUHS] v7 source code for sh

by Bakul Shah

On Feb 19, 2022, at 8:11 AM, Clem Cole <clemc(a)ccc.com> wrote: > > > On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas <usotsuki(a)buric.co> wrote: >> Apparently Bourne was heavily into ALGOL, > That's sort of an understatement. I believe that when he was at Cambridge, he was one of the people that helped to take the Algol-X proposal and turned it into the Algol-68 definition. I also believe he worked on their famous implementation of same. Some of you may be interested in this “A history of Algol68” paper: https://dl.acm.org/doi/pdf/10.1145/234286.1057810 The author, Charles H Lindsey, still occasionally posts on comp.lang.misc about Algol68. Among other things Bourne was a coauthor of Algol68C, a portable implementation of Algol68.

3 years, 3 months

12
15
0 0

Re: [TUHS] v7 source code for sh

by norman＠oclsc.org

Rob Pike: I did the same to adb, which turned out to have a really good debugger hidden under a few serious bugs of its own, which I fixed. ===== Memories. Was it you who replaced ptrace with /proc in adb, or did I do that? I do remember I was the one who took ptrace out of sdb (which a few 1127-ers, or perhaps 112-ers on alice and rabbit still used). After which I removed ptrace from the kernel, and from the copy of the V8 manual in the UNIX room. Conveniently ptrace occupied two facing pages; I glued them together. I also later did some work to try to isolate the target-dependent parts of adb and to make them work in host-independent ways--e.g. assembling ints byte-by-byte rather than assuming byte order--to make it easier to make a cross adb, e.g. to examine PDP-11 or 68K core dumps on a VAX. I miss adb; maybe it's time to revive it, though these days I'd be tempted to rewrite it in Python so I could just load the right module at runtime to pick the desired target. Norman Wilson Toronto ON

3 years, 3 months

2
1
0 0

Re: [TUHS] v7 source code for sh

by Rudi Blom

Second half of the 1980-tish when the computer division of Philips Electronics started on their own Motorola M68010 / UNIX System V.3 (don't remember for sure I'm afraid) they used a syntax.h with macros similar to mac.h. Only I understand it's more Pascal like. Appended the 1987 version I found in my archive. Cheers, rubl -- The more I learn the better I understand I know nothing.

3 years, 3 months

1
0
0 0

v7 source code for sh

by Will Senn

I have been poring through the v7 source code lately, and came across an oddity I would like to know more about. Specifically, in sh. The code for sh is c, but it makes *extensive* use of of macros, for example: /usr/src/cmd/sh/word.c ... WHILE (c=nextc(0), space(c)) DONE ... The macros for sh are defined in mac.h: /usr/src/cmd/sh/mac.h ... #define BEGIN { #define END } #define SWITCH switch( #define IN ){ #define ENDSW } #define FOR for( #define WHILE while( #define DO ){ #define OD ;} #define REP do{ #define PER }while( #define DONE ); ... I can read the resultant code through the lens of my experience coding c, but I'm curious why the macros and how this came about? In v6, the sh source is straight up c. Is there a story behind it worth knowing? Thanks, Will

3 years, 3 months

5
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS