- wine-gitlab - winehq.org

[PATCH 0/1] MR9121: user32/tests: Inline process helpers into test_child_process().
by Elizabeth Figura (＠zfigura) 07 Oct '25

07 Oct '25

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

2 1

[PATCH v11 0/5] MR9045: windows.devices.enumeration: Add support for device properties in DeviceInformation objects.
by Vibhav Pant (＠vibhavp) 07 Oct '25

07 Oct '25

-- v11: windows.devices.enumeration: Implement IDeviceInformationStatics::{FindAllAsyncAqsFilterAndAdditionalProperties, CreateWatcherAqsFilterAndAdditionalProperties}. https://gitlab.winehq.org/wine/wine/-/merge_requests/9045

2 5

[PATCH v10 0/5] MR9045: windows.devices.enumeration: Add support for device properties in DeviceInformation objects.
by Vibhav Pant (＠vibhavp) 07 Oct '25

07 Oct '25

-- v10: windows.devices.enumeration: Implement IDeviceInformationStatics::{FindAllAsyncAqsFilterAndAdditionalProperties, CreateWatcherAqsFilterAndAdditionalProperties}. https://gitlab.winehq.org/wine/wine/-/merge_requests/9045

4 11

[PATCH v7 0/11] MR8960: mshtml: Implement XDomainRequest.
by Gabriel Ivăncescu (＠insn) 07 Oct '25

07 Oct '25

-- v7: mshtml: Implement contentType for XDomainRequest. mshtml: Implement timeout for XDomainRequest. mshtml: Implement XDomainRequest.open(). mshtml: Add XDomainRequest factory implementation. mshtml: Factor out XMLHttpRequest's send. mshtml: Factor out XMLHttpRequest's open. mshtml: Factor out XMLHttpRequest's abort. mshtml: Factor out XMLHttpRequest's get_responseText. mshtml: Separate the ifaces and the other XHR fields. mshtml: Factor out XMLHttpRequest constructor init. mshtml: Factor out XMLHttpRequest creation. https://gitlab.winehq.org/wine/wine/-/merge_requests/8960

3 13

[PATCH v6 0/11] MR8960: mshtml: Implement XDomainRequest.
by Gabriel Ivăncescu (＠insn) 07 Oct '25

07 Oct '25

-- v6: mshtml: Implement contentType for XDomainRequest. mshtml: Implement timeout for XDomainRequest. mshtml: Implement XDomainRequest.open(). mshtml: Add XDomainRequest factory implementation. mshtml: Factor out XMLHttpRequest's send. mshtml: Factor out XMLHttpRequest's open. mshtml: Factor out XMLHttpRequest's abort. mshtml: Factor out XMLHttpRequest's get_responseText. mshtml: Separate the ifaces and the other XHR fields. mshtml: Factor out XMLHttpRequest constructor init. mshtml: Factor out XMLHttpRequest creation. https://gitlab.winehq.org/wine/wine/-/merge_requests/8960

2 11

[PATCH v7 0/2] MR8073: ntdll: Unbreak new wow64 mode on FreeBSD.
by Alexander Shaikhulin (＠shkhln) 07 Oct '25

07 Oct '25

1. For %fs/fsbase the patch follows the macOS logic with LDT descriptor registration and Linux with switching. One notable difference is that on 32->64 transition we set %fs to GSEL(GUFS32_SEL, SEL_UPL) before restoring fsbase, otherwise FreeBSD will just revert it by reloading the selector [at the first opportunity](https://github.com/freebsd/freebsd-src/blob/5673462af5330df207…. GSEL(GUFS32_SEL, SEL_UPL) is the default %fs value on FreeBSD and is special-cased to save/restore actual fsbase value to/from PCB. 2. I was told we could get rid of fsbase glitches in signal handlers by blocking signals with [sigfastblock(2)](https://man.freebsd.org/cgi/man.cgi?query=sigfastblock) between %fs reset to the default value and fsbase reset to pthread_teb. This is currently a part of internal API for libthr, which could be exposed as pthread_signal_block_np for Wine. I'm on the fence whether it's worth it. 3. I fully admit I have no idea what registers are worth preserving around fallback sysarch(AMD64_SET_FSBASE) syscalls and whether it's appropriate to push those registers to stack. ("Kernel" stack should be fine, I assume?) Syscalls definitely clobber r8-r11. 4. For %ss see https://lkml.org/lkml/2015/4/24/216. FreeBSD doesn't have a similar workaround in the kernel, so it goes into Wine. -- v7: ntdll: Work around AMD SYSRET SS descriptor behavior on FreeBSD. ntdll: Unbreak new wow64 mode on FreeBSD. https://gitlab.winehq.org/wine/wine/-/merge_requests/8073

4 10

[PATCH v3 0/1] MR9111: ws2_32: Implement SIO_BSP_HANDLE_SELECT.
by Josh Steffen (＠joshsteffen) 07 Oct '25

07 Oct '25

My understanding is that, in the absence of layered service providers, `SIO_BSP_HANDLE_SELECT` should behave like `SIO_BASE_HANDLE` (this is relied upon by https://github.com/python-trio/trio). Should I add tests to verify this? If so, should they basically just be the same as the existing `SIO_BASE_HANDLE` tests? -- v3: ws2_32: Implement SIO_BSP_HANDLE_SELECT. https://gitlab.winehq.org/wine/wine/-/merge_requests/9111

2 1

[PATCH v2 0/1] MR9111: ws2_32: Implement SIO_BSP_HANDLE_SELECT.
by Josh Steffen (＠joshsteffen) 07 Oct '25

07 Oct '25

My understanding is that, in the absence of layered service providers, `SIO_BSP_HANDLE_SELECT` should behave like `SIO_BASE_HANDLE` (this is relied upon by https://github.com/python-trio/trio). Should I add tests to verify this? If so, should they basically just be the same as the existing `SIO_BASE_HANDLE` tests? -- v2: ws2_32: Implement SIO_BSP_HANDLE_SELECT. https://gitlab.winehq.org/wine/wine/-/merge_requests/9111

3 6

[PATCH v3 0/7] MR9115: win32u: Implement Vulkan memory D3DKMT handle import / export.
by Rémi Bernon (＠rbernon) 07 Oct '25

07 Oct '25

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) -- v3: 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. winevulkan: Treat LPCWSTR and HANDLE as pointer sized types. https://gitlab.winehq.org/wine/wine/-/merge_requests/9115

2 8

[PATCH v2 0/5] MR9116: win32u: Implement WGL_WINE_query_renderer extension for EGL driver
by Vasiliy Stelmachenok (＠ventureoo) 07 Oct '25

07 Oct '25

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> -- v2: win32u: Advertise WGL_WINE_query_renderer extension win32u: Add wglQueryRendererStringWINE implementation for EGL driver win32u: Add wglQueryRendererIntegerWINE implementation for EGL driver win32u: Add wglQueryCurrentRendererStringWINE implementation for EGL driver win32u: Add wglQueryCurrentRendererIntegerWINE implementation for EGL driver https://gitlab.winehq.org/wine/wine/-/merge_requests/9116

3 8

2025

2024

2023

2022

wine-gitlab