Date:	Tue, 17 Sep 1996 16:02:04 +0200 (MET DST)
From:	Mark Habersack <grendel AT ananke DOT amu DOT edu DOT pl>
Reply-To:	grendel AT ananke DOT amu DOT edu DOT pl
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de, djgpp-workers AT delorie DOT com
Subject:	Re: DJGPP Installation Diagnostic Program
In-Reply-To:	<9609171345.AA13337@clio.rice.edu>
Message-ID:	<Pine.NEB.3.95.960917155942.21064A-100000@ananke.amu.edu.pl>
MIME-Version:	1.0

On Tue, 17 Sep 1996, Charles Sandmann wrote:

>> Something else has just came to my mind: what if the user runs djverify on 286
>> or 86 machine. I mean, I have never run any DJGPP program on such. Does the
>> stub say something?
>
>The stub notices that 32-bit DPMI is not available, tries to load CWSDPMI,
>which does the processor type test, then issues a message if the machine
>doesn't have enough bits ...  Then the stub fails with a No DPMI message.
Well this is a little messy, I think. Shouldn't the processor-check code be
moved to the stub? If it detects a pre-i386 CPU it should gracefully terminate
with nice message.

>Both CWSDPMI and the stub are 8088 clean (well, they have been at times,
>who knows this week) up to the 80386  processor test.
>
>I haven't checked PMODE to see if it's 8088 clean or how it behaves on
>an XT.  When you mess up and get a 186+ instruction in the code it just
>hangs on an XT...
So, at least, for diagnostic program such behavior is unacceptable.

**********************************************************************
So if you ask me how do I feel inside, I could honestly tell you we've
been taken on a very long ride. And if my owners let me have free time
some day, with all good intention I would probably run away!
Clutching the short straw...
******************* http://ananke.amu.edu.pl/~grendel ****************

- Raw text -