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?
Regards, Fabian Maurer
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 :-/
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 :-/
On Mon, Jan 31, 2022 at 11:45 AM Fabian Maurer dark.shadow4@web.de wrote:
It's still the case that we can't really write tests for Win16, correct?
Currently not in tree; some people have made standalone tests (either attached to bugzilla tickets, or https://github.com/austin987/win16test).
The main blocker is the lack of a LGPL compatible compiler. Openwatcom can compile win16 binaries, but the license isn't compatible, but last year SAP (current owner of the original codebase) have agreed to relicense it, so there may be hope in the future: https://github.com/open-watcom/open-watcom-v2/discussions/271#discussioncomm...
Am Montag, 31. Jänner 2022, 21:47:41 EAT schrieb Austin English:
On Mon, Jan 31, 2022 at 11:45 AM Fabian Maurer dark.shadow4@web.de wrote:
It's still the case that we can't really write tests for Win16, correct?
Currently not in tree; some people have made standalone tests (either attached to bugzilla tickets, or https://github.com/austin987/win16test).
In a recent hacker news discussion I came across the Digital Mars C++ compiler: https://digitalmars.com/ctg/win16-programming.html , https:// github.com/DigitalMars/dmc . Boost license, which I don't really know, but FSF says it's GPL compatible: https://www.gnu.org/licenses/license-list.html#boost
The main blocker is the lack of a LGPL compatible compiler. Openwatcom can compile win16 binaries, but the license isn't compatible
I don't really understand why that is. I mean, Wine isn't distributing the compiler? Or is the point that it's hard to get distros to ship openwatcom packages due to the license?
Regards, Fabian Maurer
* On 2022-01-31 22:18, Fabian Maurer wrote:
The main blocker is the lack of a LGPL compatible compiler. Openwatcom can compile win16 binaries, but the license isn't compatible
I don't really understand why that is. I mean, Wine isn't distributing the compiler? Or is the point that it's hard to get distros to ship openwatcom packages due to the license?
IIRC the issue of the non-friendly license was that almost nobody was packaging / maintaining it on mainstream distros.
Quick Google query says it's still probably the same: https://github.com/open-watcom/open-watcom-v2/discussions/487
Here I get only packages for Arch Linux and Haiku: https://repology.org/project/openwatcom/versions https://repology.org/project/openwatcom-v2/versions
On the other hand, snap version seems to be available: https://snapcraft.io/open-watcom
S.
Am Montag, 31. Jänner 2022, 20:45:38 EAT schrieb 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?
None that I know of, but I also didn't search extensively. I came across it when toying around with dosemu2 for fun: https://github.com/dosemu2/dosemu2/ issues/976 .
https://stackoverflow.com/questions/10511506/old-16-bit-application-causing-... talks about the issues with modern CPUs.
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.
They added quite a chunk of code Wine does not have re x87 exceptions. https://github.com/otya128/winevdm/blob/master/win87em/win87em.c#L199 is the most obvious tip of the iceberg, but I guess there is more stuff hidden in their DPMI interrupt code.
On 1/31/22 11:45, Fabian Maurer wrote:
It's still the case that we can't really write tests for Win16, correct?
For what it's worth, I've been working on a scheme to allow 16-bit tests using extensive generated between 16-bit and 32-bit code. I have a proof of concept, but I haven't come close to finishing the thunking generation yet, and I haven't got time to work onit recently...
Just figured I'd throw that out there as well since we're discussing compilers.
-
Austin English -
Fabian Maurer -
Saulius Krasuckas -
Stefan Dösinger -
Zebediah Figura