Date: Sat, 22 Apr 2000 05:35:39 -0400 (EDT)
Message-Id: <200004220935.FAA18388@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: Andrew Hakman <hakmana AT hotmail DOT com>
CC: djgpp AT delorie DOT com
In-reply-to: <3900B453.F41CC292@hotmail.com> (message from Andrew Hakman on
	Fri, 21 Apr 2000 20:05:18 GMT)
Subject: Re: 387 page fault thing
References:  <3900B453 DOT F41CC292 AT hotmail DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Andrew Hakman <hakmana AT hotmail DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Fri, 21 Apr 2000 20:05:18 GMT
> 
> I was just wondering, because the original library works fine, then I
> went and changed it (added the 3 doubles that are now causing the grief)
> is there something that would have to be changed in allocating the
> callback, or the callback itself because now more memory is involved for
> the extra doubles

It's actually quite possible that you cannot use FP emulation inside a
callback.  The emulator works by invalidating the DS selector, which
triggers an exception (a GPF).  That exception is then converted to a
signal which longjmp's to the emulation code.

This could cause trouble when used from a callback, because a callback
runs in a special (and quite fragile) environment.  In particular, all
code and data that is run by a callback need to be locked.  That's why
I advised to link the emulator as a library and set the
_CRT0_FLAG_LOCK_MEMORY bit.  Strangely, it didn't help in your case...

One thing to try would be to not use FP math at all in the callback.
You could try replacing it with fixed-point computations; perhaps that
will make the problem go away.

> If it would help at all, I could probably send you a couple of the
> boards I'm using (I've got lots).

Tanks, but I won't have time to work on this.  Sorry.