On Sun Apr 20 21:04:37 2025 +0000, Alexandre Julliard wrote:
The problem is that it's not unlikely that some app currently works because we don't report failure. So we shouldn't change everything to report errors just because the spec says so. Only cases that demonstrably fix an actual app should be changed.
WinIO is expecting the carry flag to be set on DPMI failure, otherwise it will segfault on pseudo-random address dereference. SysToolsLib is also expecting the carry flag to be set on the failure. And lspci contains workaround for this "buggy" wine DPMI behavior. The workaround for windows version of lspci was added there by me because of this bug which was causing segfault. Note that I have also checked the Windows 7 behavior and it is also setting the carry flag for physical address mapping request (Windows 7 does not support DPMI physical address mapping functionality).
I highly doubt that some application can work when is asking for physical address mapping and wine returns bogus address instead of failure. If application is asking for physical address mapping then application would want to access that mapped address. And accessing the returned bogus address returned by wine will cause segfault of application.