Date: Tue, 2 May 2000 14:28:58 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Pierre Muller 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.