June 2026 - Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/1] MR11279: oleview: Avoid heap-use-after-free when reloading (ASan). - approved
by Alexandre Julliard (＠julliard) June 29, 2026

June 29, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11279

1 0

Re: [PATCH v2 0/1] MR11266: dwrite: Fix Miscellaneous Symbols font fallback. - approved
by Alexandre Julliard (＠julliard) June 29, 2026

June 29, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11266

1 0

Re: [PATCH v2 0/1] MR11277: d2d1: Free the vertex types array in d2d_figure_cleanup. - approved
by Alexandre Julliard (＠julliard) June 29, 2026

June 29, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11277

1 0

Re: [PATCH v2 0/1] MR11275: server: Fix a memory leak in d3dkmt_share_objects. - approved
by Alexandre Julliard (＠julliard) June 29, 2026

June 29, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11275

1 0

Re: [PATCH v2 0/4] MR10967: Prefer builtin for d3d helper libraries.
by Tim Clem (＠tclem) June 29, 2026

June 29, 2026

> Do we already have WineHQ bugs for each issue? There are internal CW bugs. > Also, do all of those games actually come with their own copy of d3dcompiler_xx.dll / d3dx\*.dll? Yes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10967#note_144464

1 0

Re: [PATCH v2 0/4] MR10967: Prefer builtin for d3d helper libraries.
by Matteo Bruni (＠Mystral) June 29, 2026

June 29, 2026

On Mon Jun 29 19:15:09 2026 +0000, Tim Clem wrote: > Right, clearly we'd like to find these sorts of issues, but to me it's a > question of whose responsibility that is. Do we want to break things > widely and at random and let users deal with the frustration? Or should > we, the developers, be seeking out games that ship their own d3d > libraries and setting builtin overrides to see what happens? > > only ID3DXEffectCompiler looks annoying, because it will need > substantial amount of changes, to get it right. > That's the sort of thing I worry about - that's sounds like something > that will be broken for a while, which means we're effectively requiring > that users tinker with DLL overrides to get something working that used > to be fine out-of-the-box. Do we already have WineHQ bugs for each issue? Also, do all of those games actually come with their own copy of d3dcompiler_xx.dll / d3dx*.dll? Ideally we'd fix most of the new issues before Wine 12 is out. In the meantime, downstream is certainly free to revert this, but better yet would be to help with the fixing, as that will actually move Wine's implementation forward and help with other games requiring the same features. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10967#note_144463

1 0

Re: [PATCH v2 0/4] MR10967: Prefer builtin for d3d helper libraries.
by Tim Clem (＠tclem) June 29, 2026

June 29, 2026

On Mon Jun 29 19:04:33 2026 +0000, Nikolay Sivov wrote: > Otherwise we'll never learn about those issues and it will never get > fixed. It will be easy to revert for the next major release, if it comes > to that. > From this list only ID3DXEffectCompiler looks annoying, because it will > need substantial amount of changes, to get it right. Right, clearly we'd like to find these sorts of issues, but to me it's a question of whose responsibility that is. Do we want to break things widely and at random and let users deal with the frustration? Or should we, the developers, be seeking out games that ship their own d3d libraries and setting builtin overrides to see what happens? > only ID3DXEffectCompiler looks annoying, because it will need substantial amount of changes, to get it right. That's the sort of thing I worry about - that's sounds like something that will be broken for a while, which means we're effectively requiring that users tinker with DLL overrides to get something working that used to be fine out-of-the-box. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10967#note_144462

1 0

Re: [PATCH v2 0/4] MR10967: Prefer builtin for d3d helper libraries.
by Nikolay Sivov (＠nsivov) June 29, 2026

June 29, 2026

On Mon Jun 29 19:04:33 2026 +0000, Tim Clem wrote: > Philosophically I don't know how to feel about this. Many apps that ship > their own d3dcompiler or d3dx will break, and I imagine Proton will end > up just reverting this. Games we've seen thus far that have broken: > - Crusader Kings II (graphical corruption; d3dcompiler) > - Final Fantasy 15 (crash; d3dcompiler) > - Star Wars Outlaws (this actually seems like a loader bug - we pick > builtin d3dcompiler now, and that tries to go looking for wined3d.dll > without changing the search path) > - Assetto Corsa (crash; missing D3DX11CreateShaderResourceViewFromFileW) > - They Are Billions (crash; needs working ID3DXEffectCompiler) Otherwise we'll never learn about those issues and it will never get fixed. It will be easy to revert for the next major release, if it comes to that. From this list only ID3DXEffectCompiler looks annoying, because it will need substantial amount of changes, to get it right. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10967#note_144460

1 0

Re: [PATCH v2 0/4] MR10967: Prefer builtin for d3d helper libraries.
by Tim Clem (＠tclem) June 29, 2026

June 29, 2026

Philosophically I don't know how to feel about this. Many apps that ship their own d3dcompiler or d3dx will break, and I imagine Proton will end up just reverting this. Games we've seen thus far that have broken: - Crusader Kings II (graphical corruption; d3dcompiler) - Final Fantasy 15 (crash; d3dcompiler) - Star Wars Outlaws (this actually seems like a loader bug - we pick builtin d3dcompiler now, and that tries to go looking for wined3d.dll without changing the search path) - Assetto Corsa (crash; missing D3DX11CreateShaderResourceViewFromFileW) - They Are Billions (crash; needs working ID3DXEffectCompiler) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10967#note_144459

1 0

[PATCH v2 0/4] MR11225: winewayland: Use update_client_surfaces to detach client surfaces.
by Rémi Bernon (＠rbernon) June 29, 2026

June 29, 2026

Misc winewayland client surface management tweaks in preparation for some DPI rounding fixes in win32u. -- v2: winewayland: Move ensure_window_surface_contents into wayland_surface.c. winewayland: Remove unnecessary client surface attach / detach. winewayland: Use update_client_surfaces to detach client surfaces. winewayland: Make window lock mutex recursive. https://gitlab.winehq.org/wine/wine/-/merge_requests/11225

3 5