>>>I wish it was the case, but I've seen this problem with a couple of the newer DeskJet models at customer sites. The same fixes seemed to work with them, too - use an older, compatible driver from an operating system distribution rather than from HP directly, or use _fpreset().
>>
>>Hi Ed,
>>
>>Thanks for the heads up. My question is does it happen on just a listing or only when there are mathematical operations involved?
>
>I don't really know; at least in theory, any print formatting operation may be making use of the FPU, and if you don't take care to preserve the state of the FPU, the floating point registers and control registers might not be set properly after a task switching operation by the operating system. It's been a while since I looked in detail at the problems of preserving the FPU state during task switches, but I do know where to go if you want to explore it in greater detail, The Intel Secrets Home Page; a great resource devoted to covering many things that Intel might prefer us all to remain blissfully ignorant of. It covers Intel processor errata, extended and undocumented op codes and states, and some humerous anti-Intel artwork...

Hi Ed,

So what you're saying is that the HP drivers aren't restoring the state of the FPU and when VFP sends some number or field divided by zero, the FPU throws the exception to VFP (which isn't expecting it) and...KABOOM. Is that right?