December 2025 - Wine-GitLab

[PATCH 0/4] MR9633: mfreadwrite: Implement transforms creation for writer.
by Ziqing Hui (＠zhui) Dec. 8, 2025

Dec. 8, 2025

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

3 9

[PATCH 0/1] MR9732: ntdll: Support FSCTL_DUPLICATE_EXTENTS_TO_FILE
by nikita pushkarev (＠strudelll) Dec. 8, 2025

Dec. 8, 2025

Implement FSCTL_DUPLICATE_EXTENTS_TO_FILE handling in ntdll on Linux by wiring the IOCTL to FICLONERANGE/FICLONE where available and returning STATUS_INVALID_DEVICE_REQUEST otherwise. Adds the necessary constants/types when missing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9732

4 3

[PATCH v4 0/10] MR9687: winebus, hidclass, dinput: Add bus_num and port_path to device_desc and use them in instance_id.
by Ivo Ivanov (＠logos128) Dec. 8, 2025

Dec. 8, 2025

Use only real serial numbers, otherwise return error on IOCTL_HID_GET_STRING, similar to Windows. Generate consistent container_id (winebus) based on either serial number, uid (macos LocationID), bus_num/port_path (Linux bus_udev) or input/index. Generate consistent guidInstance (dinput) based on device_id/instance_id extracted from the device_path. -- v4: dinput: Make guidInstance consistent through Wine launches. winebus.sys: Make container_id consistent through Wine launches. winebus.sys: When no serial number is available, use bus_num and port_path when generating instance_id. winebus.sys: Add bus_num and port_path to struct device_desc. https://gitlab.winehq.org/wine/wine/-/merge_requests/9687

2 12

[PATCH 0/7] MR9579: ntdll: On macOS, transform the main thread into a Wine thread (running a CFRunLoop) on launch.
by Brendan Shanks (＠bshanks) Dec. 8, 2025

Dec. 8, 2025

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). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9579

3 10

[PATCH 0/1] MR9707: devenum/tests: Skip test if no video capture device is present.
by Bernhard Übelacker Dec. 8, 2025

Dec. 8, 2025

