Message-Id: <9712091620.AA06288@gcef.gc.maricopa.edu>
Date: Tue, 9 Dec 1997 09:20:41 -0700 (MST)
From: "Joshua James Turpen" <44699 AT ef DOT gc DOT maricopa DOT edu>
To: djgpp AT delorie DOT com
Subject: Re:  Win95 and ___djgpp_hw_exception...
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.


Ok, I've rewritten the program to use 
_crt0_startup_flags =_CRT0_FLAG_LOCK_MEMORY;


It still crashes.  


Josh Turpen
44699 AT ef DOT gc DOT maricopa DOT edu