Date: Tue, 9 Dec 1997 13:17:45 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Joshua James Turpen <44699 AT ef DOT gc DOT maricopa DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: Win95 DPMI and ___djgpp_hw_exception
In-Reply-To: <9712090224.AA26406@gcef.gc.maricopa.edu>
Message-ID: <Pine.SUN.3.91.971209131723.7213J-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 8 Dec 1997, Joshua James Turpen wrote:

> This is a very scary bug.  If it does turn out to be a bug in Win95 DPMI,
> it's really going to hurt DJGPP, since the ___djgpp_hw_exception trick is
> the basis of signals under DJGPP.

There's a long way before you come to such an extreme conclusion.  See
below.

> static void top_of_vars() {};
> int tick;
> int old_sel, old_off;
> static void bottom_of_vars() {};

Who said you can lock variables in this manner?  Functions go into a
different segment than the variables (CS vs DS), so you cannot lock
data with this trick.  I think what happens is that old_sel and
old_off wind up not locked, and your interrupt handler touches them.

Please note that the DJGPP FAQ specifically advises to debug hardware
interrupt handlers by first locking all of the memory with the crt0
flag (see section 18.9 of the FAQ), because then you *know* everything
is locked, including the stack.  That advice was born out of a lot of
crashes and other disasters; please use it.  Only *after* your handler
works with everything locked should you move to selectively locking
only what's needs to be locked.