🚀 go-pugleaf

Hi everybody,

A couple of weeks or so ago I posted a pair of articles
concerning problems I have encountered with version 7 of the
Microsoft C compiler.  Since then, several people (you know
who you are 8-)) have asked to be kept advised.   Hence the
post.

It turns out there was some confusion between the two groups
of Microsoft people I was speaking to, the compiler group and
some folks from the Windows team.  Here are the facts:

1) The new version of win87em.dll, to be released by
   Microsoft (the new version will placed on CompuServe) does
   *not* require INT 3D's in your code to function correctly.
   If a floating point exception (interrupt 16) occurs,
   win87em.dll handles it by:

   a) storing the code at the CS:IP that caused the
      exception,
   b) overwriting the code with an INT 3D,
   c) returning control to your app,
   d) your app will now immediately execute the INT 3D, which
      is also handled by win87em.dll,
   e) win87em.dll restores the saved code and takes the
      appropriate action for the exception.

2) C7.0 *does* have a bug in the "fast mode compiler".  The
   fast mode compiler is used when you specify -Od (no
   optimizations), which is what most folks do for debug
   code.  It can also be explicitly invoked with the -f
   switch.  The fast mode compiler treats -FPi87 the same as
   -FPi, i.e. you get a bunch of INT 3D's after the code
   segment has been loaded.  If you want to continue to use
   -Od, you can explicitly turn off the fast mode compiler
   with the apparently undocumented -f- switch.

One more point to mention is that after the loader patches
-FPi code with a bunch of INT 3D's, the new win87em.dll will
unpatch them the first time they are executed.  So even code
that does not presume a floating point processor can achieve
speed very close to code that does, when a FPU is present.

cheers - Paul.