Date: Tue, 19 Oct 1999 10:16:52 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Dave Dribin cc: djgpp AT delorie DOT com, Charles Sandmann Subject: Re: spawnvpe hanging and bash GPF after running non-DJGPP exe In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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?