- Wine-GitLab - list.winehq.org

[PATCH v6 0/41] MR6207: Draft: include: Introduce new COM implementation helper macros.
by Rémi Bernon June 2, 2026

June 2, 2026

I think it would be very nice to have something like that to reduce the burden of implementing COM interfaces. This shows for instance on the windows.gaming.input module a 30% LoC reduction (from ~6800 to ~4700), even though the module already had a boilerplate helper macros already. The MR introduces macros to automatically implement each IUnknown method, as well as all of them at once. It also includes a helper to implement IInspectable methods at once, as well as macros to forward both interface methods to a base interface or an outer object. Last, it provides higher-level macros to implement a main interface and any number of sub interfaces and generate IUnknown, forwarding and vtables for all of them at once, with IInspectable support when needed. It uses widl to generate additional per-interface macros, for things like inheritance and vtable generation. The rest of the macros are otherwise shared in a Wine-specific header. The implementation is split to show individual macro being used, although they are later replaced by higher-level macros. The individual helpers are still useful in some corner cases where specific behavior needs to be implemented, or for aggregating classes. -- v6: widl: Generate return traces for COM classes. widl: Generate method traces for COM classes. widl: Generate COM class code for IClassFactory. windows.gaming.input: Generate the provider COM class. windows.gaming.input: Generate the vector COM classes. windows.gaming.input: Generate the async COM classes. windows.gaming.input: Generate the manager COM classes. windows.gaming.input: Generate the force feedback COM classes. windows.gaming.input: Generate the ramp effect COM classes. windows.gaming.input: Generate the periodic effect COM classes. windows.gaming.input: Generate the constant effect COM classes. windows.gaming.input: Generate the condition effect COM classes. (broken) windows.gaming.input: Generate the racing wheel COM classes. windows.gaming.input: Generate the gamepad COM classes. windows.gaming.input: rename controller to raw_controller widl: Generate initializers for COM classes. widl: Generate vtables for COM classes. widl: Generate impl unwrappers for COM classes. widl: Generate QueryInterface for COM classes. widl: generate some query interface helpers widl: Generate default IUnknown / IInspectable implementation. widl: Generate IUnkonwn and IInspectable forwarding for COM classes. widl: Generate impl_from helpers for COM classes. windows.gaming.input: Use the generated COM class structs. widl: Generate some structs for COM classes. widl: Parse a widl-specific impl attribute on structs. makedep: Generate some new impl.h headers from the IDLs. widl: Generate some new impl.h headers from the IDLs. windows.gaming.input: Use a separate interface for IAgileObject. widl: Introduce a new append_declspec helper. widl: Inline write_args into write_type_right. widl: Cleanup indentation and variables in write_type_right. widl: Remove now unnecessary write_callconv argument. widl: Introduce a new append_type_left helper. widl: Split write_type_left into a write_type_definition_left helper. widl: Cleanup indentation and variables in write_type_left. widl: Introduce a new write_record_type_definition helper. widl: Move some type name construction out of write_type_left. widl: Remove unnecessary recursion for TYPE_BITFIELD. widl: Introduce a new append_basic_type helper. widl: Wrap strappend parameters in a new struct strbuf. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/6207

4 20

[PATCH v3 0/6] MR2298: winewinrt: Introduce new WinRT common module.
by Rémi Bernon June 2, 2026

June 2, 2026

The idea I have is to use this module to declare class stubs until there is a good reason to split them to dedicated modules. WinRT modules aren't usually loaded directly, and instead the registry is queried to figure which module to load for which class. This would help avoiding unnecessary proliferation of stub WinRT modules, while at the same time allowing to factor WinRT foundation code (such as vector / async, etc...) between the modules that seem to deserve to be implemented separately. The relevant classes could then be split out to dedicated modules on a as-needed basis, when they get fleshed out. -- v3: winewinrt: Factor IAsyncOperation<boolean> implementations. winewinrt: Factor IAsyncInfo implementations. winewinrt: Move Vector<HSTRING> from windows.media.speech. widl: Write C type names for function parameters. winewinrt: Factor Vector<IInspectable> implementations. winewinrt: Introduce new static library. https://gitlab.winehq.org/wine/wine/-/merge_requests/2298

5 13

[PATCH v4 0/30] MR2122: Draft: winex11: Support fixed X11 keycode to scancode conversion.
by Rémi Bernon June 2, 2026

June 2, 2026

