MAX messenger crashes without getting a valid pointer to PersistentZoneIdentifier COM object. Adding a stubbed COM object solves the problem
--
v4: urlmon: Add PersistentZoneIdentifier COM object stubs
https://gitlab.winehq.org/wine/wine/-/merge_requests/8456
MAX messenger crashes without getting a valid pointer to PersistentZoneIdentifier COM object. Adding a stubbed COM object solves the problem
--
v3: urlmon: Add PersistentZoneIdentifier COM object stubs
https://gitlab.winehq.org/wine/wine/-/merge_requests/8456
Fixes gdiplus tests in Clang build.
When the compiler assumes non-trapping floating-point math, it may apply more aggressive optimizations. For example, in the fast path of `GdipInvertMatrix`, it may merge paired divisions into a single `divss` instruction. This can leave unused lanes whose results are ignored, but they still execute and may cause a division by zero, breaking tests that have the FP exception mask enabled.
Using `-ffp-exception-behavior=maytrap` prevents the compiler from performing such transformations.
It's a bit surprising that this flag also disables optimizations like those seen in the dmime tests, so there’s likely room for improvement on the compiler side. Regardless, relying on `round()` in tests isn't valid, as it's not available in msvcrt.dll and may depend on compiler-specific behavior.
--
v2: configure: Build PEs with -ffp-exception-behavior=maytrap.
dmime/tests: Use ceil instead of round.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8474
Fixes gdiplus tests in Clang build.
When the compiler assumes non-trapping floating-point math, it may apply more aggressive optimizations. For example, in the fast path of `GdipInvertMatrix`, it may merge paired divisions into a single `divss` instruction. This can leave unused lanes whose results are ignored, but they still execute and may cause a division by zero, breaking tests that have the FP exception mask enabled.
Using `-ffp-exception-behavior=maytrap` prevents the compiler from performing such transformations.
It's a bit surprising that this flag also disables optimizations like those seen in the dmime tests, so there’s likely room for improvement on the compiler side. Regardless, relying on `round()` in tests isn't valid, as it's not available in msvcrt.dll and may depend on compiler-specific behavior.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8474
On Sun Jun 29 21:51:04 2025 +0000, Mike Kozelkov wrote:
> Sorry, I think I messed up this MR branch, so it can't be merged
> fast-forward-merged. I've created a !8456 merge request for the stubs.
> Also I've implemented a PersistentZoneIdentifier interfaces with test
> cases in !8459, but it's just a mimic the behavior of
> PersistentZoneIdentifier without any writing or reading information
> about the zone. Some test cases fail due to no reading zone information.
Let’s use new MRs for now, but in the future you may use a force push (e.g., `git push -f`).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8378#note_108482
MAX messenger crashes without getting a valid pointer to PersistentZoneIdentifier COM object. Adding a stubbed COM object solves the problem
--
v2: urlmon: Add PersistentZoneIdentifier COM object stubs
https://gitlab.winehq.org/wine/wine/-/merge_requests/8456
Some old applications crash if GL_EXTENSIONS string is longer than a certain limit. There are some vendor-specific environment variable to limit the returned extensions, but it is IMO less convenient to use than a per-application registry setting which can be set once on prefix configuration time.
We have a DisabledExtensions registry key already, this adds a similar EnabledExtensions key that filters the returned extensions to only include those listed in that key, effectively limiting the size of the extensions string.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=25362
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58422
--
v2: opengl32: Add an EnabledExtensions registry option.
opengl32: Add a helper to read OpenGL registry options.
opengl32: Do not filter legacy extensions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8473
Some old applications crash if GL_EXTENSIONS string is longer than a certain limit. There are some vendor-specific environment variable to limit the returned extensions, but it is IMO less convenient to use than a per-application registry setting which can be set once on prefix configuration time.
We have a DisabledExtensions registry key already, this adds a similar EnabledExtensions key that filters the returned extensions to only include those listed in that key, effectively limiting the size of the extensions string.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=25362
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58422
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8473