Newsgroups: comp.windows.ms.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!maytag!watstat.waterloo.edu!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Subject: Re: Windows and Floating Point
Message-ID: <1991Jun3.122324.6264@maytag.waterloo.edu>
Sender: news@maytag.waterloo.edu (News Owner)
Organization: University of Waterloo
References: <1991Jun3.045252.5431@mnemosyne.cs.du.edu>
Date: Mon, 3 Jun 1991 12:23:24 GMT
Lines: 28

In article <1991Jun3.045252.5431@mnemosyne.cs.du.edu> ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes:
>The Problem:  If I leave the program running and shell out to DOS and then
>come back, the Windows program usually crashes, sometimes with a UAE, and
>sometimes with a message like "coprocessor stack underflow".
>
>What's even stranger is that I didn't do any floating point while in DOS-land.
>
>So I tried the following:  in my main event loop (switch statement from HELL)
>I call a routine to reset the 8x87 upon receipt of WM_KILLFOCUS and
>WM_SETFOCUS messages.  The routine is just:
>
>asm fwait
>asm finit
>asm fwait
>
>Result:  I haven't been able to make the problem recur.  Even if I shell out
>to DOS in the middle of a computation, the program doesn't crash when I get
>back.

This fix is a little dangerous.  After the FINIT, the 387 will be configured
to mask all errors:  it won't report problems like stack underflow, it'll just
return NaN as a result.  You should take frequent looks at the status word
to see if any exceptions have occurred if you do this, but watch out:
at least in Turbo Pascal, the sticky bits in the status word aren't sticky. 
The floating point string conversion routines reset them.  BC++ may have the
same bug.

Duncan Murdoch