October 2025 - Wine-GitLab - list.winehq.org

[PATCH v4 0/1] MR9038: Draft: msi: implement MsiProvideAssembly[AW]()
by Ratchanan Srirattanamet (＠ratchanan.sr) Oct. 7, 2025

Oct. 7, 2025

TODO: - make awstring version of MsiProvideComponent() and use that. - Actually implement MsiProvideAssemblyA() using the above. - Write conformance test? Dependency: - Have ACTION_PublishAssemblies() record feature (https://gitlab.winehq.org/wine/wine/-/merge_requests/9037) - Have MsiEnumFeatures() fixed. Currently it seems to just look for features at the wrong place and thus is useless for this purpose. (https://gitlab.winehq.org/wine/wine/-/merge_requests/9041) Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58578 -- v4: [WIP] msi: implement MsiProvideAssembly[AW]() https://gitlab.winehq.org/wine/wine/-/merge_requests/9038

3 5

[PATCH v2 0/6] MR9115: Draft: win32u: Implement Vulkan memory D3DKMT handle import / export.
by Rémi Bernon Oct. 7, 2025

Oct. 7, 2025

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/9108, creating D3D runtime descriptors from the Vulkan info doesn't seem possible for some cases as some information have been lost (multiple stencil formats end up with the same Vulkan format, D3D bind flags transformation is not bijective). A separate, Wine-specific, D3DKMTEscape code will be exposed instead, to let D3D runtime implementations update the resource descriptors with the data they expect to find (ideally, the same descriptors as native, so importing can be compatible), after having been created and exported. (This, currently doesn't actually implements resource sharing, it only creates the D3DKMT object and exports / imports their handles. We still lack the logic to share the underlying host object fds, which will come later) -- v2: win32u: Implement Vulkan memory D3DKMT handle import from name. win32u: Implement Vulkan memory D3DKMT global / shared handle import. win32u: Implement Vulkan memory D3DKMT NT shared handle export. win32u: Create D3DKMT global resources for exported Vulkan memory. win32u: Swap VK_KHR_external_memory_win32 with the matching host extension. win32u: Pass the name of the extension to replace to get_host_extension. https://gitlab.winehq.org/wine/wine/-/merge_requests/9115

1 7

[PATCH 0/5] MR9116: win32u: Implement WGL_WINE_query_renderer extension for EGL driver
by Vasiliy Stelmachenok (＠ventureoo) Oct. 7, 2025

Oct. 7, 2025

wined3d relies on `WGL_WINE_query_renderer` to get information about current render. The issue is that EGL driver does not implement this extension, which often leads to troubles for wined3d in trying to apply their quirks based only on a `GL_RENDERER` string. Because VRAM size becomes unknown, wined3d refuses to render due to "lack of memory". This MR solves the issue by implementing `WGL_WINE_query_renderer` for EGL driver. In EGL there's no extension like `GLX_MESA_query_renderer`, so we have to implement it ourselves. Some caveats of this implementation: - Obtaining some attributes involves context switching for direct quries to OpenGL driver. I tried to avoid risk of situation where we might lose current driver context, and from my tests it works, but maybe I’m missing something. - Getting vendor and device PCI IDs is done through DRM, which is a bit tricky at the moment as we have to go through devfs. This can be made cleaner through libdrm, but I don’t think we should introduce a new dependency just for a few attributes. - The `GL_NVX_gpu_memory_info` extension is used for VRAM size. It is quite common but not supported everywhere, unfortunately there is no simpler way to get information about VRAM. - There is no API for `WGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_WINE`. Same as for winemac.drv, but it’s not a big problem since it doesn’t seem to be used now. Some advantages: - Unlike GLX, we are not tied to Mesa specific extensions, which allows it to work for NVIDIA as well, sparing wined3d from having to guess something based only on the GPU name. - Unlike the same GLX, we can actually query multiple devices. Although `GLX_MESA_query_renderer` also proclaims this, in fact Mesa does not implement anything other than queries to the current renderer: https://gitlab.freedesktop.org/mesa/mesa/-/blob/32a10ccbdd1e6750c84aac3393d… Hope I didn’t miss anything. Signed-off-by: Vasiliy Stelmachenok <ventureo(a)cachyos.org> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9116

2 5

[PATCH v5 0/2] MR9094: rometadata: Add stub + tests for IMetaDataTables
by Vibhav Pant (＠vibhavp) Oct. 7, 2025

Oct. 7, 2025

-- v5: dlls/rometadata: Add stub for IMetaDataTables. https://gitlab.winehq.org/wine/wine/-/merge_requests/9094

3 7

