I’m re-reading Brian Kernighan’s book on Early Unix (‘Unix: A History & Memoir’)
and he mentions the (on disk) documentation that came with Unix - something that made it stand out, even for some decades.
Doug McIlroy has commented on v2-v3 (1972-73?) being an extremely productive year for Ken & Dennis.
But as well, they wrote papers and man pages, probably more.
I’ve never heard anyone mention keyboard skills with the people of the CSRC - doesn’t anyone know?
There’s at least one Internet meme that highly productive coders necessarily have good keyboard skills,
which leads to also producing documentation or, at least, not avoiding it entirely, as often happens commercially.
Underlying this is something I once caught as a random comment:
The commonality of skills between Writing & Coding.
Does anyone has any good refs for this crossover?
Is it a real effect or a biased view.
That great programmers are also “good writers”:
takes time & focus, clarity of vision, deliberate intent and many revisions, chopping away the cruft that’s isn’t “the thing” and “polishing”, not rushing it out the door.
Ken is famous for his brevity and succinct statements.
Not sure if that’s a personal preference, a mastered skill or “economy in everything”.
A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986
CC (v2 page 52)
V2 saw a burst of languages:
a new TMG,
a B that worked in both core-resident and software-paged versions,
the completion of Fortran IV (Thompson and Ritchie), and
Ritchie's first C, conceived as B with data types.
In that furiously productive year Thompson and Ritchie together
wrote and debugged about
100,000 lines of production code.
Programming's Dirtiest Little Secret
Wednesday, September 10, 2008
It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else.
But when it comes to programming, there are only so many things you can sacrifice!
You can cut down on your documentation.
You can cut down on commenting your code.
You can cut down on email conversations and
participation in online discussions, preferring group discussions and hallway conversations.
And... well, that's about it.
So guess what non-touch-typists sacrifice?
All of it, man.
They sacrifice all of it.
Touch typists can spot an illtyperate programmer from a mile away.
They don't even have to be in the same room.
For starters, non-typists are almost invisible.
They don't leave a footprint in our online community.
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate?
My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code.
Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s.
Any other notable work in this area prior to 1985?
How was the SMP implementation in SVr3 judged back in its day?
The standard routine for drawing menus on the jerq was
'menuhit'. Items in the menu were centered, and the menu was
scrollable when a certain threshold number of items was
reached, and in addition, when the mouse pointer was in the
top (bottom) item of the menu and it was possible to scroll
in the appropriate direction, the menu was scrolled up or
down 1 line. The structure associated with these menus is
There was however another menu-drawing routine, 'mhit', the
menus drawn by this being hierarchical, the structure NMenu,
which no longer contained text strings but an array of NItems.
NMenus also had provision for 'help' text to be displayed, a
simple string displayed on the screen, when button 1 was
pressed while an entry in the menu was selected.
The earliest version in the Eight Edition jerq code, also has
one function in the NMenu structure which is called when the
mouse pointer invokes a hierarchical menu. By Ninth Edition
this has been expanded, with 3 functions, one as above, one
invoked when an item is selected ('hit') and one when a
hierarchical menu is exited.
In the jerq code directories, under 'lib/jj', is a small 'ms'
document, 'A Library of Goo for the 5620', which lists
routines available in the library, and their authors. Andrew
Hume is listed as the author of 'mhit'.
Are there examples of code using these three menu functions
('dfn', 'hfn', 'bfn')?
There seems to have been little interest in hierarchical menus
at the labs, their use was quite limited. I found a program
in the Tenth Edition archive, 'bubble' (which seems to be a
program for displaying the three-dimensional structure of
molecules) which uses them. 'samuel' made heavy use of them,
including use of the 'hit' function, and Tom Cargill used
basically the same code in 'pads' wherein the routine was
The plain 'menuhit' survived into Plan9, but as far as I
know, it is only used by 'sam'.
Available at https://www.skeeve.com/bell-labs-cstrs.tar.gz
Warren and Brantley and anyone else, feel free to retrieve.
I have two sets - both are in the tarball so there are undoubtedly
duplications. If someone else can curate them into single canonical
set that'd be helpful, I just don't have the time right now.
Attached is "A Supplemental Document For Awk". This circulated on USENET
in the 80s. My copy is dated January 18, 1989, but I'm sure it's
older than that. One clue is the reference to the 4.2 BSD manual,
and 4.3 came out already in 1986 or so.
Does anyone else have a copy of this with perhaps an older date?
As far as I can tell from a short search, the author is no
longer living. If someone knows better and can provide contact
info for him, that'd be great.
In the meantime, Warren, do you want to add it to the archives?
There is a little known suite of programs, written by Peter Weinberger,
found as 'btree', or 'cbt', in the archives for Eighth and Tenth
The code in the Eighth Edition archive seems to be the earliest, and
has fewer utilities than available in the Tenth Edition code. A search
through files shows that it was used by 'road', 'weather' and
There is an ms file, 'memo', describing the programs, amongst the code,
but an appendix seems to be missing. If anyone knows about this or
where it might be I'd like to get my hands on it.
'Memo' itself is interesting because it's the only troff document I've
seen amongst the reseach papers (excluding Christopher Van Wyk's own
paper of course) that uses 'ideal', in this case, for drawing a
picture depicting B-tree structure.
Hello, I'd like to share some analysis from my recent Sixth Edition pass of my mandiff repository. For the V5-V6 diff, I opted for a branching approach, starting with a last universal common ancestor (which isn't quite right ). I compared each set of changes with the MERT0, PWB 1.0, CB-UNIX 2.3, 32V, and to a lesser extent V7 and System III manuals attempting to suss out the spiderweb of changes between them all. I created a series of branches representing last common changes between groups of branches as well. This has resulted in a littering of merge commits in the repository, but a banana's gonna have a peel.
A few important points about document genealogy here:
- The MERT0 manual, in the introduction, denotes descent from the USG Program Generic 3 manual. Furthermore, there is a listing of which pages would be replaced, which also serves as a key to which pages should be PG3 original text. However, the hs(IV) and ht(IV) pages make reference to specific MERT pages, so I question the veracity of this list. In any case, for the purposes of this analysis, much may extrapolate to USG PG3 as well. More study is needed.
- The CB-UNIX manual currently available is Edition 2.3. In studying the numbering system for CB, I've found that this represents Release 2, Issue 3, as in the kernel there are references to releases, not editions. The clue is in one of the manpages somewhere, I don't recollect as of this typing where, but that'll come back around soon enough. The manual itself appears to be from a binder that was once a CB-UNIX 2.1 binder and had select pages replaced. There are some bits and pieces of 2.1 pages that were otherwise slated to be replaced, alluding to things like the /etc/lines file in common with PG3. In any case I've prioritized 2.1 changes over 2.3 changes where they can be determined, but like PG3, no complete picture can be determined of 2.1 from available documentation.
For each of the branches, the following number of files in total reflect V5-V6 changes which aren't incorporated:
- 32V: 7
- PWB: 15
- MERT0: 46
Of these MERT0 has the greatest number of items lacking research's upstream changes from late '74-early '75. Among them:
- Has a V5-ish bas(I), no rc(I) (ratfor) at all
- The group system is not present, newgrp(I), group(V), chgrp(VIII), etc. are nowhere to be found
- nice(I) has no priority argument, simply sets a "low priority"
- TTYs are still referred to as "teletypes" instead of "typewriters" in many places
- there are 10 TTYs max so many commands don't reflect adjustments for two-digit IDs (ps(I) in particular is quite different, very V5)
- retains the lpr print command (which shows up again in 32V and System III)
- additionally, according to the replacement page list, PG3 retained the fed and form editing programs
- Program Generic may not have had a man(I) page, as the one here is a MERT0 addition, hard to say
CB tragically needs to be remerged, found as I was typing this up the system call section got an errant merge with V6 changes that shouldn't be there. Needless to say there is much in section II of the CB manual that leans more V5-ish than V6-ish. PWB differs in minor ways.
The differences can be found in this list https://gitlab.com/segaloco/mandiff/-/merge_requests?scope=all&state=closed
Each of the obviously labeled, closed merges represents a snapshot diff of the particular branch in question. As stated, the CB branch currently is in dire straits, I'm going to work that up again sometime in the future, but I should be able to use this to produce diff-able reproductions of the MERT0 and CB-UNIX 2.3 manual sources for this repository, as well as any other materials that may pop up.
- Matt G.
 - This pass I did not take good notes on such matters, but there are a few pages I'll anecdotally say reflect contents predating V5 sprinkled amongst the various manuals. I will consult with previous diffs when questions arise on in-depth analysis of the non-research changes in the branches. In any case the historical record already confirms CB-UNIX at the very least branched off quite early.
