From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9910200326.AA12536@clio.rice.edu>
Subject: Re: spawnvpe hanging and bash GPF after running non-DJGPP exe
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Tue, 19 Oct 1999 22:26:56 -0600 (CDT)
Cc: drib AT enteract DOT com, djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.991019101602.12301G-100000@is> from "Eli Zaretskii" at Oct 19, 99 10:16:52 am
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
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

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

At one time (r1 or something) I tested CWSDPMI with DOOM (built with
some version of DOS4GW) and DUKE Nukem 3D.  I found *LOTS* of bugs in
the DPMI calls the extender made.  I added workarounds to get these games
to both run.  I found problems like unlocked mouse handlers, locking
unallocated memory, setting illegal exceptions, etc.

Since that very early testing, I haven't tested again (and there have been
lots of fixes/enhancements since then which might change behavior).

I came to the conclusion that I didn't want to waste my time working around
a commercial compiler's bugs, especially when I didn't think anyone would
run that way (under CWSDPMI) anyway.  Getting DOOM and Duke working once
found bugs in CWSDPMI, was a good stress test, but I'm not sure it's worth
going through several 100K of DPMI calls to find the ones which were the
root cause of the bugs and trying to add workarounds to CWSDPMI to fix them.

By the way - one of the ugliest things I found was the extender calling
a software int to trigger the hardware int handler - which was hard to
distiguish from an exception ...