- Wine-gitlab - list.winehq.org

[PATCH 0/2] MR10027: msxml3: Skip writing xml declaration if it already exists.
by Daniel Lehman (＠dlehman25) 10 Feb '26

10 Feb '26

https://testbot.winehq.org/JobDetails.pl?Key=161651 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10027

3 7

[PATCH 0/3] MR10070: build: Propagate configured cross compiler to winegcc and winebuild.
by Jacek Caban (＠jacek) 10 Feb '26

10 Feb '26

Although we allow configuring `<target>_CC` variables to select a specific compiler for compilation, this is not currently propagated to winegcc or winebuild. As a result, linking and creation of static or import libraries uses default tools found on the PATH instead. My main use case is cross-compiling with a specific LLVM build without modifying PATH. With this change, it is enough to pass `--with-mingw=/path/to/clang`. Because we use clang to locate other tools like llvm-dlltool or llvm-ar via -print-prog-name, the rest of the LLVM toolchain from that path is picked up as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10070

2 3

[PATCH 0/2] MR9748: Draft: msi: Implement MsiProvideAssemblyW().
by Dmitry Timoshkov (＠dmitry) 10 Feb '26

10 Feb '26

While bug 58578 depends on MsiProvideAssemblyW() my testing target is SQL Server Express 2012 (bug 42792 has a download URL). I marked this MR as a draft because the implementation doesn't seem to work: MsiProvideComponent() detects feature INSTALLSTATE_ABSENT, MSDN mentions that both MsiProvideAssembly() and MsiProvideComponent() should return ERROR_FILE_NOT_FOUND in that case, however the installer generates an exception and crashes once this error is returned. The installer calls MsiProvideAssembly() with the application context, however I investigated with Orca the problematic MSI and for the assembly specified in the MsiProvideAssembly() call there's no associated application, so it's not clear how it's supposed to behave in that case. Hans, would you mind looking at this and probably suggest the ways to proceed? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9748

4 4

[PATCH v5 0/5] MR10060: Draft: comdlg32: Use XDG Desktop Portal for native file dialogs
by Alexander Wilms (＠Alexander-Wilms) 10 Feb '26

10 Feb '26

This adds XDG desktop portal integration for Wine file dialogs, with compatibility fallbacks, and solves https://bugs.winehq.org/show_bug.cgi?id=51134 I used an LLM to create the patches, the wiki does not contain an LLM policy, so I don't know if this is eligible to be merged at all. I used the following sources: - https://github.com/MicrosoftDocs/win32 which contains the markdown sources for e.g. - https://learn.microsoft.com/en-us/windows/win32/menurc/resource-compiler - https://github.com/MicrosoftDocs/sdk-api which contains the markdown sources for e.g. - https://learn.microsoft.com/en-us/windows/win32/api/commdlg/nf-commdlg-geto… - https://github.com/flatpak/xdg-desktop-portal - https://github.com/notepad-plus-plus/notepad-plus-plus to determine what calls are made when choosing Save As, since it initially didn't work - Wine logs from manual testing after adding extensive TRACE calls: - Wine `notepad.exe`: `GetOpenFileNameW` / `GetSaveFileNameW` via portal - Wine `wordpad.exe`: `GetOpenFileNameW` / `GetSaveFileNameW` via portal - [`hammerplusplus.exe`](https://ficool2.github.io/HammerPlusPlus-Website/index.html) (32-bit): `IFileDialog` (`IFileDialog2_fnShow`) Open/Save As via portal - `SumatraPDF.exe`: Open via `GetOpenFileNameW` in auto; Save As uses `GetSaveFileNameW` and falls back in case of the auto policy, but uses portal when forced (WINE_FORCE_PORTAL=1) - `notepad++.exe`: `IFileDialog` (`IFileDialog2_fnShow`) Save As via portal after result-path handling fixes Implementation: - Add a portal backend in `comdlg32` for file open/save requests - Add portal handling for `GetOpenFileNameW`, `GetOpenFileNameA`, `GetSaveFileNameW`, and `GetSaveFileNameA` when requests are compatible with portal features - Route compatible `IFileDialog`/`IFileOpenDialog`/`IFileSaveDialog` paths through the portal - Keep native Wine dialogs in case of unsupported/customized dialog options - Add a combobox to `winecfg` to select the policy for XDG Desktop Portal file dialogs: auto / always / never ![image](/uploads/2a1ded4968485e84aebfc1f0ceed0aa4/image.png){width=900 height=486} ![image](/uploads/0c70d44a21fd9334de55ce64ccb4fa9b/image.png){width=900 height=486} ![image](/uploads/5f3821abbf42809cafd5edbcb343b0f8/image.png){width=485 height=600} -- v5: shell32: route SHBrowseForFolderW through portal when compatible comdlg32/tests: add IFileOpenDialog FOS_PICKFOLDERS runtime check winecfg: add portal file dialog policy and UI comdlg32: route IFileDialog through portal when compatible comdlg32: add XDG desktop portal backend for file dialogs https://gitlab.winehq.org/wine/wine/-/merge_requests/10060