This patch copies the same skip seen in [qcap/tests/videocapture.c](https://gitlab.winehq.org/wine/wine/-/blob/maste…. This is to avoid the test crashing with wine and windows. [Test pattern page](https://test.winehq.org/data/patterns.html#devenum:devenum) Followup to 9f3ca141da. <details> <summary>ASan crash report</summary> ``` ================================================================= ==devenum_test.exe==472==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000000 (pc 0x0001400098c3 bp 0x7ffffe1ffa50 sp 0x7ffffe1ffa30 T0) ==devenum_test.exe==472==The signal is caused by a READ memory access. ==devenum_test.exe==472==Hint: address points to the zero page. #0 0x0001400098c2 in IEnumMoniker_Next Z:\builds\bernhardu\wine\build64\include\objidl.h:6841 #1 0x0001400094c5 in test_video_input Z:\builds\bernhardu\wine\build64\..\dlls\devenum\tests\devenum.c:1173 #2 0x0001400010d0 in func_devenum Z:\builds\bernhardu\wine\build64\..\dlls\devenum\tests\devenum.c:1224 #3 0x00014000e4d2 in run_test+0x102 (C:\users\gitlab\AppData\Local\Temp\wct\devenum_test.exe+0x14000e4d2) #4 0x00014000df4c in main+0x4bc (C:\users\gitlab\AppData\Local\Temp\wct\devenum_test.exe+0x14000df4c) #5 0x00014001006a in mainCRTStartup Z:\builds\bernhardu\wine\build64\..\dlls\msvcrt\crt_main.c:62 #6 0x6fffffc37a64 (C:\windows\system32\kernel32.dll+0x178027a64) #7 0x6fffffdc08b6 (C:\windows\system32\ntdll.dll+0x1700508b6) ==devenum_test.exe==472==Register values: rax = 0 rbx = 7ffffe1ffb80 rcx = 0 rdx = 140100000 rdi = 7ffffe1ffaa0 rsi = 1 rbp = 7ffffe1ffa50 rsp = 7ffffe1ffa30 r8 = 7ffffe1ffae0 r9 = 0 r10 = 8 r11 = 202 r12 = 140100000 r13 = fffffc3ff90 r14 = 7ffffe1ffae0 r15 = 0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: access-violation Z:\builds\bernhardu\wine\build64\include\objidl.h:6841 in IEnumMoniker_Next ==devenum_test.exe==472==ABORTING ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9707

2 2

[PATCH v6 0/7] MR3007: Draft: ntdll: Avoid requests with null pointer but invalid size.
by Bernhard Übelacker Dec. 8, 2025

Dec. 8, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51770 - v1: - https://www.winehq.org/pipermail/wine-devel/2021-December/202913.html - https://www.winehq.org/pipermail/wine-devel/2022-April/213866.html (resend) - v2: - https://www.winehq.org/pipermail/wine-devel/2022-April/214306.html - Validate pointer before calling wine_server_add_data. - v3: (d4a7440a) - https://www.winehq.org/pipermail/wine-devel/2022-May/218285.html - Move check to DeviceIoControl. - Always use fixed values for IOCTL_STORAGE_GET_DEVICE_NUMBER. - Remove warning at expected hang. - v4: (6a69c680) - Fix typo in commit message. - Modified format strings. - v5: (47784feb) - Move test to own test function. - Move check to wine_server_add_data. - v6: (8c641d09) - Move check to NtDeviceIoControlFile - Add (at least temporary) tests to compare with NtDeviceIoControlFile and NtFsControlFile. -- v6: ntoskrnl.exe/test: Add some temporary debugging output. kernel32/tests: Add test for IOCTL_STORAGE_GET_DEVICE_NUMBER. ntdll: Add validation for input and output buffers in NtDeviceIoControlFile. ntoskrnl.exe: Allow sending a null input buffer to the driver. ntoskrnl.exe: Add todo_wine_if to test_ioctl_buffers. ntoskrnl.exe: Remove buffer assignments in test_ioctl_buffers. ntoskrnl.exe: Add test_ioctl_buffers. https://gitlab.winehq.org/wine/wine/-/merge_requests/3007

3 10

[PATCH 0/1] MR9731: dlls/twaindsm: Save default data source in registry
by Bernd Herd (＠herdsoft) Dec. 8, 2025

Dec. 8, 2025

Solves bugs: #9404 and #79663 This Merge Request changes the Data Source Manager twaindsm.dll alias twain_32.dll to save the data source selected in the selection dialog into the windows registry. This enables applications that do not save the result of the DG_CONTROL/DAT_IDENTITY/MSG_USERSELECT call to be able to choose a data source the same as when using the twain.org DSM. While the twain.org DSM only expects every data source .ds to be responsible for only one data source and thus every call to DG_CONTROL/DAT_IDENTITY/MSG_GET to return the same result, the sane.ds and gphoto2.ds use an extension of the protocol by iterating through cameras/ scanners, always returning a different TW_IDENTITY on every call to DG_CONTROL/DAT_IDENTITY/MSG_GET. For that reason on DG_CONTROL/DAT_IDENTITY/MSG_OPENDS we cannot ask the just opened DS for it's identity as the twain.org DSM does, because it might have more than one Identity. Instead we search the list of data sources retrieved when the DSM was opened for either the identity given by the app or the identity retreived from the registry and give that identity to the MSG_OPENDS call to make the sane.ds open as for the backend we want it to use. This also means that the twaindsm.dll version from twain.org will not be able to manage more than one scanner with sane.ds and one camera with gphoto2.ds as only the wine version of the DSM has the neccessary extension. The twain.org version of the DSM does only save the name of the .DS file choosen by the user to the registry. Since sane.ds and gphoto2.ds can address more than one device, this is not sufficient for us. So the registry entries are not compatible to the ones from the twain.org version. Instead of the filename, we save Manufacturer, ProductFamily and espcially ProductName to the registry under a different registry key. This MR also solves a problem introdoced with commit https://gitlab.winehq.org/wine/wine/-/commit/c7570143bf2305e2292cf5a75abd20… (by myself) that it was no longer possible to control in DG_CONTROL/DAT_IDENTITY/MSG_OPENDS which of several configured sane data sources are to be opened by sane.ds. A second problem reported in bug report #9404 that crashed the sane.ds when using the user interface with the sane test backend was recently already addressed in commit https://gitlab.winehq.org/wine/wine/-/commit/04449af761451c312f70a71cb62ae7…. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9731

2 1

[PATCH 0/1] MR9730: twain_32/tests: Test with twaindsm.dll at 64-bits.
by Bernhard Übelacker Dec. 8, 2025

Dec. 8, 2025

If I understand it right there is now no more a `twain_32.dll` at the 64-bit side. But currently the test still tries to load the function `DSM_Entry` from this dll. Therefore the 64-bit wine tests fail, as it uses a `win_skip`. Therefore this patch makes the test use `twain_32.dll` with 32-bit and `twaindsm.dll` with 64-bit. What do you think? [Test pattern page](https://test.winehq.org/data/patterns.html#twain_32:dsm) [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=161218) Followup to c7570143bf. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9730

1 1

[PATCH 0/1] MR9729: winex11: Check for events again after processing delayed events.
by Rémi Bernon Dec. 8, 2025

Dec. 8, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59102 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9729

1 1

[PATCH v3 0/1] MR9685: wineusb.sys: Use the full port path to avoid collisions with identical devices connected to other hubs on the same bus.
by Ivo Ivanov (＠logos128) Dec. 8, 2025

Dec. 8, 2025

-- v3: wineusb.sys: Use the full port path to avoid collisions with identical devices connected to other hubs on the same bus. https://gitlab.winehq.org/wine/wine/-/merge_requests/9685

2 1