I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
This is really gonna stretch the memories. (I may have even asked about
it on this list before.)
At one of the earlier USENIX conferences that I attended, maybe in
Atlanta, there was a contest to make up humorous new errno values.
The one that won, which I remember to this day was:
A host is a host from coast to coast,
and no-one can talk to host that's close,
unless the host that isn't close
is busy, hung, or dead.
I have quoted this is the gawk doc for many years.
I'm wondering if there is a way to find out who was the author
of this gem? I'd like to give him/her credit.
> From: arnold(a)skeeve.com
> it was clear at the time that UNIX and what was happening was extremely
> special .. Those of you who were there really were part of a "golden
I once observed to Jerry Saltzer that when I started at the MIT CS labs, I
had been bummed because I had missed what I considered their 'Golden Age' -
the work on CTSS and Multics.
When I showed up there, I did a deal where they let me use a PDP-11/40 to
explore some OS ideas I had, if I woule write diagnostics on it for a ring
interface they were working on - part of a project on networking that
included work on something called internetworking.
I had no idea what I was getting into!
And of course the networking work soon sucked me in completely. In that
message to Jerry, I said something to the effect of 'clearly I've lived
through a second golden age, and only now am I understanding that'.
Eric S. Raymond has written an article about the history of the time.h
functions at http://www.catb.org/esr/time-programming/
>From his blog post announcing it (http://esr.ibiblio.org/?p=6311):
> The C/UNIX library support for time and calendar programming is a nasty mess of historical contingency. I have grown tired of having to re-learn its quirks every time I’ve had to deal with it, so I’m doing something about that.
> Announcing Time, Clock, and Calendar Programming In C, a document which attempts to chart the historical clutter (so you can ignore it once you know why it’s there) and explain the mysteries.
> What I’ve released is an 0.9 beta version. My hope is that it will rapidly attract some thoroughgoing reviews so I can release a 1.0 in a week or so. More than that, I would welcome a subject matter expert as a collaborator.
When I saw it I thought it might be generally interesting to people who
subscribe to this list.
> From: Doug McIlroy <doug(a)cs.dartmouth.edu>
> Sorry for straying from direct Unix history
Au contraire. This was a fascinating account, and very valuable to have it
noted down for history. Please stray like that anytime you feel like it! :-)
> There was a compiler/compiler in use at the Labs, imported I think by Doug
> McIlroy, called TMG.
Sorry for straying from direct Unix history, but this remark spurred a lot
TMG (from "transmogrify", defined in Webster as "to change or alter, often
with grotesque or humorous effect") was imported from Bob McClure, erstwhile
Bell Labs person, then at Texas Instruments. And an interesting import
job it was. McClure had written TMG for the CDC 1604 in machine language. He
sent me green coding sheets hand-transliterated into 7090 code. Interesting
debugging: one knew that the logic of the code was sound, but the opcodes
might not always be right. Sometimes, for example, the wrong one of the two
accumulator-load instructions, CLA and CAL, was used.
Clem Pease converted TMG to the GE 635 for Multics by the artifice of defining
7090 opcodes as 635 macros--sometimes many instructions long to slavishly
emulate the 7090's peculiar accumulator (which mixed 38-bit sign-magnitude
with 37-bit twos-complement and 36-bit ones-complement arithmetic). It's
amusing to speculate about the progressive inflation of TMG had McClure sent
me a similar translation for the 7090.
TMG had a higher-level language written in TMG, which evolved during the
Multics project into something considerably more elaborate than McClure's
original, including features like syntax functions, e.g. seplist(a,b) denoted
a sequence of a's separated by b's, for arbitary syntactic categories a and
b. Syntax functions took TMG beyond the domain of context-free languages.
Multics was to be written in PL/I, a compiler for which was commissioned from
Digitek. They had brilliant Fortran technology, but flubbed PL/I. When it
appeared that the Digitek compiler was hopeless, Bob Morris proposed that
we write a quick and dirty one in TMG. Despite being slow (an interpreter
running on an emulated 7090) and providing only three diagnostics, this
compiler carried the project for a couple of years.
When Unix came along, we were again faced with how to bootstrap TMG across
machines. This time I wrote a bare-bones interpreter in PDP7 assembler, then
by stages grew the language back to the Multics state. Ken, in a compliment
I still treasure, once called this the most amazing program on the original
I believe TMG was involved in the initial evolution of B, but the
real tour-de-force in B was the ability of an interpreted version to
exploit software paging and transcend the limited memory of the PDP-11.
The following scenario was to be repeated several times in the early days
of Unix. When the native version of B ran out of steam, the interpreted
version would be used to introduce some new optimization that would squeeze
the native version back to fit. (Bigger input, smaller output!) Subsequently
we saw the same thing happen with C and the kernel. When the kernel grew
too big, a new optimization would be introduced in C to squeeze it. (And to
squeeze the compiler, too. The compiler, though, never enjoyed B's advantage
of being able temporarily to run in a bigger arena.)
I've been looking into the history of yacc (yet another compiler compiler).
The earliest reference I can find is the man page for yacc from v3
which indicates that yacc was written in B language. The files actn.b
and /crp/scj/bigyacc are mentioned. No luck so far in locating those
There is a man page for v4 which is very brief.
There is a yacc executable for v5 but so far I haven't found any v5
era code that works with it. My attempts to compile bc.y from v6 using
yacc from v5 were not successful.
Also the source code for yacc in v5 is missing.
On a happier note I was able to use yacc and cc to regenerate the bc
calculator in v6. It needed a fair amount of swap space to compile
otherwise an "Intermediate file error" will occur. It seemed to
require at least 300 blocks of hard drive space.
It's a bit mysterious what the Unix v5 yacc was used on. It predated
bc and expr. There's no v5 era *.y files available to look at.
I've been comparing Unix v5 libc to modern linux and various other
Unix versions and I found something odd.
I made a list of functions which occur in Unix v5 libc.a and modern
linux glibc.a and while there is no problem using the ecvt function in
modern linux it doesn't seem to appear:
ar t /usr/lib/libc.a | grep ecvt
...doesn't find ecvt.
But if you do:
grep ecvt /usr/lib/libc.a
Binary file /usr/lib/libc.a matches
So it seems it is in there somewhere. While searching for ecvt.c I
found it as part of openbsd. I assume in modern Linux ecvt must be
part of a larger function but I couldn't find it in the glibc source.
Of course in Unix v5 things were completely straightforward as TUHS
has the file V5/usr/source/s3/ecvt.s
I just want to find all the functions that are still in modern glibc.a
which also existed in Unix v5 libc.a
At 01:04 PM 8/15/2014, Brian Zick wrote:
>Would it still be possible today for someone like me to go out, and find an old teletype terminal (an old ASR or DECwriter or something), set up a phone line and modem and get a roll of paper, and then actually use it to connect to other computers?
Yes, lots of people do it. There is a "Greenkeys" mailing list
populated by mostly ham radio RTTY types, but it's also a great archive
of posts about hook-ups and repairs. Yes, there are current-loop
adapters and RS-232 to USB adapters that can be used to connect
to contemporary machines. There are also streaming audio web sites
that send RTTY-style signals if you'd like to emulate your old radio
over the Internet but still use your RTTY audio decoding hardware.
There's also a fellow http://aetherltd.com/ who connects even older teletype
hardware to cell-phone texting.
The Teletype Model 33 was very popular among early computer users
because it was relatively low-priced compared to heavier-duty
teletypes. The old RTTY folks tend to look down their nose at it
because it wasn't as robust as other models.
They routinely huff and puff at recent auction prices for the Model 33,
though, as old computer collectors routinely pay $1,000 for them, while
it's tough to give away the better-built (and heavier!) teletypes.
Last summer I picked up a Western Union-branded Teletype Model 28 KSR
(circa mid-1950s) in near-pristine condition for $50. Almost twenty
years ago I found a Model 33 in a university dumpster.