August 2025 - Wine-gitlab - list.winehq.org

[PATCH 0/4] MR8796: win32u: Introduce a new framebuffer object GL surface.
by Rémi Bernon 21 Aug '25

21 Aug '25

Used with nulldrv only for now, laying ground for framebuffer hooking in opengl32. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8796

2 5

[PATCH 0/4] MR8784: widl: Cleanup write_type helpers (2/3)
by Rémi Bernon 21 Aug '25

21 Aug '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8784

2 5

[PATCH v2 0/1] MR8785: rsaenh: Use TomCrypt for hash implementations.
by Hans Leidekker (＠hans) 21 Aug '25

21 Aug '25

Some apps unload bcrypt which causes a crash if rsaenh is used afterwards. -- v2: rsaenh: Use TomCrypt for hash implementations. https://gitlab.winehq.org/wine/wine/-/merge_requests/8785

3 8

[PATCH 0/1] MR8804: server: Return NULL from get_first_valid_hook when no hook is found.
by Rémi Bernon 21 Aug '25

21 Aug '25

Fixes: 5b7b76432dffa453e75c6336d76fdb856ab8d0c7 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8804

1 1

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Stian Low (＠stianlow) 21 Aug '25

21 Aug '25

@rbernon Confirming wine-staging is not a dependency for yabridge new-wine10-embedding branch which works for 75b9e1722d1 Release 10.13. Varities of music apps that depend on yabridge are being tested. So far Carla has worked best for me with the least minor issues. Others reported more minor issues for other apps like Bitwig. Yabridge new-wine10-embedding branch seems to behave differently depending on which app is used like Carla vs Bitwig. I'm now mostly operating under assumptions that the changes in this merge request are valid per more review of the code and all comments including the contributions to yabridge. Because Yabridge was modded for compatibility with the latest Wine changes I lean toward the same needing to happen for these other apps. I will take a look at how Carla handles yabridge windowing wrapping to compare against apps that are not behaving as well. Maybe those other apps need to be modded for compatibility with yabridge new-wine10-embedding branch or some backwards compatible fix may be found. Changes of this merge request also broke LMMS Vestige plugin which is a VST handler independent of yabridge so that project seems to have made similar assumptions about how Wine would handle their VST windowing behaviors. I will also be comparing yabridge against LMMS Vestige for a solution compatible with this merge. I'll continue to post any relevant findings back to this issue. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113376

1 0

[PATCH 0/1] MR8803: winex11.drv: Only create dummy parent when needed in create_client_window().
by Paul Gofman (＠gofman) 21 Aug '25

21 Aug '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8803

2 2

[PATCH 0/1] MR1968: Fix a problem caused by the recent official commit "rsaenh: Factor out...
by Jackie Jiang (＠sonyps5201314) 20 Aug '25

20 Aug '25

Fix a problem caused by the recent official commit "rsaenh: Factor out block_encrypt() function." that would cause DES encryption errors -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1968

3 3

Re: [PATCH v22 0/4] MR564: cabinet: implement DllGetVersion & GetDllVersion - closed
by Alexandre Julliard (＠julliard) 20 Aug '25

20 Aug '25

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

1 0

Re: [PATCH v22 0/4] MR564: cabinet: implement DllGetVersion & GetDllVersion
by Alexandre Julliard (＠julliard) 20 Aug '25

20 Aug '25

This is now fixed in 88865957d112dd4983e0f9ddabda46c080c8e1f2, thank you for catching this! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/564#note_113357

1 0

Re: [PATCH v3 0/2] MR8786: Draft: winebuild: Add flag to disable dynamicbase/aslr
by Alexandre Julliard (＠julliard) 20 Aug '25

20 Aug '25

On Wed Aug 20 20:08:15 2025 +0000, Tres Finocchiaro wrote: > From my understanding, `winebuild` influences the PE section of this > binary, which IS meaningful. This is reinforced by the fact older > `.dll` plugins stop crashing when it's disabled, and that other PE > compilers offer similar options to control these flags. > The `HIGHENTROPYVA` should have no effect if `DYNAMICBASE` is off, so I > can see a "not meaningful" there (but only on mutual exclusion), but I > wanted to keep the PR as simple as possible. > I understand that Unix has [its own ASLR that's on by > default](https://askubuntu.com/questions/318315), but to deny the > meaningfulness of this flag for the PE section of the binary seems -- > respectively -- incorrect. This regression was introduced with > 518e394794160818ffe6826c874ff2f550c95bbb and can be reverted just the > same. I'm only asking to give `winegcc` (or more specifically > `winebuild`) 'users' the ability to control it. The only influence is when both flags are set, we stop allocating in the low 2Gb by default, which probably breaks plugins that have pointer truncation bugs. Unless both flags are set together, there shouldn't be any difference for the case of `.exe.so` binaries. There are more differences for the case of PE binaries, but that's controlled by the flags passed to `mingw`, not to `winebuild`. So there's no reason to add two separate options to `winebuild`. Clearing either flag is the same as clearing both. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113356

1 0