X11 keycodes are just Linux keycodes + 8 nowadays according to evdev or libinput drivers, and we can avoid innacurate reconstruction in the most common case. Opening this as a draft for now, to show where I'd like to go with https://gitlab.winehq.org/wine/wine/-/merge_requests/2062. -- v4: winex11: Use KbdLayerDescriptor for ToUnicodeEx. win32u: Force US layout in ToUnicode when CTRL is pressed. winex11: Use KbdLayerDescriptor for VkKeyScanEx. winex11: Use KbdLayerDescriptor for MAPVK_VK_TO_CHAR. winex11: Fill the Xkb layout KBDTABLES VkToWchar tables. winex11: Use KbdLayerDescriptor for GetKeyNameText. winex11: Fill the Xkb layout KBDTABLES KeyNames tables. winex11: Use KbdLayerDescriptor for MapVirtualKeyEx. winex11: Create KBDTABLES with VSCtoVK tables for Xkb layouts. winex11: Lookup xkb layout in KbdLayerDescriptor. win32u: Introduce KbdLayerDescriptor user driver entry. winex11: Get rid of now unnecessary EVENT_event_to_vkey. server: Convert CTRL + VK_PAUSE to VK_CANCEL. winex11: Drop now unnecessray nonchar_key_vkey table. winex11: Drop now unnecessary keyboard layout detection code. winex11: Use static scan code to vkey mapping tables. winex11: Support fixed X11 keycode to scancode conversion. winex11: Use scancode high bit to set KEYEVENTF_EXTENDEDKEY flag. winex11: Don't update the keyboard layouts on MappingNotify. winex11: Stop sending WM_INPUTLANGCHANGEREQUEST on MappingNotify. winex11: Send WM_INPUTLANGCHANGEREQUEST when Xkb group changes. crypt32: Avoid using uninitialized memory. winex11: Compute Xkb keyboard layout ID and language. winex11: Keep a list of every known Xkb keyboard layout. winex11: Read the _XKB_RULES_NAMES root window property. winex11: Listen to _XKB_RULES_NAMES root window property changes. win32u: Avoid accessing NULL key name string pointer. win32u: Init vsc2char in NtUserMapVirtualKeyEx only if necessary. win32u: Init vsc2vk in NtUserMapVirtualKeyEx only if necessary. win32u: Init vsc2vk in NtUserGetKeyNameText only if necessary. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/2122

2 2

[PATCH v6 0/12] MR10058: Draft: ntdll: Spawn main thread as a separate thread.
by Rémi Bernon June 2, 2026

June 2, 2026

This makes sure macOS main thread is a Wine thread as in https://gitlab.winehq.org/wine/wine/-/merge_requests/9579, while keeping its event loop usable for GUI, and makes every other platform work the same. Their main thread is parked for now, but the idea is to use the poll loop for various unix side internal purposes, such as winewayland pipe polling, compositing, etc. On macOS the main loop would be used similarly. -- v6: ntdll: Use CFRunLoopRun to implement sched_run on macOS. ntdll: Dont allocate a user stack for the unix main thread. ntdll: Spawn the application main thread as a separate thread. server: Initialize process tracing in get_startup_info. ntdll: Send process PEB / initial TEB in get_startup_info. ntdll: Call get_startup_info request even when it is empty. ntdll: Pass the startup info size to init_startup_info. server: Create the new process first thread in new_process request. server: Return new process thread handle from get_new_process_info. ntdll: Pass thread security descriptor to new_process request. ntdll: Pass the main thread flags in the new_process request. server: Pass a thread flags parameter to create_thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/10058

2 14

[PATCH v12 0/8] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon June 2, 2026

June 2, 2026

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. -- v12: 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 16

[PATCH 0/5] MR10163: server: Create the new process first thread in new_process request.
by Rémi Bernon June 2, 2026

June 2, 2026

In preparation for doing something like https://gitlab.winehq.org/wine/wine/-/merge_requests/10058, this also saves one wineserver request on process creation by creating the first thread in new_process. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10163

4 9

[PATCH 0/1] MR11053: rsaenh: Use SymCrypt for RSA and RC4.
by Hans Leidekker (＠hans) June 2, 2026

June 2, 2026

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

2 1

[PATCH 0/1] MR11043: wscript: Support UTF-16LE scripts with BOM
by Anders Kjersem (＠anders) June 2, 2026

June 2, 2026

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

3 2

[PATCH 0/1] MR11051: krnl386: Require 256-byte buffers in get_entry_point.
by Alex Henrie (＠alexhenrie) June 2, 2026

June 2, 2026

NE function names and module names can be up to 255 bytes long, plus one byte for the null terminator. The bug was identified by Cursor, which is a mix of LLM models. I wrote the fix myself. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11051

3 3

[PATCH 0/4] MR11052: Unload delay loaded DLLs.
by eric pouech (＠epo) June 2, 2026

June 2, 2026

This MR started as I tried to implement \__HrLoadAllImportsForDll from native delayimp.lib on top of kernel32.ResolveDelayLoadsFromDll (or its ntdll counterpart). It turns out the semantics are different (esp. when some entries are missing), so I ended up implementing directly without kernelbase or ntdll pieces. So, implementation of ResolveDelayLoadsFromDll is left out of this MR (as we don't have an app using it). Anyway, this MR contains the leftover from the work: - tests for ResolveDelayLoadsFromDll (refactoring some existing code), - test & fix for unloading delay imported DLLs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11052

2 4