Rather an aside, but the alt.sysadmin.recovery message referenced
in https://www.tuhs.org/pipermail/tuhs/1999-November/001203.html
chimes interesting chords for me.
If you care only about technical stuff, you should skip to
your next e-mail message now.
On one hand, the doubly-embedded net.unix-wizards message
from Dennis, dated 1984-12-08, containing the original dsw.s:
that was posted a few months after I joined Bell Labs, and
may even have been partly my fault. 1984 was the nominal
15th anniversary of UNIX; as a member of the steering committee
of the recently-formed UNIX* Special Interest Group in US DECUS,
I convinced Dennis to attend the Fall 1984 Symposium, in Anaheim
in early December, as part of a celebration. As another part, I
made copies of the V1-V7 manuals in the UNIX Room and had them
shipped out so people could leaf through the history. I think
Dennis dug out the PDP-7 source-code books as a contribution to
that effort; I am all but certain we brought copies of those too.
Of course I had the copies returned not to the Labs but to my
home address. I still have them, now on a shelf in my home office.
A good friend offered to take care of shipping them back to New
Jersey, of course making her own copies in return.
I also recall that the conference hotel happened to give me
room 127. I offered to swap with Dennis, since he deserved
that number more than I did (the extra digit had already been
prepended before I joined) but he cheerfully declined.
On the other hand--not as historic except to me--the author
of the singly-embedded 1999-11-23 alt.sysadmin.recovery message
is now (and has for some years been) a co-worker and a good
friend.
So this single 1999 TUHS posting touches points near both
the beginning and the end (so far) of my career, and two
different groups of smart people who are fun to work with.
Norman Wilson
Toronto ON
While performing my CB-UNIX 2.3 manual separation, among the many curious things I came across was this manual page: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man1/dsw.1l.pdf
The dsw(I) pages I've seen in the various UNIX manuals are all for the interactive delete utility, but make brief mention of the history of the command being amusing. I've seen some communication on the matter of the years here, but had never come across a manual page for the former version of dsw.
In the linked page up there is the actual "delete from switches" version of dsw. What I find particularly interesting is that the footer indicates this was printed 8/11/81, but likewise indicates the command is "PDP-7 local".
This raises a couple of questions:
- Did Columbus ever touch PDP-7 UNIX?
- Did dsw(I) as "delete from switches" ever make it to PDP-11 UNIX? Even the V1 manual lists the "delete interactively" utility, not this.
- If neither are true, that begs the question of where this page came from, if there was ever a formalized PDP-7 manual that it would've descended from or not, etc.
Finally, this page plainly spells out the history of the command in the bugs section:
"This command was written in 2 minutes to delete a particular file that managed to get an 0200 bit in its name. It should work by printing the name of each file in a specified directory and requestion a 'y' or 'n' answer. Better, it should be an option of rm(1). The name is mnemonic, but likely to cause trouble in the future."
So the first bug is eventually mitigated by transforming this into the more familiar dsw. I can't say what the latter means, whether it's a concern of "dsw" colliding with some reserved word eventually or is more poking fun at the other folk etymology of "delete s__t work".
In any case, I hadn't seen the etymology explained to this degree in the mailing list references I found while searching around, so figured I'd share this analysis.
- Matt G.
P.S. There is mention here that Dennis Ritchie shared the original dsw manpage at some point https://www.tuhs.org/pipermail/tuhs/1999-November/001203.html however the link in question appears to be dead. In any case, the source for the PDP-7 version is in that email if anyone wants to look at it, although looks to be the same as what is in the archive.
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
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.
