December 2025 - Wine-gitlab

[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) 08 Dec '25

08 Dec '25

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) 08 Dec '25

08 Dec '25

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 08 Dec '25

08 Dec '25

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 0/2] MR9710: winegstreamer: Read input in chunks of 256KiB instead of 512KiB.
by Charlotte Pabst (＠CharlottePabst) 08 Dec '25

08 Dec '25

Supersedes !8183. JR East Train Simulator's IMFByteStream implementation relies on the following two properties: - Reads are always aligned on a 256KiB boundary. - Reads are never larger than 256KiB. When chunking was initially benchmarked[1], a chunk size of 512KiB only performed marginally better than 256KiB, so this change has a negligible performance impact while being more correct. I'm testing using a WAV handler here because it's easy to create the data for it in memory (avoids including a large video file in git), but the same behavior can be observed with other handlers, such as MP4. [1] https://gitlab.winehq.org/wine/wine/-/merge_requests/2390#note_27314 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9710

3 3

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

08 Dec '25

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) 08 Dec '25

08 Dec '25

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 08 Dec '25

08 Dec '25

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 08 Dec '25

08 Dec '25

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

1 1

[PATCH 0/6] MR9569: mmdevapi/tests: Introduce helpers to test a single format.
by Giovanni Mascellani (＠giomasce) 08 Dec '25

08 Dec '25

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

2 7

[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) 08 Dec '25

08 Dec '25

-- 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