www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/20/11:03:37

Message-ID: <E1FF8239A075D311AF7200A0C9D60AE31415A9@probe-2.acclaim-euro.net>
From: Shawn Hargreaves <SHargreaves AT acclaimstudios DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: spawnvpe hanging and bash GPF after running non-DJGPP exe
Date: Wed, 20 Oct 1999 09:51:33 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Reply-To: djgpp AT delorie DOT com

Charles Sandmann writes:
> 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.

I suspect that almost all Watcom/DOS4GW programs will be doing things
like this, for the very simple reason that the Watcom docs don't bother
to explain that you are supposed to do these things. They even give
example code for a mouse handler which does no locking at all, and only
in a tiny footnote in a section about making direct DPMI calls (which
they don't even have a libc wrapper for) do they bother to mention that
you are strictly speaking supposed to lock any memory that you use in
these contexts. When porting Allegro to it, it took me a long time to 
realise that it wasn't just automatically locking all RAM in some way,
and I was coming from a djgpp background. In other words, chances are
very good that most Watcom programmers are totally unaware of this whole
issue, so that all Watcom programs will have problems in this area.


	Shawn Hargreaves.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019