- Wine-GitLab - list.winehq.org

[PATCH v2 0/12] MR11679: quartz: Implement color converter.
by Brendan McGrath (＠redmcg) Aug. 25, 2026

Aug. 25, 2026

This MR implements the DirectShow Color Space Converter filter. -- v2: quartz: Implement the ReceiveCanBlock function. quartz: Handle dynamic format change. quartz: Implement the Receive function. quartz: Create and configure the DMO color converter. quartz: Make sure cbBuffer is large enough to fit image. quartz: Implement QueryAccept for source. quartz: Implement media type enum for source. quartz: Implement QueryAccept on sink. quartz: Add the IMemInputPin sink interface. quartz: Add the IMediaSeeking source interface. quartz: Add the source and sink pins. https://gitlab.winehq.org/wine/wine/-/merge_requests/11679

2 13

[PATCH v2 0/6] MR11725: win32u: Create textures for the FBO single sampled surfaces.
by Rémi Bernon (＠rbernon) Aug. 25, 2026

Aug. 25, 2026

-- v2: win32u: Create textures for the FBO single sampled surfaces. opengl32: Always isolate some object names allocated in win32u. win32u: Avoid requiring OpenGL 4.5 for the framebuffer surface. win32u: Initialize framebuffer attachment storage before binding them. opengl32: Use the drawable latched virtual size for front buffer emulation. opengl32: Use the drawable latched virtual size for multisample resolve. https://gitlab.winehq.org/wine/wine/-/merge_requests/11725

2 6

[PATCH 0/5] MR11747: secur32: Call LSA mode functions from lsass.exe service.
by Piotr Caban (＠piotr) Aug. 25, 2026

Aug. 25, 2026

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

2 5

[PATCH 0/7] MR11724: wbemdisp: Fixes and implementations part 2.
by Conor McCarthy (＠cmccarthy) Aug. 25, 2026

Aug. 25, 2026

To avoid ending up with three separate `EnumVARIANT` implementations, I made the existing one handle all three. Let me know if they should be separate, and if so I'll change it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11724

3 10

[PATCH v7 0/2] MR11701: ntdll: Detect circular export forwarders and return the appropriate error.
by Kyle Yang (＠kyle) Aug. 25, 2026

Aug. 25, 2026

When export forwarders have circular dependencies, Wine currently causes a stack overflow, which differs from Windows behavior. This patch uses a stack to detect circular dependencies and returns the same error code as Windows. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=60130 Signed-off-by: Kyle Yang kyle.chaoxin.yang(a)gmail.com -- v7: ntdll: Detect circular export forwarders and return the appropriate error. https://gitlab.winehq.org/wine/wine/-/merge_requests/11701

3 4

[PATCH v2 0/10] MR9503: Draft: winemac: Allow Wine logging functions to be used from ObjC and non-Wine threads.
by Brendan Shanks (＠bshanks) Aug. 25, 2026

Aug. 25, 2026

The goal of this MR is to allow the use of Wine’s logging functions by ObjC code (including from the main thread or other non-Wine threads). winemac’s ObjC code has almost no logging; often the first task when working on an issue is to add temporary logging traces to the ObjC code. By making the full ERR/WARN/TRACE/FIXME and debug channel functionality available, we can add TRACEs to delegate methods, etc. and put them in the right channels. Including Wine and Win32 headers in ObjC code does need a workaround for BOOL, which is both an ObjC and Win32 type. Part of the solution is to use the C99 ‘bool’ type wherever possible. Otherwise, BOOL is #defined to WINBOOL while Win32 headers are #included, and must be used in function signatures if a Win32 BOOL is needed. Creating a debug_info for non-Wine threads was straightforward, though with the limitation that timestamp/pid/tid are not supported. Note that previously macdrv_cocoa.h was included by both C and ObjC files, but macdrv.h was only included by C files. macdrv.h is now included by ObjC files as well, and merging the two header files can be done next. -- v2: winemac: Improve debugstr_cf(). winemac.drv: Remove winemac-specific logging functions. winemac.drv: Add default debug channels to ObjC files. winemac.drv: Include config.h and macdrv.h in all ObjC files. winemac.drv: Include OpenGL in macdrv.h. winemac: Avoid RIID redefinition errors with CFPlugIn.h. winemac: Replace Win32 BOOL usage in macdrv.h with WINBOOL. winemac: Move all Windows includes (by Unix files) to macdrv.h. winemac: Use C99 bool for internal functions/variables in macdrv.h. winemac: Use C string format strings in the ObjC-only ERR(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9503

2 11

[PATCH v5 0/1] MR9579: ntdll: On macOS, convert the main thread into a Wine system thread on launch.
by Brendan Shanks (＠bshanks) Aug. 25, 2026

Aug. 25, 2026

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). **Update**: I've pushed a new version of this which is based on/an alternative to Rémi's !11333, just converting the macOS main thread to a Wine system thread at launch. There are no changes needed in winemac, and the conversion is done at process launch (in `server_init_process_done()`) so that winemac and other libraries (i.e. device notifications in winecoreaudio) can depend on the main thread being usable for Wine calls. I'll rebase !9503 next week so logging can be demonstrated too. -- v5: ntdll: Spawn a Wine system thread for the macOS main thread on launch. https://gitlab.winehq.org/wine/wine/-/merge_requests/9579

2 1

[PATCH v4 0/1] MR9579: Draft: ntdll: On macOS, transform the main thread into a Wine thread (running a CFRunLoop) on launch.
by Brendan Shanks (＠bshanks) Aug. 25, 2026

Aug. 25, 2026

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). -- v4: ntdll: Convert the macOS main thread into a Wine system thread on launch. https://gitlab.winehq.org/wine/wine/-/merge_requests/9579

3 4

[PATCH v2 0/8] MR10045: jscript/mshtml: Implement mshtml cycle collection for jscript objects.
by Gabriel Ivăncescu (＠insn) Aug. 24, 2026

Aug. 24, 2026

This implements mshtml's cycle collection for JS objects so that they can be part of gecko's CC graph and have circular refs dealt with. It only does this during a Full CC, not incremental phases as we can't be part of gecko's "purple buffer" without replacing the entire refcounting logic to gecko's (which doesn't seem desirable as it will be too slow, nor possible, since we still need the current one for normal jscript without gecko). Full CC is forced when doing jscript garbage collection, and otherwise we are ignoring reporting jscript objects during incremental collection. The way it does it now is to fakingly report the current wine-specific-refcount to gecko only when traversing. This is fine when we are doing Full CC without being part of a purple buffer, to integrate existing jscript objects' refcounting into the gecko CC. -- v2: mshtml/tests: Test that the WeakMap can handle external/host objects. mshtml: Unlink the mshtml node from the gecko node during unlink. jscript/mshtml: Traverse external objects that have gecko CC participants jscript: Use get_host_disp in the vtbl when retrieving the host outer jscript: Replace the addref/release methods for host objects with jscript: Get rid of the obj parameter in gc_process_linked_val. jscript: Get rid of the obj parameter in gc_process_linked_obj. jscript: Use no_gc_traverse for host functions and constructors. https://gitlab.winehq.org/wine/wine/-/merge_requests/10045

3 17

[PATCH 0/14] MR11679: quartz: Implement color converter.
by Brendan McGrath (＠redmcg) Aug. 24, 2026

Aug. 24, 2026

This MR implements the DirectShow Color Space Converter filter. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11679

3 16