Message-ID:	<324EDEAA.23AF@cs.com>
Date:	Sun, 29 Sep 1996 13:40:10 -0700
From:	"John M. Aldrich" <fighteer AT cs DOT com>
Reply-To:	fighteer AT cs DOT com
Organization:	Three pounds of chaos and a pinch of salt
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>,
	DJGPP Workers Mailing List <djgpp-workers AT delorie DOT com>
Subject:	Stub error messages (Was: Re: 'Cannot open')
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 960929101740 DOT 20703J-100000 AT is>

[DJVERIFY progress report:  I have altered the stub to emit error codes
for various failures, and written a batch file to interpret these.  The
program itself is now capable of running in all three modes and dumping
a bug report.  I am working on test program compilation right now.  I
still need information on how to verify the system memory
configuration.]


Eli Zaretskii wrote:
> 
> On Thu, 26 Sep 1996, John M. Aldrich wrote:
> 
> > Is it a good idea to mention this problem in the batch file's report, or
> > can I assume that it will be corrected in a later DJGPP version?
> 
> IMHO, you should mention it, for those who have `djverify' but still work
> with binaries from DJGPP releases where the stub still had this bug.

Remember, my batch file will only work if the stub has been altered to
emit the right error codes.  Since only _my_ custom stub will do this,
using the batch file on any other program is doomed to failure.  I would
write a program to interpret the error messages themselves, but such a
program would, obviously, have to be written with a compiler other than
DJGPP, all of which I discarded when I obtained the latter.  :)  If
someone would like to undertake such a task, I'd welcome their support.

If you like, I can post the batch file on djgpp-workers to show you what
I've done, along with the diffs for stub.asm.

> > Alternatively, should I wait to release djverify until Charles releases
> > the corrected stub, and use that instead of the v2.0 one?
> 
> It's a simple one-liner to correct it, so you might as well correct it
> now on your machine.

I tried putting in the line that Charles recommended, but oddly it
didn't seem to make a difference.  I tested stubs both with and without
the modification after removing my PATH variable, and both seemed to
exhibit the same behavior.  Do I have to do a PATH-less boot to make the
problem show up, or is it sufficient to just type SET PATH= from DOS and
try it then?  Also, does it make a difference if the stub is by itself
or attached to an actual image?  As I said, I haven't done extensive
testing of this; I'll try more later.  :)

Finally, since this is going to Charles, I have another question.  I
have implemented error codes for each of the ten possible errors that
the stub code can possibly emit.  However, I do not fully understand the
possible causes of three of those errors:

Load error:  can't switch modes.
Load error:  no DPMI selectors.
Load error:  no DPMI memory.

While I more or less understand what those messages mean, I don't know
exactly what could bring them about, or how to solve the problem.  As it
is, I just have a message saying essentially, "Your system is screwed up
- contact the newsgroup."  :)  Also, what is the error that is supposed
to be triggered by having a pre-386 CPU?  I recall a flap a while ago
that said that there is an bug in the stub that causes it to crash
instead of emit an error for this case, but I don't know what the
original error message was supposed to be.  Is that what "can't switch
modes" means?

Thanks for all your help!

-- 
---------------------------------------------------------------------
| John M. Aldrich, aka Fighteer I  |        fighteer AT cs DOT com         |
| Plan:  To find ANYONE willing to |   http://www.cs.com/fighteer   |
| play Descent 2 on DWANGO!        | Tagline: <this space for rent> |
---------------------------------------------------------------------

- Raw text -