30 Oct
2019
30 Oct
'19
12:36 p.m.
All,
my daughter is well aware of my affinity for old computers and software, and, as usual,
she pointed out that there?s an XKCD for that:
https://xkcd.com/2221/
I found this remarkably accurate.
- Mark
30 Oct
30 Oct
2:35 p.m.
On Wed, Oct 30, 2019 at 2:17 PM Tapley, Mark B. via cctalk <
cctalk at classiccmp.org> wrote:
All,
my daughter is well aware of my affinity for old computers and software,
and, as usual, she pointed out that there?s an XKCD for that:
https://xkcd.com/2221/
I found this remarkably accurate.
For the dps8 emulator, I wrote (for expediency) the I/O code to complete
immediately. When the CPU executes an I/O instruction, the I/O is completed
and the interrupt posted before the next instruction is executed. As the
emulator was (at that point) single threaded, there was no performance
reason to do otherwise, and delaying interrupt delivery was additional code
that I didn't want to write and debug. The consensus in the Multics
community was that this was *probably* OK; the interrupt structure was
robust and the interrupt handling code well written, and should be able to
cope. But everytime a runtime failure occured, the question popped up: is
zero-latency I/O the issue? I ended up adding code to delay interrupt
delivery as a run-time configuration option so that that possibility could
be checked.
The XKCD is dead on for me. I have had that conversation.
-- Charles
2:50 p.m.
On Oct 30, 2019, at 2:35 PM, Charles Anthony via
cctalk <cctalk at classiccmp.org> wrote:
For the dps8 emulator, I wrote (for expediency) the I/O code to complete
immediately. When the CPU executes an I/O instruction, the I/O is completed
and the interrupt posted before the next instruction is executed. As the
emulator was (at that point) single threaded, there was no performance
reason to do otherwise, and delaying interrupt delivery was additional code
that I didn't want to write and debug. The consensus in the Multics
community was that this was *probably* OK; the interrupt structure was
robust and the interrupt handling code well written, and should be able to
cope. But everytime a runtime failure occured, the question popped up: is
zero-latency I/O the issue? I ended up adding code to delay interrupt
delivery as a run-time configuration option so that that possibility could
be checked.
The XKCD is dead on for me. I have had that conversation.
-- Charles
If you?re on this list, does this mean this is a good place to ask Multics questions? :-)
Yes, I have a couple.
Zane
3:50 p.m.
On Wed, Oct 30, 2019 at 2:50 PM Zane Healy <healyzh at avanthar.com> wrote:
I would think that Multics is well inside the cctalk purview. There are
several Multics knowledgeable people lurking on this list, and if we can't
answer a question, we know people who can. Ask away...
-- Charles
On Oct 30, 2019, at 2:35 PM, Charles Anthony via
cctalk <
cctalk at classiccmp.org> wrote:
For the dps8 emulator, I wrote (for expediency) the I/O code to complete
immediately. When the CPU executes an I/O instruction, the I/O is
completed
and the interrupt posted before the next
instruction is executed. As the
emulator was (at that point) single threaded, there was no performance
reason to do otherwise, and delaying interrupt delivery was additional
code
that I didn't want to write and debug. The
consensus in the Multics
community was that this was *probably* OK; the interrupt structure was
robust and the interrupt handling code well written, and should be able
to
cope. But everytime a runtime failure occured,
the question popped up: is
zero-latency I/O the issue? I ended up adding code to delay interrupt
delivery as a run-time configuration option so that that possibility
could
be checked.
The XKCD is dead on for me. I have had that conversation.
-- Charles
If you?re on this list, does this mean this is a good place to ask Multics
questions? :-) Yes, I have a couple.
4:01 p.m.
On Oct 30, 2019, at 3:50 PM, Charles Anthony
<charles.unix.pro at gmail.com> wrote:
I would think that Multics is well inside the cctalk purview. There are several Multics
knowledgeable people lurking on this list, and if we can't answer a question, we know
people who can. Ask away...
Awesome!
On my first install, about a year ago, I didn?t know to setup the Crank. I eventually
figured it out and could never get it going. It was failing with the following error.
Message from Initializer.SysDaemon (absentee) 10/30/19 0300.6 pst Wed:
Absentee job >user_dir_dir>SysAdmin>admin>crank.absin 191029110004.811332
termi
\cnated. absentee: Attempt to reenter user environment via a call to cu_$cl. J
\cob terminated.
I rebuilt the system recently, and now the error seems intermittent. I will say, that
backing up my directory of files, and restoring it to the new system was a lot easier than
fighting with the tape drives we had on the DPS-8 Mainframes I worked with nearly 30 years
ago (we ran GCOS-8).
I?m getting the following message on the console. This wasn?t initially a problem, but
now is.
1452.8 Utility.SysDaemon.z: monitor_quota: Storage in >system_control_1>syserr_log
is 26212% full.
The following absentee jobs are running.
lar
Absentee queue 1: 3 requests. 3 total requests.
120004.8 weekly.absin (deferred by user to 11/01/19 04:00)
103014.7 dodrp.absin (deferred by user to 10/31/19 02:30)
110004.6 crank.absin (deferred by user to 10/31/19 03:00)
r 14:58 1.003 17
mail
18 messages.
Message from Initializer.SysDaemon (install) 10/16/19 0300.2 pst Wed:
Installed sat for healyzh.SysAdmin.m.
Message from Initializer.SysDaemon (absentee) 10/16/19 0300.8 pst Wed:
Absentee job >user_dir_dir>SysAdmin>admin>crank.absin 191015173249.204951
termi
\cnated. absentee: Attempt to reenter user environment via a call to cu_$cl. J
\cob terminated.
Message from Initializer.SysDaemon (install) 10/18/19 0650.8 pst Fri:
Installed sat for healyzh.SysAdmin.m.
=:(10/19/19 0300.2 pst Sat) Installed sat for healyzh.SysAdmin.m.
=:(10/20/19 0300.2 pst Sun) Installed sat for healyzh.SysAdmin.m.
=:(10/21/19 0300.2 pst Mon) Installed sat for healyzh.SysAdmin.m.
=:(10/22/19 0300.2 pst Tue) Installed sat for healyzh.SysAdmin.m.
=:(10/23/19 0300.2 pst Wed) Installed sat for healyzh.SysAdmin.m.
Message from Initializer.SysDaemon (absentee) 10/23/19 0300.6 pst Wed:
Absentee job >user_dir_dir>SysAdmin>admin>crank.absin 191022110004.734659
termi
\cnated. absentee: Attempt to reenter user environment via a call to cu_$cl. J
\cob terminated.
Message from Initializer.SysDaemon (install) 10/24/19 0300.2 pst Thu:
Installed sat for healyzh.SysAdmin.m.
Message from Initializer.SysDaemon (absentee) 10/24/19 0300.6 pst Thu:
Absentee job >user_dir_dir>SysAdmin>admin>crank.absin 191023110004.826004
termi
\cnated. absentee: Attempt to reenter user environment via a call to cu_$cl. J
\cob terminated.
Message from Initializer.SysDaemon (install) 10/25/19 0300.2 pst Fri:
Installed sat for healyzh.SysAdmin.m.
=:(10/26/19 0300.2 pst Sat) Installed sat for healyzh.SysAdmin.m.
=:(10/27/19 0300.2 pst Sun) Installed sat for healyzh.SysAdmin.m.
=:(10/28/19 0300.2 pst Mon) Installed sat for healyzh.SysAdmin.m.
=:(10/29/19 0300.2 pst Tue) Installed sat for healyzh.SysAdmin.m.
=:(10/30/19 0300.2 pst Wed) Installed sat for healyzh.SysAdmin.m.
Message from Initializer.SysDaemon (absentee) 10/30/19 0300.6 pst Wed:
Absentee job >user_dir_dir>SysAdmin>admin>crank.absin 191029110004.811332
termi
\cnated. absentee: Attempt to reenter user environment via a call to cu_$cl. J
\cob terminated.
mail: Delete? n
r 14:59 1.298 0
4:10 p.m.
On Wed, Oct 30, 2019 at 4:01 PM Zane Healy <healyzh at avanthar.com> wrote:
I rebuilt the system recently, and now the error seems intermittent. I
will say, that backing up my directory of files, and restoring it to the
new system was a lot easier than fighting with the tape drives we had on
the DPS-8 Mainframes I worked with nearly 30 years ago (we ran GCOS-8).
I don't recognize that error. I will check on it.
I?m getting the following message on the console.
This wasn?t initially a
problem, but now is.
1452.8 Utility.SysDaemon.z: monitor_quota: Storage in
needs to be
done by hand. (It includes purging the log files). Instructions
can be found at:
https://docs.google.com/document/d/1cZsdr67LtE8YeWACdYWum8HIPMcHWdmUffxvK7g…
There is a dps8m/Multics mailing list at
https://sourceforge.net/p/dps8m/mailman/
-- Charles
system_control_1>syserr_log is 26212% full.
The crank does the daily and weekly accounting; the monthly accounting
31 Oct
31 Oct
7:10 a.m.
On Oct 30, 2019, at 4:10 PM, Charles Anthony
<charles.unix.pro at gmail.com> wrote:
On Wed, Oct 30, 2019 at 4:01 PM Zane Healy <healyzh at avanthar.com <mailto:healyzh
at avanthar.com>> wrote:
I rebuilt the system recently, and now the error seems intermittent. I will say, that
backing up my directory of files, and restoring it to the new system was a lot easier than
fighting with the tape drives we had on the DPS-8 Mainframes I worked with nearly 30 years
ago (we ran GCOS-8).
I don't recognize that error. I will check on it.
Thanks, that?s a frustrating one, I originally thought it was due to having waited until
the disks filled up to start trying to run the crank. Let me know if any further info
might help.
I?m getting the following message on the console.
This wasn?t initially a problem, but now is.
1452.8 Utility.SysDaemon.z: monitor_quota: Storage in
>system_control_1>syserr_log is 26212% full.
The crank does the daily and weekly accounting; the monthly accounting needs to be done
by hand. (It includes purging the log files). Instructions can be found at:
https://docs.google.com/document/d/1cZsdr67LtE8YeWACdYWum8HIPMcHWdmUffxvK7g…
<https://docs.google.com/document/d/1cZsdr67LtE8YeWACdYWum8HIPMcHWdmUffxvK7g-xbs/edit?usp=sharing>
Looks like i had a corrupt quota system, that doc did the trick!
There is a dps8m/Multics mailing list at
https://sourceforge.net/p/dps8m/mailman/ <https://sourceforge.net/p/dps8m/mailman/>
I just signed up for users and general. That seems like a better place to ask the
next question, which is a programming on Multics question. Though it will be a while
before I?m ready. Especially since I appear to have accidentally deleted the source code
I was working on from my original system, prior to backing it up. Mainframes really
should have nightly backups. :-)
Zane
3 Nov
3 Nov
8:14 a.m.
ons 2019-10-30 klockan 16:01 -0700 skrev Zane Healy via cctalk:
I
rebuilt the system recently, and now the error seems
intermittent. I will say, that backing up my directory of files, and
restoring it to the new system was a lot easier than fighting with
the tape drives we had on the DPS-8 Mainframes I worked with nearly
30 years ago (we ran GCOS-8).
My old university had an Pyramid with a normal tape drive - either
way one of my teacher had as his own last year student job being a
system administrator for said machine.
One day he had to restore from backup but finds out that the tape drive
is cranky.
One of his terse comments in the report was:
It is good to fix things immediately when the fault is found - not
waiting until you one day finds out that it is preferable to have said
thing in order.
He had to help the drive start (the drive was sluggish in startup) the
whole evening that day.....
30 Oct
30 Oct
4:27 p.m.
On 10/30/19 2:35 PM, Charles Anthony via cctalk wrote:
For the dps8 emulator, I wrote (for expediency) the
I/O code to complete
immediately.
FWIW, I just uploaded a lot of information on the Honeywell Level 6
minicomputer to bitsavers. I don't know if this is helpful at all for
simulating the comms front-end.
10:11 p.m.
On Wed, Oct 30, 2019 at 9:53 PM Al Kossow via cctalk <cctalk at classiccmp.org>
wrote:
On 10/30/19 2:35 PM, Charles Anthony via cctalk wrote:
Thank you. We are currently simulating the comms front end at the API
level, but there is a lot of interest in doing it at the h/w level.
-- Charles
--
X-Clacks-Overhead: GNU Terry Pratchett
For the dps8 emulator, I wrote (for expediency)
the I/O code to complete
immediately.
FWIW, I just uploaded a lot of information on the Honeywell Level 6
minicomputer to bitsavers. I don't know if this is helpful at all for
simulating the comms front-end.
31 Oct
31 Oct
7:15 a.m.
On Oct 30, 2019, at 10:11 PM, Charles Anthony via
cctalk <cctalk at classiccmp.org> wrote:
Thank you. We are currently simulating the comms front end at the API
level, but there is a lot of interest in doing it at the h/w level.
-- Charles
Unfortunately I sent all my Honeywell documentation up to LCM a few years ago, so no
longer have access to it. If I remember right, they should have some Datanet-8000
documentation.
Zane
9:23 a.m.
On Thu, Oct 31, 2019 at 8:15 AM Zane Healy via cctalk <cctalk at classiccmp.org>
wrote:
Anything from bitsavers relevant?
http://bitsavers.org/pdf/honeywell/
Warner
On Oct 30, 2019, at 10:11 PM, Charles Anthony via
cctalk <
cctalk at classiccmp.org> wrote:
Thank you. We are currently simulating the comms front end at the API
level, but there is a lot of interest in doing it at the h/w level.
-- Charles
Unfortunately I sent all my Honeywell documentation up to LCM a few years
ago, so no longer have access to it. If I remember right, they should have
some Datanet-8000 documentation.
Zane
3:15 p.m.
On Thu, Oct 31, 2019 at 9:23 AM Warner Losh <imp at bsdimp.com> wrote:
On Thu, Oct 31, 2019 at 8:15 AM Zane Healy via cctalk <
cctalk at classiccmp.org> wrote:
Sadly no.
There are two models of FNP, the 355 and the 6661.
The 355 is an 18-bit machine with an architecture very similar to the 635
(and thus its descendent DPS8/M); I tend to think of it as a 635 sawed in
half. The code that runs the 355 is assembled and linked on the Multics
host and downloaded into the 355 at system startup.
We have that source code, and reasonably good documentation on the 355 CPU
and on the Direct Interface Adaptor which connects the 355 to the DPS8/M We
do not have documentation on the I/O controller or on the peripherals, nor
do we any other software (such as diagnostics). The 355 emulator is at the
point where it will run the first few dozen instructions.
The 6661 is built around a Honeywell Level 6 16-bit minicomputer. There is
a lot of documentation on the hardware, but we have no idea how it was
programmed to be an FNP. The 355 18 bit code obviously will not run; so
either there was a 355 emulator running on it, or there was a seperate
firmware program that we do not have.
The 355 I/O controller is probably quite similar the the DPS8/M IOM, and
with some reverse engineering of the firmware, a reasonably correct
implementation could be done. The peripherals (serial i/o multiplexor,
operators console) are conceptually straight forward and should yield to
the same approach.
There are some messy implementation details that need attention, mostly
things like interprocess communication widgets to handle the interrupt
request signals between the FNP and DPS8/M.
What is needed for 355 implementation:
IO controller docs.
HSLA (High Speed Line Adaptor) docs.
Diagnostic software, if it ever existed.
What is needed for 6661 implementation:
A Level 6 emulator.
The FNP software.
-- Charles
Warner
Anything from bitsavers relevant?
http://bitsavers.org/pdf/honeywell/
> Zane
>
>
>
>
>
--
X-Clacks-Overhead: GNU Terry Pratchett
5:41 p.m.
On Oct 31, 2019, at 3:15 PM, Charles Anthony via
cctalk <cctalk at classiccmp.org> wrote:
On Thu, Oct 31, 2019 at 9:23 AM Warner Losh <imp at bsdimp.com> wrote:
Is there any sort of product tree document for Honeywell anywhere online? Honestly even
though I was a Systems Analyst on a DPS-8, and have worked a little with DPS-6?s, they
have an incredibly confusing list of names. :-)
The FNP I?m most familiar with is the Datanet-8. I was trained on the Datanet-8000, but
never used it.
On Thu, Oct 31, 2019 at 8:15 AM Zane Healy via cctalk <
cctalk at classiccmp.org> wrote:
Sadly no.
There are two models of FNP, the 355 and the 6661.
Anything from bitsavers relevant?
http://bitsavers.org/pdf/honeywell/
The 6661 is built around a Honeywell Level 6 16-bit
minicomputer. There is
a lot of documentation on the hardware, but we have no idea how it was
programmed to be an FNP. The 355 18 bit code obviously will not run; so
either there was a 355 emulator running on it, or there was a seperate
firmware program that we do not have.
The 355 I/O controller is probably quite similar the the DPS8/M IOM, and
with some reverse engineering of the firmware, a reasonably correct
implementation could be done. The peripherals (serial i/o multiplexor,
operators console) are conceptually straight forward and should yield to
the same approach.
There are some messy implementation details that need attention, mostly
things like interprocess communication widgets to handle the interrupt
request signals between the FNP and DPS8/M.
What is needed for 355 implementation:
IO controller docs.
HSLA (High Speed Line Adaptor) docs.
Diagnostic software, if it ever existed.
What is needed for 6661 implementation:
A Level 6 emulator.
The FNP software.
It looks like you need a copy of Multics Communications Software (MCS).
Have you seen the following document? It appears to touch on some of your questions.
http://www.bitsavers.org/pdf/datapro/communications_processors/C13-480_Hone…
I think we were using GRTS on GCOS-8, as I remember that name.
It looks like you?d need a copy of the firmware, and a copy of the 8? floppy with system
test and diagnostics programs.
I?ve been trying to remember if we had to do any sort of software load on a Datanet-8, and
I can?t remember needing to do anything like that. Though obviously the Datanet-8 is
newer than a Datanet-6661.
Zane
6:04 p.m.
On Thu, Oct 31, 2019 at 5:41 PM Zane Healy <healyzh at avanthar.com> wrote:
It looks like you need a copy of Multics Communications Software (MCS).
We have MCS for the 355. MCS for the 6661, not so much, but that document
shows
that I can lease it for $275 month, but I can't get through to the
sales department.
Have you seen the following document? It appears to
touch on some of your
questions.
http://www.bitsavers.org/pdf/datapro/communications_processors/C13-480_Hone…
Really no point in pursuing a 6661 emulation unless the MCS software can be
located.
-- Charles
6:13 p.m.
On Oct 31, 2019, at 6:04 PM, Charles Anthony
<charles.unix.pro at gmail.com> wrote:
It looks like you need a copy of Multics
Communications Software (MCS).
We have MCS for the 355. MCS for the 6661, not so much, but that document shows that I
can lease it for $275 month, but I can't get through to the sales department.
Have you seen the following document? It appears to touch on some of your questions.
http://www.bitsavers.org/pdf/datapro/communications_processors/C13-480_Hone…
<http://www.bitsavers.org/pdf/datapro/communications_processors/C13-480_Honeywell_DATANET_6661.pdf>
Really no point in pursuing a 6661 emulation unless the MCS software can be located.
? Charles
So to sum it up, you have the software for the 355, and the documentation for the 6661.
That?s rough. Once again, I find myself wishing more software was preserved and
available.
Another obscure Honeywell tidbit, back around ?93 the DPS-6 was emulated on HP-UX systems.
Part of my very limited GCOS-6 experience was helping to migrate from physical hardware,
to the emulated systems in January of ?94.
Zane
10:20 a.m.
On Thu, Oct 31, 2019 at 7:15 AM Zane Healy <healyzh at avanthar.com> wrote:
Unfortunately I sent all my Honeywell documentation up to LCM a few years
ago, so no longer have access to it. If I remember right, they should have
some Datanet-8000 documentation.
I'm in the Seattle area and have contacts at LCM; I will see if I can get
a
look at it.
-- Charles
4:37 a.m.
On 10/30/19 5:35 PM, Charles Anthony via cctalk wrote:
On Wed, Oct 30, 2019 at 2:17 PM Tapley, Mark B. via
cctalk <
cctalk at classiccmp.org> wrote:
Hi Charles,
I guess it depends on the OS.
For LisaEm, I found that if I did that, it would cause lots of failures
with disk I/O.
So, in my case I keep track of CPUCYCLES since power on in an int64, and
when an I/O event happens, I setup a timer to trigger an IRQ CPUCYCLES+N
later. N varies by device, and I shave down N as close as possible to
not cause issues.
Like in the XKCD, floppy and hard disk access is now ludicrously fast.
The 68000 has 7 levels of IRQs, masked to filter out which it will
allow. Should the IRQLEVEL mask be higher than the IRQ of a device, but
CPUCYCLES>DEVICETIMER, then it will retry again once the mask goes back
down.
Should two device events happen for the same IRQ, it will only generate
one IRQ, and then it's up to the OS to handle the extra I/O for that
device, just as in real life. This shouldn't happen with things like
disk I/O, thought it can for serial port I/O.
So, it's not quite a time series queue, but, kind of.
For things like repeating timers on VIA6522s, or square wave sound
generation from the VIAs, I found that I can't fully get away with tying
their timing to the wall clock rather than the CPUCYCLES clock, so to
make sounds work properly when the user selects a higher CPU clock, I
temporarily slow down the CPU to the original 5MHz while the sound is
playing, and for a little bit longer after that to account for delay
loops between beeps.
Cheers,
-- Ray.
All,
my daughter is well aware of my affinity for old computers and software,
and, as usual, she pointed out that there?s an XKCD for that:
https://xkcd.com/2221/
I found this remarkably accurate.
For the dps8 emulator, I wrote (for expediency) the I/O code to complete
immediately. When the CPU executes an I/O instruction, the I/O is completed
and the interrupt posted before the next instruction is executed. As the
emulator was (at that point) single threaded, there was no performance
reason to do otherwise, and delaying interrupt delivery was additional code
that I didn't want to write and debug. The consensus in the Multics
community was that this was *probably* OK; the interrupt structure was
robust and the interrupt handling code well written, and should be able to
cope. But everytime a runtime failure occured, the question popped up: is
zero-latency I/O the issue? I ended up adding code to delay interrupt
delivery as a run-time configuration option so that that possibility could
be checked.
1:26 p.m.
In my MU5 emulator I have attempted to do all I/O at the speed it would have been done in
the real hardware. Not because I think the OS might be sensitive to it (I don't know
as I don't have any OS running on it), but simply because if/when ever it runs an OS I
want the experience to be as close as possible to what it was originally. I even slow down
the console output to actual Teletype Model 33 speed. I will add options to run at host
machine speed at some point though.
Regards
Rob
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Charles Anthony
via cctalk
Sent: 30 October 2019 21:36
To: Tapley, Mark B. via cctalk <cctalk at classiccmp.org>
Subject: Re: OT(?): Emulation XKCD
On Wed, Oct 30, 2019 at 2:17 PM Tapley, Mark B. via cctalk <
cctalk at classiccmp.org> wrote:
All,
my daughter is well aware of my affinity for old computers and
software, and, as usual, she pointed out that there?s an XKCD for that:
https://xkcd.com/2221/
I found this remarkably accurate.
For the dps8 emulator, I wrote (for expediency) the I/O code to complete
immediately. When the CPU executes an I/O instruction, the I/O is
completed and the interrupt posted before the next instruction is executed.
As the emulator was (at that point) single threaded, there was no
performance reason to do otherwise, and delaying interrupt delivery was
additional code that I didn't want to write and debug. The consensus in the
Multics community was that this was *probably* OK; the interrupt structure
was robust and the interrupt handling code well written, and should be able
to cope. But everytime a runtime failure occured, the question popped up: is
zero-latency I/O the issue? I ended up adding code to delay interrupt
delivery as a run-time configuration option so that that possibility could be
checked.
The XKCD is dead on for me. I have had that conversation.
-- Charles 
12:18 a.m.
On Wed, Oct 30, 2019 at 07:36:18PM +0000, Tapley, Mark B. via cctalk wrote:
All,
my daughter is well aware of my affinity for old computers and
software, and, as usual, she pointed out that there?s an XKCD for
that:
https://xkcd.com/2221/
I found this remarkably accurate.
- Mark
Oh. Gosh. I. cannot. stop. reading. XKCD. again.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
4:05 a.m.
At 02:36 PM 10/30/2019, Tapley, Mark B. via cctalk wrote:
my daughter is well aware of my affinity for old
computers and software, and, as usual, she pointed out that there???s an XKCD for that:
https://xkcd.com/2221/
I found this remarkably accurate.
Does reading this in 1997's Eudora count?
It's been working fine under Windows 7 but now I did an in-place upgrade
to Windows 10 and something in Windows' compatibility emulations
has changed, and now it crashes regularly when I'm composing emails.
- John
1638
days inactive
1642
days old
20 comments
10 participants
participants (10)
-
aek＠bitsavers.org -
charles.unix.pro＠gmail.com -
healyzh＠avanthar.com -
imp＠bsdimp.com -
jfoust＠threedee.com -
mark.tapley＠swri.org -
ray＠arachelian.com -
robert.jarratt＠ntlworld.com -
rtomek＠ceti.pl -
stefan.skoglund＠agj.net