- Wine-GitLab - list.winehq.org

[PATCH v2 0/1] MR9686: winhttp: Implement WINHTTP_AUTOPROXY_ALLOW_STATIC
by Tobias Gruetzmacher (＠TobiX) Dec. 9, 2025

Dec. 9, 2025

This seems to be a convenience feature to return the static/default proxy config when that is configured. This is a first stab at the "correct" implementation, passes the test and seems right to me, but might be crap. Found in [PyManager](https://github.com/python/pymanager/blob/fa2de8c8820f0b2521cc4e3…, which at least fails at a different place with this change. :D -- v2: winhttp: Implement WINHTTP_AUTOPROXY_ALLOW_STATIC https://gitlab.winehq.org/wine/wine/-/merge_requests/9686

3 3

[PATCH 0/2] MR9642: msi/tests: Add a test for MsiDecomposeDescriptor() with a product with only one feature.
by Dmitry Timoshkov (＠dmitry) Dec. 9, 2025

Dec. 9, 2025

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

3 3

[PATCH v19 0/1] MR9632: sxs: avoid uninitialised len_name length
by Hans Chen (＠hans.chen) Dec. 9, 2025

Dec. 9, 2025

The `redirect_data->clrdata_len` [is unset in /dlls/ntdll/actctx.c#L4411-4412](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/actctx.c?ref_type=heads#L4411-4412) when using registration-free COM in C# NET code. Program.cs ```C# //... Guid guid = Guid.Parse("COM clsid"); Type type = Type.GetTypeFromCLSID(guid, true); var instance = Activator.CreateInstance(type)); //... ``` App.manifest ```xml <assembly> <file name="ExampleCOM.dll"> <comClass description="ExampleCOM" progid="ExampleCOM" clsid="{COM clsid}" threadingModel="Free"/> </file> </assembly> ``` The above C# code gets this error on its second line. ```Shell System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ``` This is because `len_name` is uninitialized when calling `memcpy(ret_strings, ptr_name, len_name);` in `SxsLookupClrGuid`, which is fixed in this MR. -- v19: test_SxsLookupClrGuid https://gitlab.winehq.org/wine/wine/-/merge_requests/9632

2 1

[PATCH v18 0/1] MR9632: sxs: avoid uninitialised len_name length
by Hans Chen (＠hans.chen) Dec. 9, 2025

Dec. 9, 2025

The `redirect_data->clrdata_len` [is unset in /dlls/ntdll/actctx.c#L4411-4412](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/actctx.c?ref_type=heads#L4411-4412) when using registration-free COM in C# NET code. Program.cs ```C# //... Guid guid = Guid.Parse("COM clsid"); Type type = Type.GetTypeFromCLSID(guid, true); var instance = Activator.CreateInstance(type)); //... ``` App.manifest ```xml <assembly> <file name="ExampleCOM.dll"> <comClass description="ExampleCOM" progid="ExampleCOM" clsid="{COM clsid}" threadingModel="Free"/> </file> </assembly> ``` The above C# code gets this error on its second line. ```Shell System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ``` This is because `len_name` is uninitialized when calling `memcpy(ret_strings, ptr_name, len_name);` in `SxsLookupClrGuid`, which is fixed in this MR. -- v18: reset https://gitlab.winehq.org/wine/wine/-/merge_requests/9632

2 1

[PATCH v17 0/4] MR9632: sxs: avoid uninitialised len_name length
by Hans Chen (＠hans.chen) Dec. 9, 2025

Dec. 9, 2025

The `redirect_data->clrdata_len` [is unset in /dlls/ntdll/actctx.c#L4411-4412](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/actctx.c?ref_type=heads#L4411-4412) when using registration-free COM in C# NET code. Program.cs ```C# //... Guid guid = Guid.Parse("COM clsid"); Type type = Type.GetTypeFromCLSID(guid, true); var instance = Activator.CreateInstance(type)); //... ``` App.manifest ```xml <assembly> <file name="ExampleCOM.dll"> <comClass description="ExampleCOM" progid="ExampleCOM" clsid="{COM clsid}" threadingModel="Free"/> </file> </assembly> ``` The above C# code gets this error on its second line. ```Shell System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ``` This is because `len_name` is uninitialized when calling `memcpy(ret_strings, ptr_name, len_name);` in `SxsLookupClrGuid`, which is fixed in this MR. -- v17: remove args https://gitlab.winehq.org/wine/wine/-/merge_requests/9632

2 4

[PATCH v47 0/5] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) Dec. 9, 2025

Dec. 9, 2025

Follow-up of !2786, which appears to have been abandoned. Depends on !8182, !8575, !8578 # Execute minimal test case 1. checkout wine into \~/src/wine 2. in dlls/ws2_32/tests/sock.c wrap all calls to test functions after `Init()` until `test_afunix()` with #if 0 ... #endif 3. build into \~/src/wine-build 4. run ``` (cd ~/src/wine-build; \ WINEPREFIX=~/src/wine/.wine \ ../wine/tools/runtest -q -P wine -T . -M ws2_32.dll \ -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` or without the wrapper and some imported wine debug channels enabled ``` (cd ~/src/wine-build; WINEDEBUG=+file,+winsock \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ ./wine dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` # How to debug wineserver Since `wineserver` runs in the background, simple calls to printf() will show nothing when the test case is executed. A workaround is to open a file and call fprintf() to write debug messages to this file, which can then be inspected. The wineserver man page mentions that there is limited support to control wineserver debugging by using `WINEDEBUG=+server` ``` -d[n], --debug[=n] Set the debug level to n. 0 means no debugging information, 1 is the normal level, and 2 is for extra verbose debugging. If n is not specified, the default is 1. The debug output will be sent to stderr. wine(1) will automatically enable normal level debugging when starting wineserver if the +server option is set in the WINEDEBUG variable. ``` However, higher levels probably cannot be set in this way. # Problems with synchronized log output - The Windows test binary prints test failures to stdout (line-buffered or fully buffered). - Wine/Wineserver debug prints to stderr (unbuffered). When merged into a single stream (stderr+stdout), stdout lines get fragmented and interleaved between Wine/Wineserver trace messages., which looks like this: ``` 012c:trace:file:NtWriteFile (0xd,(nil),(nil),(nil),0x6afd40,0x4190bc,0x00000012,(nil),(nil)) [?25lsock.c[?25h012c:trace:file:NtWriteFile = SUCCESS (18) 0124:trace:file:NtDeviceIoControlFile (0x10,(nil),(nil),(nil),0x74ddd0,0x00504000,(nil),0x00000000,0x74ddcc,0x00000004)xts={} ) ``` Unfortunately, synchronized logs are important for analyzing processes. # How to debug a wine test case At https://gitlab.winehq.org/wine/wine/-/blob/master/tools/runtest#L151 there is mentioned a environment variable name `WINETEST_WRAPPER`, with which it may be possible to run gdb to debug test cases ``` (cd ~/src/wine-build; make -j10 ;\ WINETEST_WRAPPER="gdb --args" \ WINEPREFIX=~/src/wine/.wine \ ../wine/tools/runtest -P wine -T . -M ws2_32.dll \ -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) Reading symbols from ./wine... (gdb) set follow-fork-mode child (gdb) r current directory: 'Z:\home\ralf.habacker\src\wine-build' sock.c:14624: Test failed: test_afunix.sock: wrong attr ffffffff sock.c:14658: Test failed: test_afunix.sock: wrong family 0 sock.c:14693: Test failed: test_afunix.sock: wrong family 0 ... ``` or without the wrapper and some important debug channels enabled ``` (cd ~/src/wine-build; \ make -j10; \ WINEDEBUG=+file,+winsock \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ gdb --args ./wine dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` With this you can debug the wine application, but unfortunally not the windows api. # How to debug a wine test case (windows api) 1. After building wine install the binaries into a temporary location ``` make -C ~/src/wine-build install DESTDIR=~/src/wine-install ``` 2. run ``` (cd ../wine-build; \ WINEPREFIX=~/src/wine/.wine \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ ./wine programs/winedbg/i386-windows/winedbg.exe --gdb dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` Now let's look at the loaded shared libraries ``` Wine-gdb> info sharedlibrary >From To Syms Read Shared Object Library 0xf7b39000 0xf7bff6e0 Yes /home/user/src/wine-build/dlls/ntdll/ntdll.so 0x00401000 0x00478e2c Yes /home/user/src/wine-build/dlls/ws2_32/tests/i386-windows/ws2_32_test.exe 0x7bcc1000 0x7bd69280 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ntdll.dll 0x7bb31000 0x7bb91594 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernel32.dll 0x7b5b1000 0x7b841f38 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernelbase.dll 0x77fd1000 0x77ff89d8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/iphlpapi.dll 0x7b4b1000 0x7b4ebcb8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/advapi32.dll 0x7b1e1000 0x7b280014 Yes /home/user/src/wine/.wine/drive_c/windows/system32/msvcrt.dll 0x7b151000 0x7b16de40 Yes /home/user/src/wine/.wine/drive_c/windows/system32/sechost.dll 0x7adf1000 0x7aec2690 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ucrtbase.dll 0x77f71000 0x77f85a80 Yes /home/user/src/wine/.wine/drive_c/windows/system32/dnsapi.dll 0x77f31000 0x77f3b240 Yes /home/user/src/wine/.wine/drive_c/windows/system32/nsi.dll 0x7ad41000 0x7ad6653c Yes /home/user/src/wine/.wine/drive_c/windows/system32/ws2_32.dll 0x7a111000 0x7a2cc55c Yes /home/user/src/wine/.wine/drive_c/windows/system32/user32.dll 0x7a631000 0x7a6ae67c Yes /home/user/src/wine/.wine/drive_c/windows/system32/gdi32.dll 0x7a0b1000 0x7a0e48e8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/win32u.dll 0x78121000 0x7813de90 Yes /home/user/src/wine/.wine/drive_c/windows/system32/imm32.dll ``` It is visible, that the unix variant of the shared libraries (ntdll.so) are read from the build dir and also the test case. The Windows part (\*.dll) is loaded from the wine prefix, so that these must be copied from the build directory initially and whenever changes are made. With this is possible to set breakpoints ``` Wine-gdb> b GetFileAttributesW@4 Breakpoint 1 at 0x7b5d3725: file ../wine/dlls/kernelbase/file.c, line 1665. Wine-gdb> c Continuing. Breakpoint 1, GetFileAttributesW@4 ( name=0x40fcfa <test_afunix+1434> L"\xec83\x8304\xfff8\x940f\x89c0\x247c\xf08\xc0b6\x44c7\x424\x1bbf\103\x489\xe824\x52e6\001\x44c7", <incomplete sequence \x824>) at ../wine/dlls/kernelbase/file.c:1665 1665 TRACE( "%s\n", debugstr_w(name) ); ``` # Followup By adding `WINESYSTEMDLLPATH=/home/user/src/wine-install/usr/local/lib/wine/i386-windows/` to the command line, some shared libraries are loaded directly from the build directory, so they do not need to be copied. ``` >From To Syms Read Shared Object Library 0xf7eb2000 0xf7f786e0 Yes /home/user/src/wine-build/dlls/ntdll/ntdll.so 0x00401000 0x00478e2c Yes /home/user/src/wine-build/dlls/ws2_32/tests/i386-windows/ws2_32_test.exe 0x7bcc1000 0x7bd69280 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ntdll.dll 0x7bb31000 0x7bb91594 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernel32.dll 0x7b5b1000 0x7b841f38 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernelbase.dll 0x77fd1000 0x77ff89d8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/iphlpapi.dll 0x7b4b1000 0x7b4ebcb8 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/advapi32.dll 0x7b1e1000 0x7b280014 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/msvcrt.dll 0x7b151000 0x7b16de40 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/sechost.dll 0x7adf1000 0x7aec2690 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/ucrtbase.dll 0x77f71000 0x77f85a80 Yes /home/user/src/wine/.wine/drive_c/windows/system32/dnsapi.dll 0x77f31000 0x77f3b240 Yes /home/user/src/wine/.wine/drive_c/windows/system32/nsi.dll 0x7ad41000 0x7ad6653c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/ws2_32.dll 0x7a111000 0x7a2cc55c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/user32.dll 0x7a631000 0x7a6ae67c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/gdi32.dll 0x79e31000 0x79e648e8 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/win32u.dll 0x78121000 0x7813de90 Yes /home/user/src/wine/.wine/drive_c/windows/system32/imm32.dll ``` Why this does not apply to all system libraries is currently unclear. -- v47: ws2_32: Add note in bind() for AF_UNIX sockets server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. ws2_32: Add support for AF_UNIX sockets. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

3 5

[PATCH v16 0/3] MR9632: sxs: avoid uninitialised len_name length
by Hans Chen (＠hans.chen) Dec. 9, 2025

Dec. 9, 2025

The `redirect_data->clrdata_len` [is unset in /dlls/ntdll/actctx.c#L4411-4412](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/actctx.c?ref_type=heads#L4411-4412) when using registration-free COM in C# NET code. Program.cs ```C# //... Guid guid = Guid.Parse("COM clsid"); Type type = Type.GetTypeFromCLSID(guid, true); var instance = Activator.CreateInstance(type)); //... ``` App.manifest ```xml <assembly> <file name="ExampleCOM.dll"> <comClass description="ExampleCOM" progid="ExampleCOM" clsid="{COM clsid}" threadingModel="Free"/> </file> </assembly> ``` The above C# code gets this error on its second line. ```Shell System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ``` This is because `len_name` is uninitialized when calling `memcpy(ret_strings, ptr_name, len_name);` in `SxsLookupClrGuid`, which is fixed in this MR. -- v16: force to call prepare_and_run_test https://gitlab.winehq.org/wine/wine/-/merge_requests/9632

2 3

[PATCH 0/1] MR9735: win32u: Iterate the client surfaces rather than the toplevel window tree.
by Rémi Bernon Dec. 9, 2025

Dec. 9, 2025

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

1 1

[PATCH 0/1] MR9734: ntdll: Fix memory leak in reparse code path.
by Daniel Lehman (＠dlehman25) Dec. 9, 2025

Dec. 9, 2025

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

2 1

[PATCH 0/1] MR9733: sapi: Implement SpDataKey::EnumValues()
by Jade Pfeiffer (＠Cthuflu) Dec. 9, 2025

Dec. 9, 2025

Fixes an issue with programs that infinitely read for `SPERR_NO_MORE_ITEMS`, such as Scrivener. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9733

2 1

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

Dec. 9, 2025

-- v2: mfreadwrite: Create converter if failed to use a single encoder. mfreadwrite: Implement transforms creation for writer. mfreadwrite: Rename update_media_type_from_upstream and make it non-static. mfreadwrite: Implement stream_create_transforms helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/9633

2 5

[PATCH v15 0/2] MR9632: sxs: avoid uninitialised len_name length
by Hans Chen (＠hans.chen) Dec. 9, 2025

Dec. 9, 2025

The `redirect_data->clrdata_len` [is unset in /dlls/ntdll/actctx.c#L4411-4412](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/actctx.c?ref_type=heads#L4411-4412) when using registration-free COM in C# NET code. Program.cs ```C# //... Guid guid = Guid.Parse("COM clsid"); Type type = Type.GetTypeFromCLSID(guid, true); var instance = Activator.CreateInstance(type)); //... ``` App.manifest ```xml <assembly> <file name="ExampleCOM.dll"> <comClass description="ExampleCOM" progid="ExampleCOM" clsid="{COM clsid}" threadingModel="Free"/> </file> </assembly> ``` The above C# code gets this error on its second line. ```Shell System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ``` This is because `len_name` is uninitialized when calling `memcpy(ret_strings, ptr_name, len_name);` in `SxsLookupClrGuid`, which is fixed in this MR. -- v15: add a blank line to trigger tests running https://gitlab.winehq.org/wine/wine/-/merge_requests/9632

2 2

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

Dec. 9, 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

[PATCH v2 0/1] MR9725: Revert "dwrite: Use uppercase paths for local file loader keys."
by Nikolay Sivov (＠nsivov) Dec. 8, 2025

Dec. 8, 2025

It's possible to get system font files paths in unix-path format, if there is no drive configured that allows access to corresponding trees. When this happens registry font list starts using unix paths, and those can't be modified the same way regular win32 paths could be. This fixes a regression caused by 2a2cc34db71. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58811 Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: Revert "dwrite: Use uppercase paths for local file loader keys." https://gitlab.winehq.org/wine/wine/-/merge_requests/9725

2 2

[PATCH 0/1] MR9728: wined3d: Properly compare reduction modes in wined3d_texture_gl_apply_sampler_desc().
by Henri Verbeet (＠hverbeet) Dec. 8, 2025

Dec. 8, 2025

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

2 1

[PATCH 0/1] MR9727: wined3d: Expect WINED3D_VIEW_TEXTURE_CUBE for cube textures in get_texture_view_target().
by Henri Verbeet (＠hverbeet) Dec. 8, 2025

Dec. 8, 2025

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

2 1