From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9609300343.AA13628@clio.rice.edu>
Subject: Re: Stub error messages (Was: Re: 'Cannot open')
To: fighteer AT cs DOT com
Date: Sun, 29 Sep 1996 22:43:32 -0600 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com
In-Reply-To: <324EDEAA.23AF@cs.com> from "John M. Aldrich" at Sep 29, 96 01:40:10 pm
Content-Type: text
Content-Length: 2973      

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

You can't create this path condition - you must boot a floppy without
a path statement to have it set up that way.  It's a DOS bug that it 
creates an environment variable with an assignment of zero length.  If
you issue the SET command and see "PATH=" (nothing following) then this 
is the appropriate problem case.  Trying to set a zero length PATH will
normally remove it completely, so you wouldn't see the problem.

> I do not fully understand the possible causes of three of those errors:
> Load error:  can't switch modes.

Tried to switch into PM via the DPMI API, and it returned an error.  This
could be due to nesting too deeply (I've see this with QDPMI), or if a 
16-bit DPMI client was previously loaded and we are nesting under that
client (it will fail our 32-bit request).

> Load error:  no DPMI selectors.

The allocate DPMI selector call failed.  Probably due to nesting too
deeply, or the DPMI is scrogged.

> Load error:  no DPMI memory.

The allocate DPMI memory call failed.  The program is too big for the
available DPMI memory (more paging space is needed, or more physical memory,
or less nesting, or any one of things that cause memory to be used up).

> what is the error that is supposed to be triggered by having a pre-386 CPU?  

You will be unable to load a 32-bit DPMI provider.  On a 8086, you won't
ever find a DPMI, and if you try to load CWSDPMI, it will tell you that
you need a 386, fail to load, then the stub will say no DPMI.  On an 80286
it's possible to have 16-bit only DPMI, which we would ignore and try to
load CWSDPMI, with the same results as above.

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

CWSDPMI r1 had a bug in it that it used a 80286 instruction before it
had done the machine type detection, so would hang instead of printing
the message.  I believe that's been fixed, but I don't have any machines
to test these things on anymore.  I thought someone sent me a message saying
it worked with CWSDPMI r2 (and I think the stub was clean).  I don't know
if anyone has checked r3.

Sorry if I haven't been more helpful, but I've been very sick this week
with the flu (still not well) and I have some important things which must
be handled at work which are the only priority for me right now.