Tim Shoppa:
This brings up a question: should fixes (and I mean fundamental fixes
like Y2K ones) be incorporated back into the boot images in the archive, or
should they be left in their "pristine" state? (Yes, i know, some of
those boot images aren't quite so pristine.)
I would argue strongly that the archive should contain absolutely pure
copies of any historic objects, whether they were proper distributions
or just snapshots like most of the older boot images. It's important
to preserve accurate, unbowdlerized history; that is part of what we
should be doing.
There's nothing wrong with keeping fixed-up versions too, but but they
should be clearly distinguished from the historic originals. (Perhaps
we could label them `ancient' and `primary platform'?)
Even using a CVS repository somehow doesn't feel kosher to me, though
that is probably silly as long as it is possible (and clear how) to
extract the unimproved original, and as long as the very original
distribution or dump tape or whatnot is kept around too so that future
archaeologists have the right thing to study.
Norman Wilson
684 Crawford Street, Toronto
(Formerly 696 Crawford Street before a renumbering in the 1950s;
I keep thinking of putting the old number up too.)
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id UAA48301
for pups-liszt; Thu, 6 Jan 2000 20:35:35 +1100 (EST)
In article by Tim Shoppa:
> This brings up a question: should fixes (and I mean fundamental fixes
> like Y2K ones) be incorporated back into the boot images in the archive, or
> should they be left in their "pristine" state? (Yes, i know, some of
> those boot images aren't quite so pristine.)
I'd agree to both. Mind you, once you start patching, where do you stop?
We could bring V6 up to being POSIX compatible with an ANSI C compiler :-)
Seriously, at one stage I did think of trying to check-in every version of
UNIX we have into a single CVS repository. Problem is, files have moved
around, and I want to leave gaps just in case we ever get the missing versions.
> As long as we're on the topic, which versions of Unix had the C
> compiler recognize when it was recompiling [/bin/login] and put a back
> door in for the developers?
I might ask Dennis for the details. From memory, the binaries never got out
of the Labs, and it would have been around the time of V6. Also from memory,
this was the topic of Ken's speech when he won the Turing award. I wonder if
the article is lying around somewhere.
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id HAA41128
for pups-liszt; Thu, 6 Jan 2000 07:45:45 +1100 (EST)
>From Andru Luvisi <luvisi(a)andru.sonoma.edu> Thu Jan 6 07:01:27 2000
Received: from andru.sonoma.edu (andru.sonoma.edu [130.157.3.226])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id HAA41124
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 6 Jan 2000 07:45:21 +1100 (EST)
Received: (qmail 8022 invoked by uid 501); 5 Jan 2000 21:01:27 -0000
Received: from localhost (sendmail-bs(a)127.0.0.1)
by localhost with SMTP; 5 Jan 2000 21:01:27 -0000
Date: Wed, 5 Jan 2000 13:01:27 -0800 (PST)
From: Andru Luvisi <luvisi(a)andru.sonoma.edu>
To: Warren Toomey <wkt(a)cs.adfa.edu.au>
cc: Unix Heritage Society <pups(a)minnie.cs.adfa.edu.au>
Subject: Re: Viral Unix Compiler
In-Reply-To: <200001052035.HAA24359(a)henry.cs.adfa.edu.au>
Message-ID: <Pine.LNX.4.03.10001051300300.7685-100000(a)andru.sonoma.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Thu, 6 Jan 2000, Warren Toomey wrote:
[snip]
> I might ask Dennis for the details. From memory, the binaries never got out
> of the Labs, and it would have been around the time of V6. Also from memory,
> this was the topic of Ken's speech when he won the Turing award. I wonder if
> the article is lying around somewhere.
http://www.acm.org/classics/sep95/
Andru
--
--------------------------------------------------------------------------
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| luvisi(a)andru.sonoma.edu | Textile imports from Provence, France |
--------------------------------------------------------------------------
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id IAA41348
for pups-liszt; Thu, 6 Jan 2000 08:14:17 +1100 (EST)
>From "J. Capp" <jcapp(a)wilkes.kp.net> Thu Jan 6 07:33:48 2000
Received: from wilkes.kp.net (wilkes.kp.net [207.44.21.1])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id IAA41344
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 6 Jan 2000 08:13:52 +1100 (EST)
Received: from localhost (jcapp@localhost)
by wilkes.kp.net (8.9.3/8.9.3) with ESMTP id QAA11665;
Wed, 5 Jan 2000 16:33:48 -0500
Date: Wed, 5 Jan 2000 16:33:48 -0500 (EST)
From: "J. Capp" <jcapp(a)wilkes.kp.net>
To: Warren Toomey <wkt(a)cs.adfa.edu.au>
cc: Unix Heritage Society <pups(a)minnie.cs.adfa.edu.au>
Subject: Re: Viral Unix Compiler
In-Reply-To: <200001052035.HAA24359(a)henry.cs.adfa.edu.au>
Message-ID: <Pine.LNX.4.05.10001051618210.10423-100000(a)wilkes.kp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Thu, 6 Jan 2000, Warren Toomey wrote:
>
> I might ask Dennis for the details. From memory, the binaries never got out
> of the Labs, and it would have been around the time of V6. Also from memory,
> this was the topic of Ken's speech when he won the Turing award. I wonder if
> the article is lying around somewhere.
>
Ken's speech "Reflections on Trusting Trust", was published in the
Communication of the ACM, Vol. 27, No. 8, August 1984. It describes this
"trojan horse" in great detail. But I do believe from this article that
it was an example of what could be done, not necessarily something that
was ever released into the hands of the public.
Jim Capp
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id UAA48149
for pups-liszt; Thu, 6 Jan 2000 20:09:45 +1100 (EST)
Michael Sokolov grumbled:
> Warren's note reminds me of a few other Y2K bugs I've spotted that affect
> ancient UNIX:
^^^^^^^
Would you please avoid that term? It is offensive to those for whom Kernighan/
Ritchie/Thompson/Berkeley UNIX is the primary and sole computing platform.
Thank you.
If the shoe doesn't fit, feel free not to wear it. I certainly didn't have
`Kernighan/Ritchie/Thompson/Berkeley UNIX' in mind; I rarely do, as I am
much more interested in ancient systems.
Chuckling all the way to the rest home,
Norman Wilson
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id UAA37886
for pups-liszt; Wed, 5 Jan 2000 20:13:04 +1100 (EST)
>From Greg Lehey <grog(a)lemis.com> Wed Jan 5 19:33:12 2000
Received: from freebie.lemis.com (root(a)freebie.lemis.com [192.109.197.137])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id UAA37882
for <pups(a)minnie.cs.adfa.edu.au>; Wed, 5 Jan 2000 20:12:42 +1100 (EST)
Received: (from grog@localhost)
by freebie.lemis.com (8.9.3/8.9.0) id UAA60952;
Wed, 5 Jan 2000 20:03:12 +1030 (CST)
Date: Wed, 5 Jan 2000 20:03:12 +1030
From: Greg Lehey <grog(a)lemis.com>
To: norman(a)nose.cita.utoronto.ca
Cc: pups(a)minnie.cs.adfa.edu.au
Subject: Re: 200(0) Ancient UNIX Licenses
Message-ID: <20000105200311.Y30038(a)freebie.lemis.com>
References: <200001041145.WAA32766(a)minnie.cs.adfa.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <200001041145.WAA32766(a)minnie.cs.adfa.edu.au>
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Tuesday, 4 January 2000 at 7:08:51 -0500, norman(a)nose.cita.utoronto.ca wrote:
> Warren's note reminds me of a few other Y2K bugs I've spotted that affect
> ancient UNIX:
> - date: no way to set the date past 1999 unless in the present year,
> because two-digit input.
I didn't have any problem with 2.11BSD. I just supplied 00 for the
year. Which release were you using?
Greg
--
Finger grog(a)lemis.com for PGP public key
See complete headers for address and phone numbers
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id AAA38658
for pups-liszt; Thu, 6 Jan 2000 00:03:32 +1100 (EST)
>From Tim Shoppa <SHOPPA(a)trailing-edge.com> Wed Jan 5 23:23:18 2000
Received: from timaxp.trailing-edge.com (timaxp.trailing-edge.com [63.73.218.130])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id AAA38654
for <PUPS(a)MINNIE.CS.ADFA.EDU.AU>; Thu, 6 Jan 2000 00:03:11 +1100 (EST)
Received: by timaxp.trailing-edge.com; Wed, 5 Jan 2000 8:23:18 -0500
Date: Wed, 5 Jan 2000 8:23:18 -0500
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: grog(a)lemis.com
CC: PUPS(a)minnie.cs.adfa.edu.au
Message-Id: <000105082318.202000b0(a)trailing-edge.com>
Subject: Re: 200(0) Ancient UNIX Licenses
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Greg wrote:
>On Tuesday, 4 January 2000 at 7:08:51 -0500, norman(a)nose.cita.utoronto.ca wrote:
>> Warren's note reminds me of a few other Y2K bugs I've spotted that affect
>> ancient UNIX:
>> - date: no way to set the date past 1999 unless in the present year,
>> because two-digit input.
>I didn't have any problem with 2.11BSD. I just supplied 00 for the
>year. Which release were you using?
That's because I did the fix for 2.11BSD back when I was Y2K-ing all
my PDP-11 sources a few years ago, and Steven incorporated it into the
distribution. The fix was quick and dirty, but works fine because
Unix effectively has an expiration date of 2038 when the signed 32-bit time
word goes negative, so it's easy enough to window the centuries.
This brings up a question: should fixes (and I mean fundamental fixes
like Y2K ones) be incorporated back into the boot images in the archive, or
should they be left in their "pristine" state? (Yes, i know, some of
those boot images aren't quite so pristine.)
As long as we're on the topic, which versions of Unix had the C
compiler recognize when it was recompiling the kernel and put a back
door in for the developers? And of course the C compiler recognized
when it was recompiling itself and made sure that the this recognition
code was also inserted. As I understand it, the distributed sources
never had this security hole in them, only the binaries, but of course
the binaries self-perpetuated the security hole even if you recompiled them.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id BAA39019
for pups-liszt; Thu, 6 Jan 2000 01:30:17 +1100 (EST)
>From "A. P. Garcia" <apg(a)execpc.com> Thu Jan 6 00:46:13 2000
Received: from playground.lan (qmailr(a)minbar-1-131.mdm.mke.execpc.com [169.207.136.133])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id BAA39006
for <PUPS(a)minnie.cs.adfa.edu.au>; Thu, 6 Jan 2000 01:29:49 +1100 (EST)
Received: (qmail 451 invoked by uid 1000); 5 Jan 2000 14:46:13 -0000
Date: 5 Jan 2000 14:46:13 -0000
Message-ID: <20000105144613.450.qmail(a)playground.lan>
From: "A. P. Garcia" <apg(a)execpc.com>
To: grog(a)lemis.com, SHOPPA(a)trailing-edge.com
Subject: Re: 200(0) Ancient UNIX Licenses
Cc: PUPS(a)minnie.cs.adfa.edu.au
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> This brings up a question: should fixes (and I mean fundamental fixes
> like Y2K ones) be incorporated back into the boot images in the archive, or
> should they be left in their "pristine" state? (Yes, i know, some of
> those boot images aren't quite so pristine.)
Ideally, both. Perhaps boot images with these fixes should be available,
yes, but so should the originals.
> As long as we're on the topic, which versions of Unix had the C
> compiler recognize when it was recompiling the kernel and put a back
> door in for the developers?
Good question! I don't know, but it was actually the login command...
Here's Brian Kernighan's note on troff and Y2K:
in n1.c, numtab[YR] is set to localtime()->tm_year, which is the
number of years since 1900. in 2000, this will contain 100.
the troff manual says that \n(yr contains "the last two digits of
the current year", but nowhere in the code is this set, and the
year can be set to anything. so it's really "the current year
minus 1900". the manual and the code are
inconsistent, which is always a problem.
in any case, in most installations troff and nroff are legacy
systems for which there is no source code, so changing them is
not feasible. furthermore, any change to troff is likely to
require changes in macro packages anyway, and may cause silent
errors by conflicting with current behavior or colliding with
previously unused names.
fortunately, it seems straightforward to fix the macro packages
that are the most likely sources of problem; individual macro
packages will have to be fixed by individuals. grepping for
"yr" will find most trouble spots.
typical macros packages use \n(yr in two ways. one is
ds ]W (printed \n(mo/\n(dy/\n(yr)
which assumes that the year is 2 digits and to be printed as 2
digits. presumably the first day of 2000 is to be printed as
1/1/00, so the fix here is to set register yr to 2 digits
.nr yr \n(yr%100
either once at the beginning (under the assumption that the year
isn't changed by the macro package) or each time \n(yr is going
to be used (providing locality at the price of more changes).
the other common usage is
.ds ]W \*(]m \n(dy, 19\n(yr
the easiest way to fix this is to add, at the beginning again,
.nr yr 1900+\n(yr
and change all subsequent uses from 19\n(yr to \n(yr.
any macro package that uses both of these constructions will need
a bit more care to unify things; the easiest fix is likely to be
two registers, one with the full year and one with the last two
digits.
.nr YR 1900+\n(yr \" 4-digit year
.nr yr \n(yr%100 \" last two digits
this will break code that happened to use this register name.
some macro packages (e.g., -mm) try to be clever about dates,
and include explicit tests to determine whether a user-provided
date has 2 or 4 digits, and then adjust by 1900; this is another
case that has to be fiddled by hand.
any approach that changes register yr at the beginning fails if
the year is set explicitly later on, as it might be by some of
the date macros in -ms and -mm. this still seems like the best
fix, however.
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id KAA35876
for pups-liszt; Wed, 5 Jan 2000 10:35:21 +1100 (EST)
Warren's note reminds me of a few other Y2K bugs I've spotted that affect
ancient UNIX:
- date: no way to set the date past 1999 unless in the present year,
because two-digit input.
- at and atrun: commands are stored in the spooling directory with names
of the form YY.DDD.HHMM.xx, where xx is a unique number. This one is
trickier to fix, because the filename is already exactly 14 characters,
so there's no room for expansion. (On V10, I just rewrote the programs
to use a simple UNIX time expressed as a decimal number. A simpler solution
might be to print the year in hex.)
- Perhaps least consequential and most amusing: nroff and troff store the
year in a number register. The manual says it contains `the last two
digits of the year,' and many macro packages assume that is true, but the
truth is that it contains (year-1900), the same as tm_year. So, for example,
when I ran man on New Year's Day, I was told that the manual page had been
printed on 1/1/100.
I was about to fix the various troff macro packages when I noticed that
the manual implied that I shouldn't. I asked Brian Kernighan for an opinion
(since the code and the manual were both last touched by him); he thinks the
best view is that the manual is just wrong and the macro packages should be
fixed. \n(yr is a read-write register, so `.nr yr \n(yr+1900' is probably
the easiest fix, though Brian points out that it's not always the right one
(maybe you really wanted a two-digit year). If anyone is interested I can
pass along a more detailed note from Brian.
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id CAA33653
for pups-liszt; Wed, 5 Jan 2000 02:17:48 +1100 (EST)
Welcome back to all the PUPS mailing list members! They've finally turned our
router back on here, so now the list server Minnie is no longer deaf.
Over the past few weeks I've been working on my Apout simulator, with help
from Tim Shoppa, and it now runs binaries from 1st Edition UNIX. The
announcement is below; details of how to obtain the source, and some UNIX
binaries, are also given.
Hope you all had a good festive break, and best wishes for the New Year.
Cheers,
Warren
Apout -- Simulate PDP-11 Unix a.out binaries
Version 2.3 Alpha
Warren Toomey wkt(a)cs.adfa.edu.au
January 2000
Introduction
------------
This program is a user-level simulator for UNIX a.out binaries. Binaries
for V1, V5, V6, V7, 2.9BSD and 2.11BSD can be run with this simulator. The
user-mode PDP-11 instructions are simulated, and TRAP instructions are
emulated by calling equivalent native-mode system calls.
The advantages of an a.out simulator over a full-blown PDP-11 simulator are:
+ system calls can be done natively, thus speeding up execution
+ the simulator is less of a CPU-hog than a full-blown PDP-11 simulator
+ you don't need a simulated operating system or a simulated file system
Apout can be obtained via anonymous ftp at minnie.cs.adfa.edu.au in the
directory pub/PDP-11/Sims/Apout. The directory pub/PDP-11/Sims/Apout/UnixBins
contains tar archives of a.out binaries from several versions of UNIX.
Status
------
The program is now at release 2.3 Alpha1. Most of the binaries from V5, V6
and V7 run fine. All of the V5/V6/V7 system calls are caught, but some are
ignored and some generate EPERM errors. The V1, 2.9BSD and 2.11BSD
environments are still under construction: see the file LIMITATIONS for
details. Finally, the simulator won't run on a big-endian machine.
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id KAA29223
for pups-liszt; Tue, 4 Jan 2000 10:43:10 +1100 (EST)
>From Warren Toomey <wkt(a)cs.adfa.edu.au> Tue Jan 4 10:08:05 2000
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.edu.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id KAA29219
for <pups(a)minnie.cs.adfa.edu.au>; Tue, 4 Jan 2000 10:42:51 +1100 (EST)
Received: (from wkt@localhost)
by henry.cs.adfa.edu.au (8.9.2/8.9.3) id LAA03372
for pups(a)minnie.cs.adfa.edu.au; Tue, 4 Jan 2000 11:08:05 +1100 (EST)
From: Warren Toomey <wkt(a)cs.adfa.edu.au>
Message-Id: <200001040008.LAA03372(a)henry.cs.adfa.edu.au>
Subject: No Answer to `Unix Mallet' Mystery
To: pups(a)minnie.cs.adfa.edu.au (Unix Heritage Society)
Date: Tue, 4 Jan 2000 11:08:05 +1100 (EST)
Reply-To: wkt(a)cs.adfa.edu.au
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Hi all,
I just received this e-mail from Keith Bostic, in reply to a
strange question which was discussed on this mailing list months (years?)
ago. Read on.....
----- Forwarded message from Keith Bostic -----
Hi, Warren, I'm digging out some old email, and found the following:
> [Chris] While looking over userland source, calendar(1)'s calendar.computer
> mentions:
> 08/14 First Unix-based mallet created, 1954
> Could someone please explain the joke. :)
>
> [Warren] I can't find it in V6/V7/2.11. According to the SCCS records on
> Kirk McKusick's 4th CD,
> /usr/src/usr.bin/calendar/calendars/calendar.computer was:
> date and time created 89/11/27 14:10:01 by bostic
> Mind you, this was obviously the first time it was checked into SCCS.
>
> The earliest calendar.computer files I can find, apart from the
> SCCS record, are:
>
> 4bsd/43reno.vax/src.tar, calendar.computer dated 1989/11/28
> 4bsd/net2/net2.tar, calendar.computer dated 1989/11/28
> 4bsd/43reno.vax/usr.tar, calendar.computer dated 1990/07/29
>
> so the finger of suspicion does point at Keith Bostic.
I think I'm just the one that checked it in... around that time
I went through the source tree and committed everything into
SCCS, and, my bet is that those files weren't already under SCCS.
I also broke the single calendar file up into a bunch of different
files as part of re-writing calendar(1) to make it AT&T free.
You might want to look in early releases for a "calendar" source
file, and not "calendar.computer" (although I'm not positive it
was named "calendar", I'm pretty sure that I broke an original
file up into multiple files, so I created the "calendar.computer"
file and filled it with stuff from an already existing file).
> So can you shed any light on this interesting entry in calendar.computer,
> was it a private joke, and were you the perpertrator?
Not me. Did you ever figure out where the line came from?
--keith
----- End of forwarded message from Keith Bostic -----
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id MAA29790
for pups-liszt; Tue, 4 Jan 2000 12:15:39 +1100 (EST)
>From Warren Toomey <wkt(a)cs.adfa.edu.au> Tue Jan 4 11:40:19 2000
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.edu.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id MAA29784
for <pups(a)minnie.cs.adfa.edu.au>; Tue, 4 Jan 2000 12:15:19 +1100 (EST)
Received: (from wkt@localhost)
by henry.cs.adfa.edu.au (8.9.2/8.9.3) id MAA04392
for pups(a)minnie.cs.adfa.edu.au; Tue, 4 Jan 2000 12:40:19 +1100 (EST)
From: Warren Toomey <wkt(a)cs.adfa.edu.au>
Message-Id: <200001040140.MAA04392(a)henry.cs.adfa.edu.au>
Subject: 200 Ancient UNIX Licenses
To: pups(a)minnie.cs.adfa.edu.au (Unix Heritage Society)
Date: Tue, 4 Jan 2000 12:40:19 +1100 (EST)
Reply-To: wkt(a)cs.adfa.edu.au
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Hi all,
Just a note to say that I have received SCO Ancient UNIX licenses
up to AU-201 in the mail today. Another note: a bug in the date libraries
in 5th and 6th Edition Unix prevents ctime() from properly displaying
dates after November 1999. I haven't bothered to find/fix it yet.
Cheers,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id WAA32773
for pups-liszt; Tue, 4 Jan 2000 22:45:57 +1100 (EST)
