Xref: utzoo alt.msdos.programmer:732 comp.sys.ibm.pc:38474 comp.lang.fortran:2689
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!watmath!maytag!watstat!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc,comp.lang.fortran
Subject: Re: MS Fortran bug
Summary: I found the bug, and have a patch
Message-ID: <864@maytag.waterloo.edu>
Date: 20 Nov 89 02:26:32 GMT
References: <863@maytag.waterloo.edu>
Sender: daemon@maytag.waterloo.edu
Reply-To: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Organization: U. of Waterloo, Ontario
Lines: 36

In article <863@maytag.waterloo.edu> I wrote:
>
>The following little program crashes an XT clone with an 8086/8087.  

It turned out to be a bug in the run-time library routine __init80x87.
It had the sequence
  FSTCW  [BP-4]
  FNINIT
  MOV    CX,01Eh
  LOOP   in place
What happens on an 8087 is that the FNINIT aborts the FSTCW instruction, and 
the control word never got stored.  Later on a garbage control word was loaded
and the system crashed.  A fix that seems to work is to put the delay loop 
before the FNINIT.  I'm not sure what the original programmer would have 
been thinking of writing it this way; the next instruction is an arithmetic
one that is preceded by a WAIT anyways.

To patch the library LLIBFOR7.LIB, search for the original bytes

  9B D9 7E FC     
  DB E3
  B9 1E 00
  E2 FE

and replace them with

  9B D9 7E FC     ; no change
  B9 1E 00        ; line 3 above
  E2 FE           ; line 4 above
  DB E3           ; line 2 above

In my copy of the library the first 6 bytes of the original gave a unique search
string.  I'd guess it's safe to do the same patch on any other library; the 
original code would never make sense.

Duncan Murdoch