>>>Hi Kevin,
>>>
>>>PMFJI, but what's happening is that the printer driver is setting the math co-processor to a state where the calling application (in this case VFP) is expected to handle division by zero. VFP expects the co-processor to take care of it. See Q183522 in the MS Knowledge base for further details.
>>>
>>
>>That said George, would it be difficult for MS to fix the behavior?
>
>Hi Rick,
>
>I tend to agree with Ed that it would be easier for HP to "fix" the problem than MS. This problem seems to occur most often with HP drivers. MS drivers for HP printers don't cause it, and other printer manufacturers don't seem to follow the practice. Don't forget that there a specs (the DDK) for writing device drivers. While this is conjecture on my part, it appears that HP isn't following the specs.
>
>Having said that, I should also say that it would be nice if VFP would be made a bit more "fault tolerant" (I'm not sure that's exactly the correct phrase, but it seems to fit) so that this sort of thing wouldn't happen.

I think that we see it more because foxpro uses the FPU more than other languages because all numerics are doubles, therefore the fpu is always used. The performance hit for resetting the state of the FPU before every FPU operation would be too great in this case. This is also why Intel Pentiums run foxpro faster than non Intel equivalents, they tend to have faster integer performance and slower FPU performance.