Bug 52488, floating point denormal exception

[Fabian Maurer]

Hello Stefan,

Of course it couldn't be easy..

> Netscape 4 is the application where I came across the problem. Microsoft has
> some floating point sample applications that also show the issue.

Do we have a bugreport for those already?

> The correct thing would be to bring
> the Win16 float exception handling code from winevdm back to Wine.

Their implementation actually isn't too different from Wine's, unless you mean 
the part where they use the MAME emulator.

I'd like to help, but the problem is that I don't really understand what's 
going on. We have a similar bug (34867) where we have a divide by zero that's 
not handled properly. And advice an how to proceed?

It's still the case that we can't really write tests for Win16, correct?

Regards,
Fabian Maurer

On Montag, 31. Januar 2022 10:52:51 CET you wrote:
> Am Montag, 31. Jänner 2022, 01:14:25 EAT schrieb Fabian Maurer:
> > Hello wine-devel,
> > 
> > attaching a patch that works around a floating point issue, this is how
> > they do it on otya128/winevdm, the win16 wine fork.
> > Is this the correct way to do it, or why does Wine code do what it does?
> 
> A while back (circa 2019 I think) I spent some spare time learning about
> Win16 and came across floating point exceptions. Wine has pretty much no
> handling of float exceptions. To make matters worse, new-ish CPUs have bugs
> / features that break things. I think Sandy Bridge and newer Intel CPUs set
> the %cs segment to 0 in fxrstor. That breaks a pile of Win16 applications
> even when run inside a virtual machine (but not when run inside a full CPU
> emulator).
> 
> Netscape 4 is the application where I came across the problem. Microsoft has
> some floating point sample applications that also show the issue.
> 
> So to answer your question: I don't really know, but I suspect the patch
> just hides the real problem by luck. The correct thing would be to bring
> the Win16 float exception handling code from winevdm back to Wine. I don't
> know how correct it is though. And on top of that try to find workarounds
> for whatever CPU errata there are nowadays :-/