From: random832@fastmail.com (Random832)
Subject: [TUHS] Some notes on running UNIX v6 in 2015, using SimH and a healthy dose of documentation
Date: Thu, 3 Dec 2015 17:27:47 +0000 (UTC) [thread overview]
Message-ID: <n3pu2j$27r$1@ger.gmane.org> (raw)
In-Reply-To: <20151203152150.C571C18C084@mercury.lcs.mit.edu>
On 2015-12-03, Noel Chiappa wrote:
> I did a very similar exercise using the Ersatz11 simulator; I have a lot
> of stuff about the process here:
>
> http://www.chiappa.net/~jnc/tech/V6Unix.html
>
> It contains a number of items that you might find useful, e.g.: "V6 as
> distributed is strictly a 20th Century operating system. Literally. You can't
> set the date to anytime in the 21st century, for two reasons. First, the
> 'date' command only take a 2-digit year number. Second, even if you fix that,
> the ctime() library routine has a bug in it that makes it stop working in the
> closing months of 1999."
I don't think your fix to the date command is accurate. The description says:
> The 'date' command has been extended to support 2- and 4-digit year
> numbers (to be upwardly compatible, the 2-digit ones assume 19xx).
But the code says:
> if ((y < 0) || (yh < 0)) {
> time(nt);
> y = localtime(nt)[5];
> y =+ 1900;
> }
> else
> y = yh + y;
To match your description it should be
if ((y < 0) && (yh < 0)) {
time(nt);
y = localtime(nt)[5];
} else if(y < 0) {
/* yh = two digit year */
y = 1900 + yh;
} else
y = yh + y;
Though I'd be inclined to add "if (y < 1970) y =+ 100;" to bring it in line
with modern systems' 1970-2069 range for two-digit years.
Of course, _any_ ancient unix system (and a fair few modern ones) can't
represent dates past 2038. We've only got 23 years left before attempts to
bring up old systems will need some trickery (maybe set the year to 28 or 56
years before the present... that trick, with increasing windows, will work
until 2100 isn't a leap year)
On the other hand, treating it as an "unsigned" value will last about as long
and is a bit less of a hack. But as you note, doing this sort of thing in V6 C
isn't trivial.
next prev parent reply other threads:[~2015-12-03 17:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 15:21 Noel Chiappa
2015-12-03 17:27 ` Random832 [this message]
2015-12-03 18:46 ` Will Senn
-- strict thread matches above, loose matches on Subject: below --
2015-12-03 15:42 Noel Chiappa
2015-12-03 18:54 ` Will Senn
2015-12-04 0:52 ` Greg 'groggy' Lehey
2015-12-04 21:33 ` Win Treese
2015-12-04 22:00 ` John Cowan
2015-12-02 21:37 Will Senn
2015-12-03 0:20 ` Warren Toomey
2015-12-03 2:37 ` Will Senn
2015-12-03 4:11 ` Dave Horsfall
2015-12-03 4:18 ` Will Senn
2015-12-03 6:05 ` Peter Jeremy
2015-12-03 12:59 ` John Cowan
2015-12-04 6:22 ` Dave Horsfall
2015-12-04 6:38 ` Greg 'groggy' Lehey
2015-12-04 14:52 ` John Cowan
2015-12-04 18:17 ` Ronald Natalie
2015-12-04 18:33 ` Gregg Levine
2015-12-04 22:36 ` Greg 'groggy' Lehey
[not found] ` <CAKt831GfmmKQ75TRy1tCmmbnx4CGLmjy12zns6-c+_oJB+h2dA@mail.gmail.com>
2015-12-04 19:13 ` SZIGETI Szabolcs
2015-12-04 12:41 ` Peter Jeremy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='n3pu2j$27r$1@ger.gmane.org' \
--to=random832@fastmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).