Date:	Tue, 19 Oct 1999 10:16:52 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Dave Dribin <drib AT enteract DOT com>
cc:	djgpp AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject:	Re: spawnvpe hanging and bash GPF after running non-DJGPP exe
In-Reply-To:	<Pine.NEB.3.96.991018194616.27526A-100000@shell-3.enteract.com>
Message-ID:	<Pine.SUN.3.91.991019101602.12301G-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 18 Oct 1999, Dave Dribin wrote:

> > Try to find a different (newer?) version of PMODE/W.  If PMODE/W is
> > actively supported by its vendor, try mailing them or looking at their
> > Web site.
> 
> No go.  Couldn't find anything newer than 1.33.  I did find older
> versions, though.

I think some older version of DOS4GW was tested with CWSDPMI and
worked.  Charles, do you remember what version was that?

Would PMODE/DJ help here?  I mean stubediting Bash to use PMODE/DJ 
instead of CWDSDPMI.  (This is probably not such a good idea, because
there's no virtual memory, and due to problems with Ctrl-C, but
perhaps it is worth checking?)

> I did manage to rebind the EXE against DOS4GW 1.97.  It runs from a
> straight DOS shell, but now crashes right away when launched from
> bash.  Bash doesn't die this time, but the program is never run.
> Here's the dump:
> 
> DOS/4GW Protected Mode Run-time  Version 1.97
> Copyright (c) Rational Systems, Inc. 1990-1994
> DOS/4GW error (2001): exception 0Eh (page fault) at 25F:102DEFFB
> TSF32: prev_tsf32 5290
> SS       267 DS       267 ES       267 FS         0 GS        E7
> EAX        0 EBX 102E9960 ECX 102E9B60 EDX 102E97C4
> ESI 102E9B78 EDI 102E9CB0 EBP 102EA068 ESP 10662B44
> CS:IP  25F:102DEFFB ID 0E COD        6 FLG    13246
> CS=  25F, USE32, page granular, limit FFFFFFFF, base        0, acc CFFB
> SS=  267, USE32, page granular, limit FFFFFFFF, base        0, acc CFF3
> DS=  267, USE32, page granular, limit FFFFFFFF, base        0, acc CFF3
> ES=  267, USE32, page granular, limit FFFFFFFF, base        0, acc CFF3
> FS=    0, USE16, byte granular, limit        0, base        0, acc  0
> GS=   E7, USE16, byte granular, limit     FFFF, base    46A90, acc F3
> CR0: unavailable
> Crash address (unrelocated) = 1:00009FFB

I cannot make anything out of this.  Sorry.  Charles, can you see
something interesting (except for the fact they use -1 as segement
limit)?

> > Sadly, no.  Since restoring an interrupt vector requires a call to
> > another function of Int 31h, this is a catch-22.
> 
> Darn!  Well how does this program trample Int 31h?  If they can
> trample it, can't I restore it?

A program that hooks Int 31h usually saves the old Int 31h handler in
some variable.  It then can call that old handler directly, e.g. to
restore the old handler.  But once it exits without restoring the old
handler, an external program has no way of doing this, because the
variable holding the old handler is gone.

> Hmmm...  it's looking like the only way to do this is to write a
> 16-bit real mode application?  What tools are available for this kind
> of task?  Only NASM?

You can also use djasm.

Why do you need to launch the game from a DJGPP program?  Perhaps the
problem you are trying to solve can be solved in a different way?

- Raw text -