February 2026 - Wine-gitlab

[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

[PATCH v3 0/7] MR9579: ntdll: On macOS, transform the main thread into a Wine thread (running a CFRunLoop) on launch.
by Brendan Shanks (＠bshanks) 10 Feb '26

10 Feb '26

Currently, the process's main thread runs `main()` -> `__wine_main()` -> `apple_main_thread()` -> `CFRunLoopRun()`. A run loop source is added that creates the Wine main thread and runs `start_main_thread()`. With this MR, the Wine main thread calls `transform_mac_main_thread()` in `server_init_process()`. That essentially calls `NtCreateThreadEx()`, but instead of creating a new pthread it adds a source to the main thread run loop to run `start_thread()`. This transforms the process main thread into a Wine thread, after that it calls the PE `__wine_mac_run_cfrunloop()` in ntdll. That does a run_mac_cfrunloop Unix call, which just runs `CFRunLoopRun()`. The process main thread is now a Wine thread, but is otherwise still a normal Mac application main thread (including the ability for winemac to transform into a Cocoa application). In theory it might be possible to avoid the initial `CFRunLoopRun()` and have `apple_main_thread()` just spawn the Wine main thread and wait to run `start_thread()`, but the extra `CFRunLoopRun()` on the stack doesn't hurt anything. An exception/crash on the process main thread will be caught like a normal syscall fault, but `__wine_mac_run_cfrunloop()` prints an error and terminates the process. I think this is an improvement over the current behavior, which is a segfault in the signal handler when it tries to access the non-existent TEB that results in the thread hanging and eating 100% CPU. (Arguably it would be even better to unregister the signal handler and re-throw the signal so the user gets a normal macOS crash report with a helpful backtrace, maybe this could be done later.) Besides exception handling, having the main thread be a Wine thread will also allow the full use of Wine logging functions (!9503), and should allow winemac to be simplified (where many AppKit functions must be called from the main thread, and events are delivered to the main thread). -- v3: ntdll: On macOS, transform the main thread into a Wine thread (running a CFRunLoop) on launch. ntdll: Get a pointer to the PE __wine_mac_run_cfrunloop on the Unix side. ntdll: Add __wine_mac_run_cfrunloop to the PE side and export it. ntdll: Add Unix call to run a CFRunLoop. ntdll: Make thread creation helper an argument to create_thread. ntdll: Move all of NtCreateThreadEx into a helper. ntdll: Factor pthread creation out of NtCreateThreadEx. https://gitlab.winehq.org/wine/wine/-/merge_requests/9579

5 12