New Version of Apout PDP-11 Emulator

New Version of Apout PDP-11 Emulator

[Warren Toomey]

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 at 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 at 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)
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 at minnie.cs.adfa.edu.au>; Tue, 4 Jan 2000 10:42:51 +1100 (EST)
Received: (from wkt at localhost)
	by henry.cs.adfa.edu.au (8.9.2/8.9.3) id LAA03372
	for pups at minnie.cs.adfa.edu.au; Tue, 4 Jan 2000 11:08:05 +1100 (EST)
From: Warren Toomey <wkt@cs.adfa.edu.au>
Message-Id: <200001040008.LAA03372 at henry.cs.adfa.edu.au>
Subject: No Answer to `Unix Mallet' Mystery
To: pups at minnie.cs.adfa.edu.au (Unix Heritage Society)
Date: Tue, 4 Jan 2000 11:08:05 +1100 (EST)
Reply-To: wkt at 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 at 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 at 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)
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 at minnie.cs.adfa.edu.au>; Tue, 4 Jan 2000 12:15:19 +1100 (EST)
Received: (from wkt at localhost)
	by henry.cs.adfa.edu.au (8.9.2/8.9.3) id MAA04392
	for pups at minnie.cs.adfa.edu.au; Tue, 4 Jan 2000 12:40:19 +1100 (EST)
From: Warren Toomey <wkt@cs.adfa.edu.au>
Message-Id: <200001040140.MAA04392 at henry.cs.adfa.edu.au>
Subject: 200 Ancient UNIX Licenses
To: pups at minnie.cs.adfa.edu.au (Unix Heritage Society)
Date: Tue, 4 Jan 2000 12:40:19 +1100 (EST)
Reply-To: wkt at 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 at 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 at 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)
Received: from nose.cita.utoronto.ca (nose.cita.utoronto.ca [128.100.76.157])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id WAA32766
	for <pups at minnie.cs.adfa.edu.au>; Tue, 4 Jan 2000 22:45:32 +1100 (EST)
From: norman@nose.cita.utoronto.ca
Message-Id: <200001041145.WAA32766 at minnie.cs.adfa.edu.au>
Subject: 200(0) Ancient UNIX Licenses
To: pups at minnie.cs.adfa.edu.au
Date: Tue, 04 Jan 2000 07:08:51 -0500
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

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 at 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)
Received: from meson.jpsystems.com (209-184-70-169.jpsystems.com [209.184.70.169] (may be forged))
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id CAA33649
	for <pups at minnie.cs.adfa.edu.au>; Wed, 5 Jan 2000 02:17:13 +1100 (EST)
Received: by meson.jpsystems.com (5.67/1.35)
	id AA12473; Tue, 4 Jan 00 09:39:51 -0600
Date: Tue, 4 Jan 00 09:39:51 -0600
From: msokolov@meson.jpsystems.com (Michael Sokolov)
Message-Id: <0001041539.AA12473 at meson.jpsystems.com>
To: pups at minnie.cs.adfa.edu.au
Subject: Re: 200(0) Ancient UNIX Licenses
In-Reply-To: <200001041145.WAA32766 at minnie.cs.adfa.edu.au>
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

norman at nose.cita.utoronto.ca wrote:

> 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.

> - 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.)

Both Y2K bugs have been fixed in the UNIX master source tree a couple of weeks
ago, will appear on the 4.3-QJ0b tape. For details, send a subscription request
to quasijarus-request at meson.jpsystems.com.

> - 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.

OK, haven't hit that one yet, will look. Please do pass along B. W. Kernighan's
note.

--
Michael Sokolov				Harhan Computer Operation Facility
Special Agent				615 N GOOD LATIMER EXPY #4
International Free Computing Task Force	DALLAS TX 75204-5852 USA
					Phone: +1-214-824-7693
					ARPA INET: msokolov at meson.jpsystems.com

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id DAA34078
	for pups-liszt; Wed, 5 Jan 2000 03:27:07 +1100 (EST)
Received: from playground.lan (qmailr at kashyyyk-1-179.mdm.mke.execpc.com [169.207.133.53])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id DAA34066
	for <pups at minnie.cs.adfa.edu.au>; Wed, 5 Jan 2000 03:26:28 +1100 (EST)
Received: (qmail 202 invoked by uid 1000); 4 Jan 2000 16:46:07 -0000
Date: 4 Jan 2000 16:46:07 -0000
Message-ID: <20000104164607.201.qmail at playground.lan>
From: "A. P. Garcia" <apg@execpc.com>
To: pups at minnie.cs.adfa.edu.au
Subject: that ancient old geezer stuff
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

norman at nose.cita.utoronto.ca wrote:
>> Warren's note reminds me of a few other Y2K bugs I've spotted that affect
>> ancient UNIX:

msokolov at meson.jpsystems.com replied:
> 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.


Interesting.  It's true that the word ancient is generally pejorative
in the context of computers.  However, I think that this word may have
helped persuade SCO to offer us licenses for these versions.  The header
of my license contains some wording like, "Special software license
agreement for ancient unix source code."

So I tend to use this terminology with an inside-joke kind of smirk on
my face.  These kernels are more elegant and pure in design than their
descendants.  If the good folks at SCO are having pleasant dreams, please
don't disturb their sleep.


> Please do pass along B. W. Kernighan's note.

I second this request.  Don't hold out on us.  :-)