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
Hello, I've just today secured purchase of an original 4BSD manual and papers set and a copy of what I believe is the V6 papers set as well. Of note amongst the tabs I could read from the pictures of the Berkeley binder was a section of fonts that I don't think I've seen before named the Berkeley Font Catalog. I did a bit of searching around and didn't find anything matching that on first inspection re: scanned and source-available BSD doc collections. Anyone got the scoop on this?
Either way, once these arrive in the mail in I'll try and see what the delta might be between these and the current sources in V6 and 4BSD stuff on the archive. They're from the collection of an emeritus professor on the east coast, and I'm not sure if they represent unmodified docs shipped from Bell and Berkeley or have local modifications. In any case, his son said they'll be going through more material soon and are liable to turn up more UNIX stuff, so I'll keep folks posted if I come into possession of anything else particularly spiffy.
- Matt G.
for some reason, i have a copy of
“computer programming and autocodes”
by
burnett-hall, dresel and samet (1964).
it covers pegasus-sirius autocode, elliot 803 autocode,
mercury autocode and algol.
it is a hardcover duplicate from the library of congress.
anyone want this?
otherwise, it gets recycled thru my local library.
I've just completed the Fourth Edition pass of commits in my manual history repository here: https://gitlab.com/segaloco/mandiff
Something I've kept a particular eye on is what the landscape looked like on the filesystems over the early years of development. Here are some of those observations with a few areas perhaps requiring further illumination:
In the first two editions, there was a file, /etc/uids, which mapped simply a username to a uid. The reason was presumably due to the plaintext passwords in /etc/passwd at the time. The arrival of crypt(III) and related functionality rendered this moot by the time of V3. Additional GECOS information is first spotted in /etc/ident in V2 but by V3 has also found home in /etc/passwd in the GECOS field today used often for a user's full name. The s1-bits source codes refer to /etc/passwd where disassembled s2-bits binaries refer to /etc/uids still, dating both sets of code.
References to /etc/motd first appear in the V2 manual from what I could find, so that may not have been around in V1. Additionally, after V1 many files are moved from /etc to locations under /usr such as ascii and kbd moving to /usr/pub and roff's suftab moving to /usr/lib. It seems in the First Edition, manual section VII mapped to /etc itself it seems, with etc and misc in the manual being synonymous.
So all in all it seems, in terms of support files anyhow, /etc wound up smaller by the advent of the C system, at which point init beings using /etc/rc and the directory begins to expand again.
Another directory of interest is /sys for a few reasons. First, this directory serves different purposes depending on your kernel these days, with BSD systems storing system source code here whereas Linux provides a kernel interface filesystem. I'm not sure what other contemporary systems may use this for, but from V3 and back, this was another RK disk mounted in addition to /usr. This /sys directory appeared to contain the manuals, source code to system components including the commands, kernel, bootloader, and languages, and a copy of the kernel image referenced down in the source tree.
In total I've identified the following directories: c, fort, lang, man, mdec, source, sys. Most names should be obvious from later releases, with lang being a parent directory that contained bdir and mdir B and m6 languages respectively. My guess is that when RP support was made workable in V4, there was no longer a need to segregate data amongst RKs like this so /sys was merged into /usr, leading to the later structure we see in V4-V6. Of note, this structure is implied in CB-UNIX still in the path names of the source code available on the archive. The kernel is found at /tsys/sys/ much like the kernel in V1-V3 living at /sys/sys.
One thing I haven't been able to glean in the process is precisely how the command and library source code was stored in these very early versions. The kernel in T.R. Bashkow's analysis is implied to be stored in files u[0-9x].s, and command source files at least exist somewhere as the command followed by .s. As of V5, the command, syscall wrapper, and library source codes are split up amongst a number of directories with names such as s1, s2, s3, etc. under source. By V7, this has taken on the cmd/lib/sys structure of later releases.
Finally, just a general curiosity the version study involved has raised. 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've seen one handwritten document that makes mention of some of this, but is there any other information such as documents, code, etc. concerning the 11/45 assembly version? 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?
As always, thanks for keeping up, hopefully I can get this repository up to V6 soon, then the real branching fun begins. The V3 to V4 changes are hopefully the last time the commit diffs have major noise, what with the conversion from roff to nroff. I suspect transitions to macro packages later won't be as bad.
- Matt G.
Howdy folks, I was perusing old copies of ;login: and came across a note about the BSTJ UNIX issue in the August 1978 newsletter: https://archive.org/details/login_august-1978
What I find particularly amusing is that all UNIX licensees at the time of that publication allegedly were provided a copy free of charge. The text goes on to indicate additional copies can be purchased for a measly $1.50.
Fast forward to today and I typically don't see this copy pop up on auction for less than $100. Still, amazing how something was being just tossed out to anyone who wanted one and now here 45 years later, it's a mad scramble to find the same. Then there's this listing: https://www.ebay.com/itm/134212722284?hash=item1f3fb39e6c:g:9VEAAOSw8HtjCp2…
$3000 dollars...quite shocking, although perhaps they're banking on the uniqueness of that little sleeve, I've never seen one of those with a BSTJ issue before. Was that some sort of packaging the issues were delivered in? It has the Bell Logo in the little window on either side, so I want to believe it's original and not something someone threw together after the fact.
In any case, I suspect part of the low pricing is due to Bell anti-trust stuff, as they really moved on nickle and diming on documentation once they were legally able to. In any case, I'm always shocked to see how much I paid for something in my archival efforts and then I find a price sheet only to find out someone bought a book back in the day for the cost of a burger and fries. While I'm pursuing documents for research purposes...I may be inadvertently building myself quite the value store without even meaning to...
- Matt G.
