Xref:	news2.mv.net comp.os.msdos.djgpp:1762
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: floating p. exception behaves strange
Date:	Thu, 07 Mar 1996 22:38:33 CST
Organization:	Rice University, Houston, Texas
Lines:	26
Message-ID:	<313fb9c9.sandmann@clio.rice.edu>
References:	<9603070902 DOT AA07840 AT tntnhb3 DOT tn DOT tudelft DOT nl>
Reply-To:	sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host:	clio.rice.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> But there is more: if I run the program twice, it behaves the second time
> precisely like it did the first time (on the 386 and 486). 

This is how it should behave if the DPMI provider handles the FPU properly.

> However, on the Pentium (using Win95), the program immediately quits with 
> "signal SIGFPE" the second time it is run. 

This is a problem that has been reported to me, but I do NOT see it on my
Win95 box.  I also had an identical report under WFW 3.11, but the problem went
away when the user quit running one of his other non-DJGPP Win applications.

In any case, this is a Microsoft DPMI bug, since it is generating an FPU
exception on an instruction which explicitly says do not generate exceptions
while initializing the FPU.  So, their FPU task emulation stuff is buggy (at
least in combination with some other software).

When I tried to code a workaround - it would sometimes generate a second
SIGFPE just trying to re-initialize the FPU immediately after the exception!
(causing a loss of the FPU signal information and other problems).

I'm tired of writing code to work around bugs for a company which makes
Billions of dollars selling buggy software.  You paid for W95, try to get
Microsoft to send you a patch.  Else, establish a signal handler for SIGFPE
and try to handle the nested exceptions which get generated, and do what
you feel needs to be done.

- Raw text -