[PATCH 0/6] MR9108: win32u: Create D3DKMT descriptors for exported buffers and images.
by Rémi Bernon Oct. 7, 2025

Oct. 7, 2025

First step to implement VK_KHR_external_memory_win32 and shared resources. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9108

1 7

[PATCH 0/6] MR9115: win32u: Implement Vulkan memory D3DKMT handle import / export.
by Rémi Bernon Oct. 7, 2025

Oct. 7, 2025

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/9108, creating D3D runtime descriptors from the Vulkan info doesn't seem possible for some cases as some information have been lost (multiple stencil formats end up with the same Vulkan format, D3D bind flags transformation is not bijective). A separate, Wine-specific, D3DKMTEscape code will be exposed instead, to let D3D runtime implementations update the resource descriptors with the data they expect to find (ideally, the same descriptors as native, so importing can be compatible), after having been created and exported. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9115

1 6

Re: [PATCH v6 0/1] MR9097: imm32: Do not overwrite input context window with GetFocus() in ime_ui_update_window.
by zhengyong chen (＠chenzhengyong) Oct. 7, 2025

Oct. 7, 2025

On Tue Oct 7 08:46:40 2025 +0000, Rémi Bernon wrote: > IIUC `ime_ui_update_window` is always called from the IME UI window > procedure, which is created lazily, in `get_ime_ui_window`. I think it's > meant to live in the same thread as the activated context window but I > don't remember the logic very well here. I'm thinking maybe the IME UI > window should rather be destroyed then re-created in the proper thread, > if the IME context target window thread changes? You're right — indeed, `ime_ui_update_window` is always called from the IME UI window procedure.\ My suggestion is that we should **not** modify `ctx->hWnd` directly here, as this would cause inconsistencies between the `hWnd` and the associated `IMC`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9097#note_117773

1 0

[PATCH v3 0/11] MR7869: Thread priority boosts (part 1)
by Marc-Aurel Zent (＠mzent) Oct. 7, 2025

Oct. 7, 2025

This implements setting `ThreadPriorityBoost`, `ProcessPriorityBoost`, `ProcessBasePriority` and getting `ThreadPriorityBoost`, `ProcessPriorityBoost` NT info classes and adds tests where appropriate. The actual boosting mechanism will be in part 2 to keep the size of this MR manageable. -- v3: kernel32/tests: Add tests for GetProcessPriorityBoost/SetProcessPriorityBoost. kernelbase: Implement SetProcessPriorityBoost. kernelbase: Implement GetProcessPriorityBoost. ntdll: Implement ProcessPriorityBoost class in NtSetInformationProcess. ntdll: Implement ProcessPriorityBoost class in NtQueryInformationProcess. ntdll: Implement ThreadPriorityBoost class in NtSetInformationThread. ntdll: Properly implement ThreadPriorityBoost class in NtQueryInformationThread. ntdll/tests: Add tests for setting process base priority. ntdll: Implement ProcessBasePriority class in NtSetInformationProcess. https://gitlab.winehq.org/wine/wine/-/merge_requests/7869

3 12

[PATCH v3 0/1] MR8916: ntdll: Switch to CLOCK_BOOTTIME for monotonic counters on Linux.
by Marc-Aurel Zent (＠mzent) Oct. 7, 2025

Oct. 7, 2025

This now accounts for system suspend periods on Linux, similar to how native win32 ticks work. On macOS `mach_continuous_time` already does so. ~~On BSDs (and other POSIX compliant operating systems) `CLOCK_MONOTONIC` likewise includes suspend time. However they also provide a `CLOCK_BOOTTIME`, which does *not* include suspend time, hence the added `__linux__` check there.~~ See https://lkml.org/lkml/2020/5/8/1707 -- v3: ntdll: Switch to CLOCK_BOOTTIME for monotonic counters when available. https://gitlab.winehq.org/wine/wine/-/merge_requests/8916

2 1

[PATCH v2 0/1] MR8916: ntdll: Switch to CLOCK_BOOTTIME for monotonic counters on Linux.
by Marc-Aurel Zent (＠mzent) Oct. 7, 2025

Oct. 7, 2025

This now accounts for system suspend periods on Linux, similar to how native win32 ticks work. On macOS `mach_continuous_time` already does so. ~~On BSDs (and other POSIX compliant operating systems) `CLOCK_MONOTONIC` likewise includes suspend time. However they also provide a `CLOCK_BOOTTIME`, which does *not* include suspend time, hence the added `__linux__` check there.~~ See https://lkml.org/lkml/2020/5/8/1707 -- v2: ntdll: Switch to CLOCK_BOOTTIME for monotonic counters when available. https://gitlab.winehq.org/wine/wine/-/merge_requests/8916

3 3