Xref: news2.mv.net comp.os.msdos.djgpp:1762 From: Charles Sandmann 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.