Rather than increase subject drift on a thread I started
"UNIX on (not quite bare) System/370", here's a new thread.
Since the TUHS archive seems to now include documentation,
I decided to take a look and see if the earliest UNIX manual I have
is in the archive:
It was given to me by a friend at Stevens Tech in Hoboken NJ (c. 1980)
who had graduated, and worked for AT&T.
It's hole punched for a four ring binder
(I found an unused Bell System Project Telstar binder to put it in).
The cover page has:
Upper left corner:
Bell Telephone Laboratories Incorperated
PROGRAM APPLICATION INSTRUCTION
Upper right corner:
PA-1C300-01
Section 1
Issue 1, January 1976
AT&TCo SPCS
Center:
UNIX PROGRAMMER'S MANUAL
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January, 1976
The preface starts with:
This document is published as part of the UNIX Operating System Program Generic,
PG-1C300 Issue 2. The development of the Program Generic is the result of the
efforts of the members of the UNIX Support Group, supervised by J.F. Maranzano
and composed of: R. B. Brant, J. Feder, C. D. Perez. T. M. Raleigh, R. E. Swift,
G. C. Vogel and I. A. Winheim.
and ends with
For corrections and comments please contact C. D. Perez, MH 2C-423, Extension
6041.
Not knowing who else I could ask, I brought it to a Boston Usenix (in
the 90's or oughts), and asked DMR if he could identify it. He said
it was an early supported UNIX, and he signed the preface page for me.
The manual has sections I through VIII; all manual pages start with page -1-
I found https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_ja…
with cover page:
UNIX PROGRAM DESCRIPTION
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January 1976
contents:
NUMBER ISSUE TITLE
PD-1C301-01 1 Operating System
PD-1C302-01 1 Device Drivers Section 1
PD-1C303-01 1 Device Drivers Section 2
And consists of descriptions of kernel functions.
So it seems likely that my manual is a companion to that.
I have a Brother printer/scanner, but the paper is fragile, so unless
it's of immediate and burning value to someone, it's unlikely to rise
to the top of my ever-static list of documents to scan....
But if someone has specific questions I can look up, let me know....
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”.
steve j
=========
A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986
M.D. McIlroy
<https://www.cs.dartmouth.edu/~doug/reader.pdf>
<https://archive.org/details/a_research_unix_reader/page/n13/mode/2up>
pg 10
3.4. Languages
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
<http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret…>
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
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
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?
Paul
Came across something interesting by chance in the Sixth Edition document set I recently received. I took the binder to the park for a little light reading and found myself perusing the C reference manual. As an aside, I will always appreciate the style of the manual, and I still pick up something new or see something differently every time I flip the pages. The introduction includes these paragraphs:
> Most of the software for the UNIX time-sharing system is written in C, as is the operating system itself. C is also available on the HIS 6070 computer at Murray Hill, using a compiler written by A. Snyder and currently maintained by S. C. Johnson. A compiler for the IBM System/360/370 series is under construction.
>
> This is a manual only for the C language itself as implemented on the PDP-11. Hints are given occasionally in the text of implementation-dependent features, and an appendix summarizes the differences between the Honeywell and DEC implementations; it also contains some known bugs in each.
I didn't think too much of this initially, but then I found myself looking through some other old documents yesterday evening and found myself reading the memorandum version of the manual that Dennis linked to on his Bell Labs usr page: https://www.bell-labs.com/usr/dmr/www/cman74.pdf
In this version, the paragraphs have been altered and merged:
> Most of the software for the UNIX time-sharing system is written in C, as is the operating system itself. C is also available on the HIS 6070 computer at Murray Hill and and on the IBM System/370 at Holmdel. This paper is a manual only for the C language itself as implemented on the PDP-11. However, hints are given occasionally in the text of implementation-dependent features.
So between the two, the print document I have here indicates the compiler for IBM mainframes is still in the works, but by the January 15, 1974 document, it is noted as complete and in use in Holmdel. Additionally, this print document mentions an appendix detailing DEC vs. Honeywell differences and some other bug notes. Unfortunately this appendix doesn't actually appear to be in the binder, so either it wasn't done yet or was tossed by a previous owner some time ago. Luckily, this appendix, despite the reference being dropped, *is* on the cman74 version.
In any case, upon discovering this, I then spot checked the rest of the contents of the two by seeing if any paragraphs had strange offsets from each other or there were noticeable changes in the visual flow. I didn't read each and every line, instead opting to see if paragraphs still had the same number of lines, the same "outline" (i.e. lines seem to start, end, and break pretty much the same), and that pages started and ended the same, and everything pretty much matched. There may be punctuation changes or other minor edits, but I didn't see anything indicating major changes in the language. The only other thing noticeably different is the references list, with Dennis's cman74 copy containing two extra references mine does not: "A User's Guide to the C Language on the IBM 370." by T.G. Peterson and M.E. Lesk, 1974, and "Programming in C- A Tutorial." by B.W. Kernighan, 1974. The latter is listed as unpublished in cman74. In my copy, aside from the two omitted references, the reference to the CACM paper does not have a date, instead just saying "To appear in C. ACM." and "The GCOS C Library" is listed as an unpublished memorandum with a speculative year of 1974.
So all in all, this appears to be a C Reference Manual most likely from late 1973, or however unlikely, one that was very rapidly published in the first few weeks of 1974 before the mentioned changes on January 15th of that year.
Are there any known copies of the manual that predate this which I can compare back with, or in any case is this particular revision known and captured somewhere? If not, it should be trivial to take the sources from V6 and produce a facsimile copy until it bubbles up in my scanning list (much ahead of it, got the ROFF manual scanned the other day, hoping to hit TMG and m6 in the next few.)
There is also an NROFF manual here that I see referenced in the TOC of the V6 document set in the source, but don't actually see in files. It is dated 9/11/74 and is only labeled "NROFF Users' Manual", no TROFF in the title. It is also noted as the "Second Edition" in the header. This document makes reference to the "TROFF User's Manual", dated April 1974, also by Ossanna. Of note too is a "Quick NROFF Addendum" dated 5/19/75 that is included at the end.
Finally, a slightly later version of the UNIX summary appears, dated August, 1975 instead of May, 1975, the date of the one in the V6 sources. It has minor chnages, most noticeably that the last few pages regarding NROFF and TROFF stuff have been split into two sections, one with more NROFF-y stuff and one with more more TROFF-y stuff.
Anywho, nothing earth shattering here, but at the very least, a couple of document variants vs. what is currently on the archive.
- Matt G.
Hello, I'm just emailing to notify that I've managed to split up the CB-UNIX 2.3 manual in the archive[1] into individual items. I've moved the original contents of this directory into the "raw" directory, and now the split PDFs of the manual live under "man". I intend to do the same with the source code scans, breaking them up into individual files, which will eventually go in an accompanying "sys" folder.
As for my process, decided to throw together a little something to facilitate splitting up PDFs from a simple table. I've created two scripts[2], pdfslice and pdfbutcher. The former is an interface on top of Ghostscript to take a particular page-bound slice out of a PDF on stdin and drop it on stdout. The latter then reads a tab-delimited list of slices out of a table, butchering the PDFs down into their various cuts. The format is dirt simple: the source PDF name, the start page, the end page, and the destination file prefix to which .pdf is appended on output. This isn't by any means a formal or robust solution, just something that came together easy and works for my application. I'm sure this could be made much more efficient; it just operates on one slice at a time, including all the opening and closing for each slice, but gets the job done. Feel free to use it for whatever just don't complain to me when it eats your favorite file or scribbles all over your disk. Also, an example input file for the curious is included[3].
As for the CB-UNIX pages, my hunch is that whoever owned this manual had a CB-UNIX 2.1 manual originally and "upgraded" it with supplied pages for 2.3, as was conventional with documentation updates. For this reason, there are a few random blank pages and several locally printed pages strewn throughout. In any case a blank page was encountered, it was retained in the document for the manpage it followed. In other words, if there is a blank page between a.1 and b.1, it is appended to a.1. The likely reason for blank pages on the back of 2.1 pages was that new copies of the same 2.1 pages were provided with the replacements to keep the page spacing correct with respect to the pages not being replaced. That's my hunch anyway.
There are also pages here and there missing a page, or more likely that were supposed to be removed in the 2.1->2.3 update and simply weren't. Plus, there are a few instances of more than one copy of a non-local version of a page present (in other words, situations where the original 2.1 page wasn't removed but a 2.3 or other newer page was also added). In all these circumstances, the 2.1 page is the one with the normal name and the 2.3 page has been affixed .1l instead of .1, despite not being in the "local pages" PDFs. I'm open to suggestions but my reasoning was that if the 2.1 was the original page for that actual binder, and wasn't replaced by 2.3 but rather that was added, then the 2.3 page for all intents and purposes is a local addition. When in doubt, [4] should be a reasonably complete list of which non-l-suffixed pages aren't from 2.1. Anything else non-local should originate from the previous manual. Also, where there were duplicates on pages that otherwise couldn't be solved this way, the older of the two pages is marked with a .o in the path before the manual section, keeping with the CB-UNIX convention of doing this for old versions of pages.
As usual, please let me know if anything seems amiss. I'll admit after a few spot checks I didn't check each and every page my script popped out for accuracy, but everything I've checked had the right pages. If you do find something off and want to try and slice it right, the scripts above include manpages that should give you a good idea on how to use them if simply reading the scripts isn't clear.
- Matt G.
[1] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/
[2] - https://gitlab.com/segaloco/misc/-/tree/master/scripts
[3] - https://pastebin.com/9s2ene9g
[4] - https://pastebin.com/jHw7JeDc
P.S. Wholly unrelated but just out of curiosity, if anyone knows the 16650 UART well and has some time, can you please email me privately? It's tangential to a UNIX-y project but I'll spare the details here.
Good day, something I've come across in my documentation study that I finally got around to researching a bit is a reference to the language Explor in the V2 ld(I) page:
'There are libraries for Fortran (x="f"), C (x="c"), Explor (x="e") and B (x="b").'
The manual has no corresponding mention of any Explor environment, not even a section VI page. The only other UNIX Explor reference I can easily find is on the mailing list here indicating that there is a version of Explor for UNIX on a 1977 tape here (in the 1/explor+dl directory): https://www.tuhs.org/Archive/Applications/Usenix_77/ug091377.tar.gz
Does anyone know if there is continuity here or if the V2 reference and the code on the tape are only related in that they're both for Explor?
- Matt G.
KSOS and related work was sponsored by several DoD activities, at least the
part that I worked on - after 1983.
We've wandered a bit afar for TUHS(?), but, the PWB and other software
wasn't pirated, it was supplied as "government furnished equipment" as part
of each contract.
PWB and other software we got via the NSA's Tycho site, etc. NRL (and then
others) funded later KSOS work, including the Advanced Command and Control
Testbed (ACCAT) and various multi-level secure "Guard" systems, for the
Navy, Air Force, USAFE, etc.
All of which ran on PDP-11s, using the KSOS kernel and userspace, almost
all built by using PWB as the build platform.
On Sat, May 20, 2023 at 12:09 PM Clem Cole <clemc(a)ccc.com> wrote:
> I don't think it was pirated. I'm think it was a special license Ford Aero
> got due to the work with the USG. I sort of remember KSOS and if I'm
> correct that was a DoD funded effort for the Orange Book. So it would make
> absolute sense that Ford Aero might have used the USG connections to
> convince AT&T to release it to them. As I said, Al was very skittish about
> anything that might be misinterpreted by the Justice dept. But if DoD was
> asking for it, Al could show the Jusitce -- "hey -- your people asked for
> it -- we were not selling it."
> ᐧ
>
> On Sat, May 20, 2023 at 3:03 PM Jon Forrest <nobozo(a)gmail.com> wrote:
>
>>
>>
>> On 5/20/2023 11:50 AM, Clem Cole wrote:
>> > Taking this off list.
>> >
>> > I've always wondered about that. Thank you bad word choice -- but it
>> > was not officially released outside the Bell System. Since Ford Aero
>> > had it, it must have been a very special license.
>>
>> It was already there when I arrived so I don't know how it got there.
>> I doubt it was pirated.
>>
>> > Was Ford Aero doing something on a Gvt bid when you were using it?
>>
>> Yes. It was creating KSOS which Tom Ferrine has also mentioned on the
>> TUHS list. This was a "provably" secure version of Unix.
>>
>> You might want to ask John Nagle. His email is probably
>> nagle(a)sitetruth.com, and his GitHub is https://github.com/John-Nagle.
>> He was there when I arrived and he was a key developer of KSOS.
>> If he doesn't know the answer then he might be able to refer you to
>> someone who does.
>>
>> Jon
>>
>>
>>
>>
Hi.
Was any documentation ever done for the basic interpreter
that was on System-V?
Things like allowed keywords or special keywords.
Thanks
Ken
--
WWL 📚 Okey Dokey OK Boss
> From: Matt G.
> there is a "core" file included, I wonder if kernel text is swept up in
> that.
My _guess_ is perhaps not; the disks were really small (the UNIX people
started with an RF11, which the first DEC machine I used - a RSTS system -
also had; that was _really small - 512KB :-).
Probably it did whatever V1 did. I was not up for going to look, since I
wasn't familiar with the V1 code - but then I decided to break down and look
at it, and also create a minimal index to say what's in each module. (Here:
https://gunkies.org/wiki/UNIX_First_Edition#Source_index
if anyone is interested. Made easier because the code is very well commented;
it's very easy to read.)
The code to take core dumps is in u1, at 'badsys:'. It dumps the user's
entire possible memory space (i.e. not just up to the 'break'), and then
(separately) the 'user' area. The system is not included. I doubt V2/V3 are
different.
> ac and mq EAE registers are still in use in s2-bits binaries
Interesting. How did you work that out, BTW? Also, V1 seems to mandate use of
a KE11-A (use is made of it throughout the kernel).
> but have been replaced by s1-bits.
Interesting; how did you work that out? V3's core (V):
http://squoze.net/UNIX/v3man/man5/core
doesn't give the format, just says "The actual format of the information is
complicated because it depends on what hardware is present (EAE,
floating-point option)". Do you have C3's db(I) source? Oh, wait, TUHS has
what claims to be V2's db source:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/cmd/db1.s
but it actually seems to be later; it's conditionalized for having the FPP.
So it must be for a machine running the -11/45 - which we seem to have
decided is V3?
The header for TUHS' V2 says: "The files in cmd/ are recreated from the text
fragments found on the file s1-bits.gz." Which agrees with your take:
> All in all that pegs the s1-bits fragments as being closer in character
> to V3
That's all for the moment...
Noel
> From: Matt G.
> Given the movement of UNIX to the 11/45 and then to C, does the Third
> Edition represent a version of UNIX for the 11/45 with protection but
> written in assembly, not C?
I think so (evidence detailed below). The support may not have been _quite_
identical to that in V4 (e.g. there was no support for pure texts in V3 -
below), though.
> is there any other information such as documents, code, etc. concerning
> the 11/45 assembly version?
This is the real problem, of course; all we have for V3 is some man pages.
(And in relying on them, we have to hope that they were updated to match the
then-current system - which is not guaranteed, but in general at this point
in time, man pages do seem to match whats's in the code.)
> Was work completed on the 11/45 kernel changes in the context of this
> version and then simply "ported" to the C version or were there
> concepts that were cropping up in one or the other and varying amounts
> of transportation back and forth as 11/45 and C aspects were
> implemented?
Without a lot more information, which is now almost certainly lost, we are
unlikely to be able to tell. But let me start by laying out what we _do_ know.
To start with, it's important to realize that support for protection (and
relocation - i.e. memory that looks, to user code, like it's at 0,
is actually at, say, 060000 in physical terms) in PDP-11 UNIX _pre-dates_ the
-11/45. DEC had a rare, and now almost forgotten "Memory Protect & Relocate"
option for the -11/20, the KS11:
https://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option
What exactly it did, and how, is now uncertain (no documentation, or code
that used it, appeats to have survived - all we have are a couple of vague
recollections), but it is certain that that the UNIX group's -11/20 had it:
https://www.bell-labs.com/usr/dmr/www/odd.html
and Ken has said that he wrote the code to use it.
It's also important to remember that not all the machines running UNIX would
have had their hardware updated simultaneously: e.g. the patent group's
-11/20 would not have needed the KS11 as much, since it was runnng mature
applications. So UNIX was probably conditionalized to run with and without
the KS11. As late as V3, there were apparently still UNIX machines without
relocation hardware: "The purpose of this command is to simplify the
preparation of object programs for systems which have no relocation
hardware.":
http://squoze.net/UNIX/v3man/man1/reloc
When the support for the KS11 appeared is uncertain. It's not in the extant
V1 code; but V2 seems to have had it: "the current system, which has
relocation and protection hardware":
http://squoze.net/UNIX/v2man/man5/core
V2 also seems to have started looking forward to the -11/45 - "a trap is
simulated by the floating point simulator" (ditto); "if they correspond to
11/45 floating point instructions":
http://squoze.net/UNIX/v2man/man3/fptrap
It is possible that they already had the -11/45 at this point, but I would
tend to doubt it: "immediate mode ((pc)+) is not supported, since the
PDP-11/45 handbook is not clear on what to do about it." (If they had it, a
simple experiment would have produced the answer.) And "Double precision
results are probably less correct than the hardware will be" (note tense).
(All from v2man/man3/fptrap.)
V3 seems to have the -11/45: "it depends on what hardware is present (EAE,
floating-point option)":
http://squoze.net/UNIX/v3man/man5/core
The "floating-point option" would only have been on the -11/45. (And again we
see that V3 still ran on -11/20's; the -11/45 would not have had an EAE:
https://gunkies.org/wiki/KE11-A_Extended_Arithmetic_Element
since all the EAE operations - except normalization, but that's only needed
for floating-point - were in the basic -11/45.)
Probably the protection and relocation provided to UNIX processes on the
11/45 was very similar to that provided with the KS11. Do note that thememory
management was not exactly the same as V4's: "In the future the text segment
will be write-protected and shared.":
http://squoze.net/UNIX/v3man/man5/a.out
However, it was keeping multiple processes in main memory at the same time:
"only processes whose core images are on disk have visible names":
http://squoze.net/UNIX/v3man/man8/ps
So we can actually tell a fair amount about the evolution through V2 and V3
from the few scraps that are left to us. I do live in hope that a V2 or V3
listing will turn up one day; the system changed a lot in that period, and
many questions aren't answered definitively by the man pages.
(One big one is details of how the process' address space was laid out -
ld(III) and exec(II) simply say nothing at all. I assume it started at 0 -
but who knows? In V1, it must have started at a higher address - as on
MINI-UNIX:
https://gunkies.org/wiki/MINI-UNIX#Implementation_details
which I am fairly familiar with - but again, neither V1's ld(III) or exec(II)
mentions this detail. I suppose I could work it out from the V1 source, but
I'm not _that_ interested... :-))
It is possible that the evolution started with just protection (if the KS11
could do that), and relocation was added later. It seems clear that the
step from the KS11 to the -11/45 was probably not large.
If anyone has a V2 or V3 listing, please sing up! That would be an
_incredibly_ valuable thing to add to the historical record.
Noel
