Date:	Tue, 2 May 2000 14:28:58 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: interrupt 0x75 limitation in Win95 ?
In-Reply-To:	<200005020750.JAA29985@cerbere.u-strasbg.fr>
Message-ID:	<Pine.SUN.3.91.1000502142034.22132K-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 2 May 2000, Pierre Muller wrote:

> >Yes, it looks like Windows doesn't support FP exceptions in nested
> >DPMI programs; the exception seems to be delivered to the parent
> >instead.
> >
> >If the parent program is a 16-bit real-mode program or COMMAND.COM,
> >the FP exception does happen in the program that divides by zero, but
> >if COMMAND.COM is invoked from a DJGPP program, the exception is also
> >lost.
> 
>    If the exceptions are not disabled by a call to djgpp_exception_toggle
> before calling COMMAND.COM then the first DJGPP program recieves  
> the exception !

That's what I said (above): the exception goes to the parent.

>    This Win95 limitation can be important for programs using C++ exceptions !!

How are C++ exceptions related to this issue?  I don't think they use the 
FP exception or signals, do they?

>   There is probably a way to overcome this limitation but it requires to 
> hook int 0x31 to catch the set_pm_interrupt for interrupt 0x75 and to
> redispatch the pseudo-exception according to the %cs in the exception 
> address.

I don't think I understand what you are suggesting.  Which program should 
hook Int 31h, and what should it do?

As far as I understand, the problem here is that the program which 
divides by zero doesn't even know about the FP exception, so it will
not be able to do anything about it.  How will hooking Int 31h change 
that?

If you are concerned about the parent program that wants to avoid being 
aborted by a SIGFPE which belongs to its child, then the solution is 
simply to say "signal (SIGFPE, SIG_IGN);" before invoking the child.  
DJGPP in general tries to set things up so that the signals are passed to 
the parent programs as well.  Usually, this only happens with SIGINT and 
SIGQUIT, but it seems like in this case, SIGFPE also behaves in a similar 
manner.  Programs which run other programs should be written to deal with 
that possibility.

- Raw text -