Hi folks,
A few months ago I reported on my efforts to reconstruct London &
Reiser's paper on their port of Unix to the VAX-11/780.[1]
I formerly characterized this as "the UNIX/32V port", but since London
& Reiser's paper predates the release of Seventh Edition Unix by about
six months, UNIX/32V came _after_ Seventh Edition by about the same
number of months, and the pace of Unix development was particularly
ferocious in this period[2], I felt that my identification of London &
Reiser's work with UNIX/32V may have been hasty. I also may have
overinterpreted Dennis Ritchie's words on the subject.
"Tom London and John Reiser, working from the 7th Edition and the
Interdata 8/32 system, generated a VAX 11/780 version of the system,
which, in its distribution format, would be called 32V."
That phrase "in its distribution format" could cover a variety of
changes, some of which perhaps did not match London & Reiser's
intentions or views expressed in their paper. More conservative
implications seemed prudent.
I'd thus like to present what I consider to be my "final" draft, subject
of course to feedback from these mailing lists. I'm pleased to report
that I've addressed all of the XXX points I identified in the source of
my first draft, points where I felt groff mm could be enhanced to aid
the rendering of historical documents like this. I consequently expect
groff 1.24's mm package to support several new features prompted
specifically by this work. Quoting the forthcoming NEWS file...
* The m (mm) macro package now supports a user-definable hook macro
`AFX`, which if defined is called by `AF` in lieu of the latter's
normal operation. Applications include customization of letterhead.
* The m (mm) macro package now supports a user-definable hook macro
`RPX`, which if defined is called by `RP` to format the reference
list caption string `Rp` instead of the default formatting.
* The m (mm) macro package now supports an `Aumt` string to suppress
the appearance of positional arguments to the `AU` macro in the
document heading used by memorandum types 0-3 and 6. By default, all
such arguments appear, except the second (author initials). For
example, a value of "3 4" more accurately reproduces London &
Reiser's 1978 paper describing the porting of Unix to the VAX-11/780.
* The m (mm) macro package now supports an `Rpfmt` string specifying
the `LB` macro arguments that the package uses to format the items in
a reference list.
* The m (mm) macro package no longer superscripts _and_ brackets a
reference mark (the `Rf` string). Instead, the new `Rfstyle`
register controls its formatting. The default, 0, selects bracketing
in nroff mode and superscripting in troff mode. Set `Rfstyle` to 3
in a document to obtain groff mm's previous mark formatting behavior.
[I might still update or revert the changed default; I want to
research the behavior of historical mm implementations.]
The "32vscan.pdf" document from which I prepared this reconstruction is
available at Dennis Ritchie's memorial home page.[3] I have attached
the reconstructed mm source document and two PDFs, rendered with groff
1.23.0 (the current stable release), and groff Git HEAD (exercising the
new features listed above).[4]
I offer the caveat that these cannot be pixel-perfect recreations
because (1) I have no information about the precise paper dimensions or
margins London & Reiser used[5]; (2) the fonts employed in rendering the
documents are not identical, metrically or otherwise; and (3) AT&T and
GNU troffs use different hyphenation systems and therefore sometimes
break words differently. These factors all impact the placement of line
and page breaks, and these are avowedly and clearly distinguishable.
There are furthermore a few discrepancies that I decided weren't worth
the trouble at this time to reconcile, like selective encroachment of
cover sheet material beyond the page margins. None affect the utility
of the document (in my opinion).
With that large disclaimer in place, I welcome feedback on the quality
of the reproduction.
Finally, I reiterate my encouragement that the document be _read_. In
my opinion, the final two sections "Commands" and "Software portability"
are well worth consideration in hindsight. To the extent that we
continue to boast, sometimes glibly, of C as a "portable assembly
language", be it in its current ISO C23 incarnation; as ANSI C89, the
last revision blessed by Ritchie; or in the form used when London and
Reiser wrote, their experiences and recommendations laid out a program
of better delivering on that promise.
Regards,
Branden
[1] https://www.tuhs.org/pipermail/tuhs/2024-June/030041.html
[2] 1980, for example, saw releases of 3BSD, System III, PWB/UNIX 2.0,
and 4BSD.
[3] https://www.bell-labs.com/usr/dmr/www/portpapers.html
[4] You may notice a difference in the sizes of the two PDFs, surprising
in light of their shared source document. This is thanks to a new
feature forthcoming in Deri James's gropdf(1) output driver: font
subsetting.
[5] ...or where, if anywhere, the authors "cheated" the margins
temporarily, for instance with `ll` or `pl` requests. Even with mm
macro package sources available, such things would be invisible to
the reconstructor.
Folks:
Long story short, I have a unpublished manuscript that a faculty member in my department wrote late 1980's early 2000's. He did the entire thing in troff, eqn, and pic.
The faculty member is still alive. A publisher is interested in the manuscript. I have all of the source files on an old unix machine that still has troff, eqn and pic. It also has groff. This issue is that the pic commands are bracketed by .G1 and .G2 not .PS & .PE. The original machine he would have used would have ran AT&T Sys V on an AT&T 3B20. Below is one of the files. Any thoughts on the .G1 .G2? I can get the files that have only eqn and troff to create postscript, but the .G1/.G2 is not understood by pic. I tried replacing the .G1/.G2 with .PS/PE and it failed. I must be missing another program that uses the .G1/2
Thanks
.sp -3.5
.fp 1 Z
.fp 2 XI
.ps 11
.tl ' ' '1-10'
.EQ
delim $$
gsize 11
.EN
.po 0.9i
.vs 15
.G1
frame wid 5.7 ht 6.0 invis
coord x 0.2, 100 y -40, +22 log x
grid left from -30 to +20 by 10 ""
grid left from -40.04 to +19.96 by 10 ""
grid left from -39.96 to +20.04 by 10 ""
grid left from -39 to +22 by 1 ""
grid bot from 0.4 to 40 by *10 ""
grid bot from 1 to 100 by *10 ""
grid bot from 0.2 to 20 by *10 ""
grid bot from 0.3 to 30 by *10 ""
grid bot from 0.5 to 50 by *10 ""
grid bot from 0.6 to 60 by *10 ""
grid bot from 0.7 to 70 by *10 ""
grid bot from 0.8 to 80 by *10 ""
grid bot from 0.9 to 90 by *10 ""
ticks out left from -40 to +20 by 10
ticks out bot from 0.2 to 20 by *10
ticks out bot from 0.4 to 40 by *10
ticks out bot from 1 to 100 by *10
draw solid
0.2 19.93
2 19.93
10 5.97
100 -34.02
new solid
0.2 20.07
2 20.07
10 6.05
100 -33.95
new dotted
for i=0.45 to 23 by *1.05 do
{
w=i*i
f=200/sqrt(w*w+104*w+400)
next at i,20*log(f)
}
label left "\u\udB \d\d"
label bot "\(*w, rad/s"
.G2
.in 2
Fig. 1.4. Graph of the magnitude in dB of $H(s)~=~200 over{s sup 2~+~12^s~+~20}^,$$~s~=~j^omega$.
Doug Jacobson
University Professor, Dept. Electrical & Computer Engineering
Sunil & Sujata Gaitonde Professorship in Cybersecurity
Director: ISU Center for Cybersecurity Innovation and Outreach
Mail Address: 2520 Osborn Dr, 2215 Coover Hall
Iowa State University
PH: (515) 294-8307 Fax (515) 294-8432
Office: 371 Durham Hall
Center web site: http://www.cyio.iastate.edu/<https://urldefense.com/v3/__http:/www.cyio.iastate.edu/__;!!DZ3fjg!oVZir7OL…>
Personal web site: http://www.dougj.net<https://urldefense.com/v3/__http:/www.dougj.net/__;!!DZ3fjg!oVZir7OL4VMZHCY…>
> lilian worked at bell labs in the 80s (and maybe 90s)
> around tech and films and suchlike.
Lillian was a real pioneer. She began collaborating at the Labs in the mid
1960s.
Doug
Hi All.
I'm working on revising my book on basic *nix programming, and for
the new chapter on sockets, I want to include some code from 4.2 BSD.
Is there a copyright file somewhere for that code? I'm sure it's
copyright the Regents of the University of California, but I'd like
to include the text of the copyright in the book, so that everything's
clear.
Thanks!
Arnold
Hello All,
I took a picture of my V8 and V9 manuals the other day. It's available
at https://www.skeeve.com/V8-V9-Covers.jpg.
@segaloco: This one's for you. :-)
Enjoy,
Arnold
Unix folk were barely involved in the branding or advertising of the
system. I recall that we got to proofread and edit the first Unix ad, but
essentially nothing later. Nor did we contribute to the cover designs of
the 7th edition trade verson or the 8th-10th in-house versions of the
manual.
Doug
So in the course of AT&T's involvement with UNIX, a number of different images and motifs have graced advertisements and covers of literature, among them:
- Letter Blocks (V7 HRW manuals, Release 4.0 Starter Packages)
- Criss-crossing grid lines on a black background (Release 5.0/SVR1)
- Variations on an image of earth with UNIX superimposed (SVR3/SVR4)
- Covers mirroring publication motifs of other AT&T products and literature (SVR2/SVR3)
Did the folks actually involved in the production of UNIX have any influence on the choice of design motifs for such materials, or would those sorts of decisions have been largely in the hands of marketing folks several layers removed from the Labs?
My understanding is that this sort of visual branding started in the early 80s, with the earliest example of a printed piece of UNIX literature outside of generic Bell Laboratories covers I'm aware of being the "Starter Package" documents featuring UNIX spelled out on four letter blocks in primary colors. Everything I've seen branded predating these 1981 publications is either 8.5/11 pages in a Bell Labs or Western Electric report cover or the form factor of the Release 3.0 manual using generic Bell Labs covers. I'm certainly intrigued if anyone has any recollection of any sort of visual motifs in play prior to 1981.
- Matt G.
The titled post reminds me of Ted Dolotta, a guru of PWB Unix, whose eye
for editorial detail was unsurpassed. He could spot the difference between
italic and roman periods at twenty paces. Bjarni is in good company.
Doug
> C's refusal to specify dynamic memory allocation in the language runtime
> (as opposed to, eventually, the standard library)
This complaint overlooks one tenet of C: every operation in what you
call "language runtime" takes O(1) time. Dynamic memory allocation
is not such an operation.
Your hobbyhorse awakened one of mine.
malloc was in v7, before the C standard was written. The standard
spinelessly buckled to allow malloc(0) to return 0, as some
implementations gratuitously did. I can't imagine that any program
ever actually wanted the feature. Now it's one more undefined
behavior that lurks in thousands of programs.
There are two arguments for malloc(0), Most importantly, it caters for
a limiting case for aggregates generated at runtime--an instance of
Kernighan's Law, "Do nothing gracefully". It also provides a way to
create a distinctive pointer to impart some meta-information, e.g.
"TBD" or "end of subgroup", distinct from the null pointer, which
merely denotes absence.
Doug
Someone on the TUHS list mailed me privately, prompting me to
write this lengthy apology (in the classical sense) of why groff doesn't
make a certain application easier. I have slightly revised my response.
This message also may serve as a summary of the challenges that need to
be overcome if someone else wants to tackle the job, and potentially
contribute it to groff.
[person creates PDFs of historical Unix documents (many of which are
written using the ms macros) and wishes groff ms made the task easier]
I sympathize. I sometimes render historical documents, so I prescribed
in groff ms's documentation the approach that I take myself. I decided
against trying to support a "-matt" or "-msatt" option in groff because
it's flatly impossible to know which definition of `UX` to use. Even a
date declaration in the document sheds little light, as we then have to
consider the question of whether we want fidelity to the actual state of
the mark at the time of that declared date, or to what would have been
rendered in the author's environment--and they may have been using an ms
that wasn't "up to date" in the same respect. That information, too, is
not recorded in the document.[1]
Providing all the macros _except_ `UX` didn't seem likely to satisfy
users since that's the most important one! It shows up in body text
whereas all the others seldom do--if you can live without the cover page
then, often, you're golden. Except for `UX`.
Finally there is the name collision problem with Berkeley. 4.2BSD and
later ms defined `CT` and `TM` macros (aspects of their "thesis mode")
and once again there's no declarator within the document to tell you
which dialect of ms is in use. This one can be heuristically figured
out with pretty good odds, I suspect, but troff works as a filter--what
was I going to do, write a preprocessor just for this?
(Hmm, maybe grog(1) could do it, and that would be in its wheelhouse.
But there's no point until and unless we reimplement support for
Berkeley thesis mode in the first place [so that grog has an option
argument to report], and that is an undertaking I have demurred.[2])
It seemed like a moderate amount of work for almost zero upside. It's
also hard to validate/verify my work. The only historical troffs to
which I have access are Seventh Edition Unix troff (1979, before
Kernighan) and DWB 3.3 (early 1990s). It's a right pain in the butt to
inspect typesetter output on V7 because I have nothing that emulates a
C/A/T or translates it to device-independent troff output for a
"ditroff"-style device description that Kernighan troff, DWB/Hierloom
Doctools troff, or GNU troff could use.
And even if I had either of those, they'd have to be vetted to a _high_
degree of quality before they'd be fit for purpose; else I wouldn't know
whether I was chasing bugs in the groff ms macros or the C/A/T
emulator/translator.
So, to summarize, I confine my compatibility efforts to _nroff_ output,
and rule the Bell Labs "site" macros out of scope. I feel there is not
much more I can do, and have confidence my results, without resources
that I'm lacking.
I hope this sheds some light on my reasoning.
Regards,
Branden
[1] Still, if someone wants to start, I'd start here.
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/vol2/ms/tmac.s
[2] One person, ever, has requested it, 20 years ago. And I have no
specimens of input or corresponding model output rendered by an
"authentic" BSD troff [formatter executable PLUS support files]
against which to develop a reconstruction. (On the bright side, the
Berkeley modifications to the once-encumbered AT&T "tmac.s" are, of
themselves, presumably BSD-licensed.)
https://savannah.gnu.org/bugs/?64455
All, I got this e-mail and thought many of you would appreciate the link.
Cheers, Warren
----- Forwarded message from Poul-Henning Kamp -----
I stumbled over this:
https://www.telecomarchive.com/lettermemo.html
is the TUHS crew aware of that resource ?
----- End forwarded message -----
I'm wondering if there are places where people who were in the Unix
Room wrote about the origins and evolution of what people (at least
used to(*)) refer to as "Unix Philosophy", and since some are in THIS
(TUHS) room, what they might have to say about it.
How much was in reaction to the complexity of Multics, and how much
was simply a response to the limited address spaces of
available and affordable hardware?
Eric S. Raymond wrote in "The Art of Unix Programming" quoting
Doug McIlroy and Rob Pike:
http://www.catb.org/esr/writings/taoup/html/ch01s06.html
And I wonder if they care to comment on it?
I have trouble taking ESR as authoritative, as, it seems to me that
Research Unix was more a product of the "Cathedral" (or at least a
contained community) than the "Bazaar" (at least the modern bazaar,
where everyone needs to leave a new feature grafito on the town
walls), and ESR
A side question for Rob Pike, is the "Not only is UNIX dead, it's
starting to smell really bad." quote accurate? Was it in reaction to
BSD, GNU, or all of the above?
(*) I say "used to", because, for the most part, minimalism seems to
have left the building. I can't look at modern GNU utilities, and
many, if not most open source packages and think they've gone WAY past
classic Unix minimalism, especially since I remember hearing that Bell
Research had happily stripped excess features (removal of "cat -s"
sticks in my mind) from later day research Unix, and because Stallman
is said to have coined the term "New Jersey" style as a synonym for
what Richard P. Gabriel called "Worse is Better", which seems, an
attack on minimalism (nothing less than "the right thing" is acceptable)
Worse is.... readings:
https://dreamsongs.com/WorseIsBetter.htmlhttps://dreamsongs.com/RiseOfWorseIsBetter.htmlhttps://dreamsongs.com/Files/IsWorseReallyBetter.pdfhttps://dreamsongs.com/Files/worse-is-worse.pdf
Anti-flamage disclainmers:
Inclusion of links above does not imply any agreement on my part! My
apologies in advance for any offense, misquote, or misunderstanding on
my part.
> From: Rik Farrow <rik(a)rikfarrow.com>
> Was the brevity typical of Unix command names a function of the tiny
> disk and memory available? Or more a function of having a Teletype 33
> for input?
I'm not sure the answer was ever written down (e.g. in a memo); we will
probably have to rely on memory - and memories that far back are now fairly
thin on the ground by now. Perhaps Mr. McIlroy (or Mr. Thompson, if we're
_really_ lucky) will humor us? :-)
I have the impression that some of the names are _possibly_ inherited from
Multics (which the early Unicians all used before Unix existed) - but maybe
not. The command to list a directory, on Multics, is 'ls' (but see below) -
but the Multics qcommand to remove a file is 'del' (not 'rm'); and change working
directory is 'cwd'. So maybe ls' is just chance?
Multics had a 'feature' where a segment (file) could have additional names (to
the main name), and this is used to add short aliases to many commands, so the
'base name'' for the directory list command is 'list'; 'ls' is a short
alias. A list of Multics commands (with short forms) is available here:
https://www.multicians.org/multics-commands.html
I'm not sure how early that alias mechanism came in, though; my copy of
"Introduction to Multics" (February, 1974) doesn't have short names (or, at
least, it doesn't use them).
It won't have anything to do with disk and memory. Having used a Teletype, it
would take noticeably longer to type in a longer name! It's also more effort
and time. I would expect those are the reasons for the short names.
Noel
> I wonder what happened to the amazing library at Murray Hill.
Last I knew, the Bell Labs archives were intact under supervision of a
professional archivist. Formally speaking, the archives and the library
were distinct entities. The library, which was open to self service 24
hours a day, declined rapidly after the bean counters decreed that it
should henceforth support itself on rental fees. Departments immediately
turned to buying books rather than borrowing them. It's very likely that
this was bad for the Labs' bottom line, but the cost (both monetary and
intellectual) was not visible as a budgetary line item.
The 24-hour library contributed to one of Ken's programming feats. Spurred
by a lunchtime remark that it would be nice to have a unit-conversion
program, Ken announced units(1) the next morning. Right from the start, the
program knew more than 200 units, thanks to a book Ken grabbed from the
library in the middle of the night.
Doug
> That CSTR number 1 is nicely formatted, is that troff?
The archive's CSTR 1 is ersatz. It's a 1973 journal article obtained from
JSTOR. I imagine the manuscript was largely copied from the CSTR, but the
printed paper certainly differs in meta-content and in layout, say nothing
of font. Having gone through the usual route of journal submission and
revision, the body text is probably not word-for-word identical to the CSTR
either.
Doug
Clem Cole:
Interesting -- 'Jason' had always been a Pascal hacker when the strip was
first created. As I recall, Berkeley Breathed had Wendell (his hacker
character) comment on that during the time of Pascal/C Wars.
====
But Jason later was revealed to be wearing Unix underpants:
https://www.gocomics.com/foxtrot/2002/02/25
Norman Wilson
Toronto ON
Hello everyone, I've found myself in the exceptionally fortunate circumstance of securing ownership of a MAC-TUTOR BELLMAC-8 SBC unit. It is still in shipment so I can't assess its operation yet, but I was wondering if anyone is aware of any surviving assemblers, linkers, etc. for this architecture? If not, I'm prepared to roll my own based on available documentation, but figured I'd ask to see if there's anything I can start with. From what I can tell, the main development environment was PWB, specifically the Bell System internal varieties, with the BTL edition of Release 5.0 literature describing things like m8as(1), m8cc(1), etc. as Division 452 Computer Center standard commands.
There is a bit of information here as well: http://ferretronix.com/march/sbc/mactutor/
Thanks for any tips! Regardless of how much I can manage to do with it, I'll be sure to get some good pictures and take some notes on what I am able to figure out with the thing. I presume the Gunkies wiki would be a good place to document that sort of thing?
- Matt G.
P.S. Pardon if this belongs on COFF, I figured since UNIX was the canonical development system and it is also a Bell Labs thing, I'd ask here first.
I noticed there are kexec talks this year at Linux Plumbers. Kexec, kernel
boots kernel, has had a 25 year gestation in Linux, but it looks like it's
finally coming together, driven by need.
Thereby hangs a tale.
in 1977, I was working at udel with Ed Szurkowski, the first sysadmin of
the Unix systems we got in 1976 (first machine was an 11/70). Ed was a
gifted engineer and did all kinds of neat work on v6. He later went to the
Labs once he got his PhD and I lost track of him.
Ed got tired of watching the bootstrap slowness, and wrote a system call
that did the following:
1. load kernel in memory from system call argument
2. put special signature in low memory telling bootstrap "look in memory"
3. reboot via reset.
Now, this works, because back then, ROM boot code did not zero memory.
Memory was unchanged across reset. So the bootstrap could find the magic
bits and start the kernel.
I've lost the code, I carried the listings for decades but finally dumped
them. A shame.
But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or
was there something before?
> The array size} limit that I found through trial and error is (2^15)-1.
> Declaring an array that is [larger] results in an error of "Constant
required",
On its face, it states that anything bigger cannot be an integer constant,
which is reasonable because that's the largest (signed) integer value. Does
that version of C support unsigned constants?
Doug
It's a bit off-topic but Warren OK'd it: I'm trying to tidy the absolute
dragon's hoard I call an office, so I'm looking to give away some books
I haven't touched in years. These are free for the taking for anybody
who wants to drive to SF and get them. I'd really prefer for somebody to
take them all at once, of course.
- DEC PDP11/70 Processor Handbook
- DEC VAX11 Architecture Handbook
- DEC PDP11 Peripherals and Interfacing Handbook
- DEC Introduction to Programming (PDP-8)
- Programming Languages: History and Fundamentals (Sammet)
- Computer Networks, 1st ed (Tanenbaum)
- Modern Operating Systems, 2nd ed (Tanenbaum)
- Operating Systems Design and Implementation, 1st ed (Tanenbaum)
- Advanced Programming in the UNIX Environment (Stevens)
- Computer Architecture and Organization, 2nd ed (Hayes)
- Compilers: Principles, Techniques, and Tools (Aho, Sethi, Ullman)
- The Undocumented PC, 2nd ed (van Gilluwe)
- Cybernetics (Wiener)
If you want these, please email me *off-list* to set it up.
John
> From: Ron Minnich
> Ed got tired of watching the bootstrap slowness
This may be a dumb question (in which case, my apologies), but which part of
booting a PDP-11 UNIX was slow? And thus, which parts did he bypass in a
'quick reboot'? (I'm having a bit of a hard time working it out.) I can think
of the following stages as potentially being 'slow':
1 - reading in the kernel image from disk
2 - sizing/clearing main memory
3 - loading running /etc/init
3A - creating all the 'loqin's
3B - starting all the daemons/etc with /etc/rc
(There's obviously a conflict between 2 and 3*; one can't avoid 3* if one
does 2.)
Which ones did he want to avoid?
Avoiding 3* puts some limitations on the system, obviously, because it means
one has to keep running processes around; the process table has to have the
same format (and be in the same location - or it has to be moved before the
new system is started). (Technically, I guess one would have to save the
inode and file tables, too; there isn't enough saved data in the kernel to
re-open files, plus there are file read/write ocation pointers, etc.)
One could sort of do 2 also, if one were prepared to 1) swap all processes
out to secondary storage before 'rebooting', and ii) saving the process table.
> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel"
> or was there something before?
Are you talking about for UNIX, or across all operating systems? I don't have
that broad a memory any more, to know - did TWENEX have something like that?
Noel