this is my first post on this list.
After looking at the archives for this mailing list, I have seen that
the B language has been discussed several times already.
After viewing Ken Thompson's interview by Brian Kernighan at VCF East
2019, I became interested in the B language, as it seemed full-featured
for system programming, close to C, and simple enough to write a parser
for it without a code generation tool.
So for fun and self-education, I am now writing a (or yet another) B
compiler, in C, after reading Jack Crenshaw's "Let's build a compiler"
documentation ( https://compilers.iecc.com/crenshaw/ )
Here it is: https://git.sr.ht/~f4grx/bpars
It is now starting to generate code for the 68hc11 8-bit platform. It
can also generate C code.
I have written some test programs, found some B examples, but I thought
it would be great to use my compiler with actual B software.
Of course, B was a "transition" language, that did not have a continued
use as soon as it evolved into C. so if any software remains, it will be
quite hard to find.
And here is my question, is any of you aware of original B source code
archives? or are in touch with people that would know?
In particular, I read on this document written by Dennis Ritchie:
> After the TMG version of B was working, Thompson rewrote B in itself
(a bootstrapping step).
I have also read that the YACC tool was initially written in B.
There might be other historical B sources that I am not aware of.
Do you know if any of this code has survived to this day? Where could I
find more information about this?
Thank you very much,
Sebastien Lorquet (F4GRX)