Subject: Re: Some Success with s1-bits archive

From: [email-masked]
Date: Thu, 6 Jan 2000 01:03:10 -0500

You've had more success than I in the archeology of s1.

 > What was the process of changing epochs when timestamps were in clicks,
 > both in the rebuilding of the binaries, and in the system itself?

I think epoch changes (in the 60th-sec era)  were done by writing a program that
looked at all the inodes on the disk and in some way adjusted
them back (subtract a year).  I don't remember whether this was clamped at the earliest
representable date or otherwise how unrepresentable dates were
dealt with.  There was enough churn that probably few things on the disk
could not be adjusted.   I seem to remember that at least some DECtapes
were similarly adjusted.  With just an epoch change, probably most
programs didn't need to be recompiled just for that (only those
that displayed dates).  But of course things tended to be recompiled
frequently for other reasons.

I'm a little confused about this--

 > Now to s2-bits. It looks like most files have contiguous blocks. I did
 > a visual inspection of the file, and broke it into fragments. The list of
 > fragments found are described below. A copy of the fragments can be obtained
 > by anonymous ftp to minnie.cs.adfa.edu.au in the file
 > incoming/s2-fragments.tar.gz

This means s1-bits, right?  I collected your fragments archive in any case.
I'm guessing that s1 is likely to be part of a disk dump onto tape.
Correlation of the contents (the fragments you found are
mostly recognizable) with manuals probably will yield
approximate dates.

---

From: [email-masked]
Date: Fri, 7 Jan 2000 14:53:22 -0500

OK, here is a better table, with some new facts:

First edition: November 1971
	a.out: 405
	epoch: Jan 1 1971 (60ths)
	dump format: tap

Second edition: June 1972
	a.out: 407 (405 OK)
	epoch: Jan 1, 1971 (60ths)
	dump format: tap

Third edition: February 1973
	a.out: 407
	epoch: Jan 1, 1972 (60ths)
	dump format: tap

Fourth edition: November 1973 (first C system)
	a.out: 407, 410
	epoch: Jan 1, 1970 (seconds)
	dump format: tp

---

From: [email-masked]
Date: Fri, 7 Jan 2000 01:48:38 -0500

I will recheck the dates.  I looked at them earlier today
but did some cut'n'paste in the mail and might have
mistyped also.  (Esp. in the attribution of 3rd to '72 sted 73; but
tomorrow instead jotting down notes from the shelved manuals
I will get manuals all together and do it more systematically).

One problem is that I suspect that the tap-format tapes
of which I have copies probably have more than one
epoch, and the program has just one epoch built in.

Feel free to post the C compiler story.  (BTW, I just looked
at the minnie mailing list archives and have seen comments
through Foust on 7 Jan Oz time).  It's still correct but I garbled
a bit.  Slightly edited version:

---
Ken's modified C compiler (the neat thing in his Turing award speech)
came up on the mailing list.  I've talked about the story in netnews,
but either Deja no longer goes back far enough or I didn't think
of the right search keys.

The bugged compiler was in a sense released, but probably
"implanted" is a better word.  It was not on a distribution.
Ken sent it to the Raritan River PWB group at the Labs, saying "here
is a new compiler.  I think you have to install the binaries;
your current compiler might not handle compiling the source."
They ran it for a few months; at some point I think they
looked at the symbol table for some reason and saw
some things they didn't understand so they recompiled
it, using an old compiler.  Or conceivably they ran
cpp on the main compiler,  and looked at the output--it was actually
cpp that was bugged.  However, I don't think they ever worked out
what had happened exactly, just felt that something was funny.
>From our point of view, the hole just disappeared at some
point.

One thing I've always wondered about was whether
PWB ever redistributed it unknowingly.  Mashey doubts this,
but isn't utterly positive.  Certainly it didn't spread far--
it is a fragile virus.

	Dennis