Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!shelby!portia.stanford.edu!sunrise!toye
From: toye@sunrise.stanford.edu (George Toye)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Missing INFOP100 part 3/3
Message-ID: <1990Aug18.221135.21163@portia.Stanford.EDU>
Date: 18 Aug 90 22:11:35 GMT
References: <1990Aug13.152727.10634@IRO.UMontreal.CA> <2210019@hpausla.aso.hp.com>
Sender: news@portia.Stanford.EDU (USENET News System)
Organization: Stanford University
Lines: 23

In article <2210019@hpausla.aso.hp.com> dak@hpausla.aso.hp.com (Dave Kruger) writes:
>Andrew Rossmann <andyross@ddsw1.MCS.COM> writes in comp.binaries.ibm.pc.d:
>>   Infoplus version 1.25 is now avilable on SIMTEL20. It is there as:
>> PD1:<MSDOS.INFO>INFOP125.ZIP
>
>I obtained version 1.25 from Simtel20.  Unfortunately, it *still* hangs my
>25MHz 386 (HP Vectra RS/25C) when it gets to Page 2.  It gets past the "CPU:"
>prompt, but hangs on the "Coprocessor:" prompt five lines later.  (I don't
>have a coprocessor.)  Even CTRL-ALT-DEL doesn't work.
>Dave K.

I have found that all versions of this software derived from SYSID 4.4 on
ward has similar problems on many 386 and 386sx machines without coprocessors.
It is as DAK@hp describes ... the code which tries to determine the math
coprocessor type causes these machines to hang.  (NOTE: SYSID 4.3 implements
this part of the code differently and works just fine.)  Is there some
common element to the systems that hang ... like all use AMI BIOS?  They do
not safely return from a math coprocessor exception caused by a missing 387
(uninitialized vector or hardware design)?
The machines that I have encountered so far with this problem have in common
the AMI BIOS.  Does everyone with AMI BIOS, no 387 have similar results?

	-George Toye