December 2025 - Wine-GitLab

Re: [PATCH v2 0/1] MR9820: po: Update Japanese translation. - approved
by Alexandre Julliard (＠julliard) Dec. 23, 2025

Dec. 23, 2025

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

1 0

[PATCH 0/1] MR9825: winefile: Successfully get path for shell files.
by tbodt (＠tbodt) Dec. 23, 2025

Dec. 23, 2025

Non-folder entries in the shell namespace have no ->folder, so their this would fail to get the path. Instead always look up the attributes using the parent. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9825

2 1

Re: [PATCH v7 0/2] MR2044: ntoskrnl.exe: Implement acquiring and releasing guarded mutexes
by Colleirose (＠colleirose) Dec. 23, 2025

Dec. 23, 2025

Hi all, The lack of these functions is causing the game Duet Night Abyss to fail to open since the latest release. Looking on the Proton issue tracker, there are at least 2 other games that fail for the same reason. This issue has been open since 2023 without any further progress. Is there any update on whether the tests are failing due to this code or for unrelated issues, and what other progress needs to be made? If OP no longer has interest in fixing this issue I would be willing to look into fixing it myself to fix the broken apps. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2044#note_126086

1 0

[PATCH v2 0/1] MR9811: wined3d/gl: Split UBOs to separate chunks.
by Matteo Bruni (＠Mystral) Dec. 23, 2025

Dec. 23, 2025

It matters a lot on Nvidia proprietary drivers, where binding to GL_UNIFORM_BUFFER makes a very significant difference. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56167 -- v2: wined3d/gl: Split UBOs to separate chunks. https://gitlab.winehq.org/wine/wine/-/merge_requests/9811

3 3

[PATCH 0/1] MR9824: mscoree: Update Wine Mono to 10.4.1.
by Esme Povirk (＠madewokherd) Dec. 23, 2025

Dec. 23, 2025

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

2 1

[PATCH v3 0/1] MR9731: dlls/twaindsm: Save default data source in registry
by Bernd Herd (＠herdsoft) Dec. 23, 2025

Dec. 23, 2025

Solves bugs: #9404 and #79663 This Merge Request changes the Data Source Manager twaindsm.dll alias twain_32.dll to save the data source selected in the selection dialog into the windows registry. This enables applications that do not save the result of the DG_CONTROL/DAT_IDENTITY/MSG_USERSELECT call to be able to choose a data source the same as when using the twain.org DSM. While the twain.org DSM only expects every data source .ds to be responsible for only one data source and thus every call to DG_CONTROL/DAT_IDENTITY/MSG_GET to return the same result, the sane.ds and gphoto2.ds use an extension of the protocol by iterating through cameras/ scanners, always returning a different TW_IDENTITY on every call to DG_CONTROL/DAT_IDENTITY/MSG_GET. For that reason on DG_CONTROL/DAT_IDENTITY/MSG_OPENDS we cannot ask the just opened DS for it's identity as the twain.org DSM does, because it might have more than one Identity. Instead we search the list of data sources retrieved when the DSM was opened for either the identity given by the app or the identity retreived from the registry and give that identity to the MSG_OPENDS call to make the sane.ds open as for the backend we want it to use. This also means that the twaindsm.dll version from twain.org will not be able to manage more than one scanner with sane.ds and one camera with gphoto2.ds as only the wine version of the DSM has the neccessary extension. The twain.org version of the DSM does only save the name of the .DS file choosen by the user to the registry. Since sane.ds and gphoto2.ds can address more than one device, this is not sufficient for us. So the registry entries are not compatible to the ones from the twain.org version. Instead of the filename, we save Manufacturer, ProductFamily and espcially ProductName to the registry under a different registry key. This MR also solves a problem introdoced with commit https://gitlab.winehq.org/wine/wine/-/commit/c7570143bf2305e2292cf5a75abd20… (by myself) that it was no longer possible to control in DG_CONTROL/DAT_IDENTITY/MSG_OPENDS which of several configured sane data sources are to be opened by sane.ds. A second problem reported in bug report #9404 that crashed the sane.ds when using the user interface with the sane test backend was recently already addressed in commit https://gitlab.winehq.org/wine/wine/-/commit/04449af761451c312f70a71cb62ae7…. -- v3: dlls/twaindsm: Save default data source in registry https://gitlab.winehq.org/wine/wine/-/merge_requests/9731

3 2

[PATCH v4 0/1] MR9768: include: Disable compiler exceptions for ARM64EC MSVC targets before Clang 21
by André Zwing Dec. 23, 2025

Dec. 23, 2025

Alternative to !9762 as suggested by Jacek -- v4: include: Disable compiler exceptions for ARM64EC MSVC targets before Clang 21 https://gitlab.winehq.org/wine/wine/-/merge_requests/9768

2 2

[PATCH 0/1] MR9819: windows.media.speech/tests: Get rid of duplicated hresult.
by Bernhard Kölbl Dec. 23, 2025

Dec. 23, 2025

Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9819

2 2

[PATCH 0/2] MR9823: server: Track foreground process id, instead of looking for active window.
by Rémi Bernon Dec. 23, 2025

Dec. 23, 2025

When foreground input is changed and given to a different process (for instance the desktop process), that process active window is not set until it handles its internal messages. This might cause a race condition between the new activated process and the original process trying to steal foreground back. We might allow it to get foreground back if we don't find any active window at the time of the set_foreground_window call. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9823

1 2

[PATCH 0/3] MR9821: Avoid crash in gnutls logging when crypt libraries got unloaded.
by Bernhard Übelacker Dec. 23, 2025

Dec. 23, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59163 When using one of the debug channels +bcrypt, +crypt or +secur32 alone, and that dll gets unloaded, and one of the other dlls gets loaded, there happens a "silent" crash at the unix-side, which makes this other dll loading fail. The crash consists of gnutls still holding the pointer to the logging function of the unloaded dll. One workaround would be to always use all three debug channels together. An improvement may be this patches, which set the logging function pointer to zero. But this may silence some expected logging from gnutls, when multiple of the crypt dlls are loaded at the same time. Best solution may be to access gnutls through a single unix library, currently there are three, one for each dll. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9821

2 5