3 7

[PATCH 0/1] MR10066: mciqtz32: Hide video window before resetting parent on close.
by Rémi Bernon (＠rbernon) 10 Feb '26

10 Feb '26

Avoids unnecessarily hiding then showing the window again, which seems to often trigger race conditions especially with the Wayland backend. --- This seems to fix the winmm:mci test with winewayland, where it consistently times out. The reason for the lockup is still unclear, and does not happen with every Wayland compositor (it does with Weston, which is the one used on my testbot runs, but not on GNOME), and can be reproduced with this patch: [0001-winmm-mci-test.patch](/uploads/36728018603793b33fd4653f6255fefb/0001-winmm-mci-test.patch) The winex11 test failures are more elusive and I'm not able to reproduce them locally. They seem to happen more often at least on win32 configurations, which might indicate some memory exhaustion issue, but they also sometimes happen on wow64 so it's not clear. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10066

2 1

[PATCH v2 0/3] MR9930: cfgmgr32: Update header and specifications.
by Rémi Bernon (＠rbernon) 10 Feb '26

10 Feb '26

This is in preparation for implementing cfgmgr32 functions more properly, which are widely used by native gameinput. The module is supposed to be the lower-level API, abstracting the registry, and used by other modules like setupapi instead of the other way around. -- v2: cfgmgr32: Add missing entries to cfgmgr32.spec. include: Update cfgmgr32.h definitions. cfgmgr32/tests: Add missing newline. https://gitlab.winehq.org/wine/wine/-/merge_requests/9930

3 5

[PATCH v3 0/4] MR10006: windows.devices.bluetooth: Add initial implementation for BluetoothAdapter.
by Vibhav Pant (＠vibhavp) 10 Feb '26

10 Feb '26

-- v3: windows.devices.bluetooth: Implement BluetoothAdapter::get_BluetoothAddress. windows.devices.bluetooth: Implement BluetoothAdapter::FromIdAsync. https://gitlab.winehq.org/wine/wine/-/merge_requests/10006

3 8

[PATCH v4 0/8] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon (＠rbernon) 10 Feb '26

10 Feb '26

This better splits client / host extension lists, allowing to more easily check for available host-side extensions in win32u later on, then moves the function registry to the PE side to get rid of the remaining extension logic in opengl32 unix side. Doing that, it also drops the driver function check, and always expose extension functions to the client if their extension dependency is satisfied. I'm not completely sure this is right, but I think the unix side tends to expose functions from eglGetProcAddress more often than the opposite. We could also keep a mechanism to check the driver availability, with a bit of additional complexity. On the unix side, all OpenGL functions are queried on initialization instead of just core functions, simplifying their use later on. -- v4: opengl32: Implement the function registry on the PE side. win32u: Query every OpenGL functions on initialization. opengl32: Implement client extension enumeration on the PE side. opengl32: Move major / minor version to the PE side context wrapper. opengl32: Parse host extension list to the opengl_extensions struct. opengl32: Remove now unused wgl pixel format unix thunks. opengl32: Implement wglGetExtensionsString(ARB|EXT) on the PE side. opengl32: Initialize enabled / disabled OpenGL extensions struct. https://gitlab.winehq.org/wine/wine/-/merge_requests/10019

3 19

[PATCH 0/1] MR10065: winecfg: Use the wcsdup function instead of reimplementing it.
by Alex Henrie (＠alexhenrie) 10 Feb '26

10 Feb '26

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

2 1

Re: [PATCH v3 0/2] MR10058: Draft: ntdll: Spawn main thread as a separate thread.
by Brendan Shanks (＠bshanks) 10 Feb '26

10 Feb '26

Thanks, this looks promising, I'll give it a try tomorrow. I believe a CFRunLoop will exit immediately if there's no sources added to it, if that's the case you would need to add a dummy source first (a CFRunLoopSource that never gets signaled should work). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10058#note_129314

1 0