November 2025 - Wine-gitlab

[PATCH 0/1] MR9516: jscript: Do existing prop lookups for external props only on objects with volatile props.
by Gabriel Ivăncescu 18 Nov '25

18 Nov '25

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

1 1

[PATCH v2 0/3] MR9511: Draft: server: Forbid background process window reactivation.
by Rémi Bernon 18 Nov '25

18 Nov '25

Pegasus Mail posts a WM_USER + 8991 message to its own window when it loses focus, then calls SetFocus on its window when processing this message. Several other applications have been seen calling SetWindowPos during WM_ACTIVATE message, which might also attempt to reactivate the window. That processing happens shortly after we have changed the foreground window to the desktop window, when focus is lost, then SetFocus tries to change the foreground window again. This SetFocus behavior is tested, and should work like this, but would only activate the window if the process is allowed to do so. Windows has various rules around this, and it seems to boil down to something like: * Allow taking focus if the process never was foreground, ie: when process is starting and gets initial focus on its windows. * Allow taking focus if the process was foreground but lost it recently because of a window being destroyed. * Forbid taking focus back if the process had foreground and called SetForegroundWindow explicitly to give it to another process. This doesn't implement all this rules, but rather keep rely on the host window management with some additional heuristics to avoid activating windows which lost foreground recently. This is mostly about keeping track of user input time, updating it on user input and on focus change. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167 --- I think this should be enough to prevent spurious window reactivation, either from calls to SetWindowPos during WM_ACTIVATE messages like in https://gitlab.winehq.org/wine/wine/-/merge_requests/9398 or from calls to SetFocus from posted messages right after window deactivation as described above. Fwiw we could have tests for that, and show that this MR is fixing them but fvwm doesn't implement window minimization properly, and doesn't change focus when window is minimized, so the tests would be meaningless. -- v2: server: Forbid background process window reactivation. server: Set NULL foreground input when switching to desktop window. win32u: Introduce a NtUserSetForegroundWindowInternal call. https://gitlab.winehq.org/wine/wine/-/merge_requests/9511

1 4

[PATCH v7 0/6] MR9397: dlls/sane.ds: Support ADF-Scans and fix TWSX_MEMORY
by Bernd Herd (＠herdsoft) 18 Nov '25

18 Nov '25

This merge request adds support to scan a batch of images from a scanner with Automatic Document Feeder (ADF) to the sane.ds. It also fixes problems with the buffered memory transfer mode TWSX_MEMORY, that are caused by related reasons. Before, activating the ADF only scanned the first image in the batch and then dischared the remaining images without scanning. # Why ADF scans failed Prior to this merge request, the sane.ds was based on the principle that for every successful call to sane_start there is exactly one call to sane_cancel. This was already established on the lowest level in unixlib.c: ``` static NTSTATUS start_device( void *args ) { SANE_Status status; - if (device_started) return STATUS_SUCCESS; status = sane_start( device_handle ); [...] static NTSTATUS cancel_device( void *args ) { if (device_started) sane_cancel( device_handle ); device_started = FALSE; return STATUS_SUCCESS; ``` However the sane API is designed so that for every image in a batch, sane_start must be called without a prior call to sane_cancel, as sane_cancel ends the whole batch. So for an ADF-Scan with 5 pages, sane_start is called 5 times and sane_cancel is to be called once. https://sane-project.gitlab.io/standard/api.html#code-flow So the call to ``` SANE_CALL( cancel_device, NULL ); ``` in SANE_ImageNativeXferGet prevented the scan of the 2nd frame. But as long as the "decice_started" flag in unixlib.c was not cleared, it was not possible to scan the next frame, so just removing that call is not sufficient. # New Approach An application can scan a whole image with DG_IMAGE/DAT_IMAGEMEMXFER/MSG_GET but then the application will not know the scan resolution. So it is usual to call DG_IMAGE/DAT_IMAGEINFO/MSG_GET to retrieve the scan resolution before the DAT_IMAGEMEMXFER. However the sane specification says that the obtained scan parameters "are guaranteed to be accurate between the time a scan has been started (`sane_start()` has been called) and the completion of that request. Outside of that window, the returned values are best-effort estimates of what the parameters will be when `sane_start()` gets invoked." So it is neccessary to call sane_start to make sure that the scan parameters are valid. https://sane-project.gitlab.io/standard/api.html#sane-get-parameters The TWAIN Spec says about DG_IMAGE / DAT_IMAGEINFO / MSG_GET: "Data Source writers are strongly encouraged to report back finished image values in State 6" The values that sane reports before calling sane_start can be completely wrong. One driver gave a 0-width estimate. So this code calls sane_start when the application does call one of the functions that require addition informations and then set the currentState from 6 to 7. With a state of 7, sane_start is not called again. # Terminating the Batch Batch scans are done when either: * The application negotiated a value \>0 for CAP_XFERCOUNT or * The sane-parameter "source" is set to ADF. The applcation calls DG_CONTROL/DAT_PENDINGXFERS/MSG_ENDXFER and the field pPendingXfers-\>Count determines if the application expects more frames. Without a batch scan, SANE_Cancel is called to make sure the process ends (else some backends could restart scanning the flatbed on and on). In batch scan the application counts the number of pages and stops when it is reached. Else it calls SANE_Start() without SANE_Cancel() to initiate scanning the next page. If this fails, DAT_PENDINGXFERS/MSG_ENDXFER returns pendingcount 0 to inform the application that there are no further pages. # Why buffered memory transfers failed oftenly 1. The scan parameters from SANE retrieved by the application in DG_IMAGE / DAT_IMAGEINFO / MSG_GET were wrong. For example the image width could be 0. 2. The YOffset parameter in cally to DG_IMAGE/DAT_IMAGEMEMXFER/MSG_GET was always set to 0. It is unclear if this violates the TWAIN specification, as this value is only required in tiled transfer mode. But it more robust to fill in that value, as does the gphoto2.ds and many other TWAIN drivers. # Tests performed As this change heavily changes the way the sane API is applied, the exact consequences are not easily predictable. So I tested both with different application programs and with different sane backends. ## Testapplication There are rather few application programs out there with the capability to do an ADF batch scan and buffered memory transfers. I'm attaching a minimalistic program with 600 lines of C-Code that can do batch scans and buffered memory transfers and save the results into .bmp files. I tested the 32-Bit testprogram to work correctly in Windows 11 with the official driver for the HP Officejet Pro 8600 N911a provided by HP. ## Tested applications * IrfanView 4.72 both 32-Bit and 64-Bit. 64-Bit needs twaindsm.dll from TWAIN .org to use 64-Bit sane.ds. Irfanview is one of the few easily available applications that can do ADF batch scans. * LibreOffice_6.2.8.2 64-Bit with twaindsm.dll from TWAIN .org to use 64-Bit sane.ds. Newer versions of Libreoffice 64-Bit are using a 32-Bit EXE to address 32-Bit TWAIN. 6.2.8 is the last version with native 64-Bit TWAIN based on twaindsm.dll. * LibreOffice_25.8.2_Win_x86.msi 32-Bit. * OpenOffice.org 3.3.0 32-Bit (May 2011). * Microsoft Word 97 32-Bit (Starts Microsoft Photo Editor for scanning). ## Tested Backends * HP Officejet Pro 8600 N911a using the hpaio backend. * Brother MFC-L9570CDW using the escl backend. * Brother MFC-L9570CDW using the brscan4 backend (Prprietary driver from brother). ## State of Tests Some application tests were not repeated with the very last changes in the code. I'd like to see if more changes are neccessary before a wine release before I repeat tests. [twain_memxfer.zip](/uploads/b0ce7dd6738e0921f1714c09207e3c73/twain_memxfer.zip) ``` Length Date Time Name --------- ---------- ----- ---- 17942 2025-11-05 11:10 memxfer.c 77104 2025-10-16 14:02 twain.h 302 2025-11-05 08:00 Makefile --------- ------- 95348 3 files ``` # Note on twaindsm.dll The twain data source manager is called twain_32.dll for 32-Bit Windows. However on windows there is not such module for 64-Bit environments. Instead the twain consortium offers twaindsm.dll (Both 32-Bit and 64-Bit). https://github.com/twain/twain-dsm It contains an extension in the interface allowing a DS to work with a DSM of any name by transfering the callback entry point. Some documentation on the reasons can be found here: https://github.com/twain/twain-dsm/blob/master/TWAIN_DSM/src/readme.doc even if the filenames documented in later documentations are different. When renaming the 64-Bit twain_32.dll from wine to twaindsm.dll, a problem occurs due to sane_main.c explicitly searching for twain_32: ``` static TW_UINT16 SANE_OpenDS( pTW_IDENTITY pOrigin, pTW_IDENTITY self) { if (SANE_dsmentry == NULL) { HMODULE moddsm = GetModuleHandleW(L"twain_32"); ``` And the current code (from me) that sends the entry points is called too late (After SANE_OpenDS) so runs into an error. I've got a patch for this. But essentially for 64-Bit TWAIN, the twain_32.dll should be renamed to twaindsm.dll as expected by Windows applications for 64-Bit TWAIN to work out of the box. I have no idea how to patch wine to create twain_32.dll for 32-Bit windows and twaindsm.dll for 64-Bit Windows. # -- v7: dlls/sane.ds: Read frame data until EOF in native transfer mode Implement DG_CONTROL/DAT_PENDINGXFERS/MSG_GET based on scannedImages counter Fill TW_IMAGEMEMXFER.YOffset in SANE_ImageMemXferGet dlls/sane.ds: Apply SANE_Start() and SANE_Cancel() dlls/sane.ds: Store CAP_XFERCOUNT to activeDS.capXferCount dlls/sane.ds: Replace LocalLock/LocalUnlock with GlobalLock/GlobalUnlock https://gitlab.winehq.org/wine/wine/-/merge_requests/9397

2 6

[PATCH 0/2] MR9514: gdi32: Fix font creation with invaild bits.
by Bernhard Kölbl 18 Nov '25

18 Nov '25

Black Squad's launcher creates a font like ```c font = CreateFontW(12, 0, 0, 0, 0, 0, 0, 0, DEFAULT_CHARSET, 0, 0, 0, 0x80 /* ??? */ | FF_ROMAN, L""); ``` This confuses Wine and causes it to pick a sans serif font instead of a serif one. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9514

1 2

[PATCH 0/5] MR9505: comctl32/updown: Add a helper to get the buddy border size.
by Zhiyi Zhang (＠zhiyi) 18 Nov '25

18 Nov '25

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

5 10

[PATCH 0/1] MR9513: user32/tests: Avoid out-of-bounds access in DdeCreateDataHandle (ASan).
by Bernhard Übelacker 18 Nov '25

18 Nov '25

The literal "data" is just 5 bytes, but DdeCreateDataHandle is currently told to read a length of MAX_PATH. [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=160926) <details> <summary>ASan report details</summary> ``` ================================================================= ==1464==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000140292045 at pc 0x6ffffe8ccfac bp 0x7ffffe1feed0 sp 0x7ffffe1fef18 READ of size 258 at 0x000140292045 thread T0 #0 0x6ffffe8ccfab in memmove /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/../sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:100:3 #1 0x6ffffa6dd6e6 in DdeCreateDataHandle .../wine/dlls/user32/dde_misc.c:1328 #2 0x000140061ffe in test_DdeCreateDataHandle .../wine/dlls/user32/tests/dde.c:1943 #3 0x00014005b743 in func_dde .../wine/dlls/user32/tests/dde.c:2764 #4 0x000140268de2 in run_test .../wine/include/wine/test.h:780 #5 0x0001402687eb in main .../wine/include/wine/test.h:900 #6 0x00014026aa7a in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:62 #7 0x6ffffaf57a54 in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x178027a54) #8 0x6ffffdcb06d6 in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x1700506d6) 0x000140292045 is located 27 bytes before global variable '"Expected non-NULL ptr\n"' defined in '.../wine/dlls/user32/tests/dde.c:1915' (0x000140292060) of size 23 '"Expected non-NULL ptr\n"' is ascii string 'Expected non-NULL ptr ' 0x000140292045 is located 0 bytes after global variable '"data"' defined in '.../wine/dlls/user32/tests/dde.c:1886' (0x000140292040) of size 5 '"data"' is ascii string 'data' SUMMARY: AddressSanitizer: global-buffer-overflow .../wine/dlls/user32/dde_misc.c:1328 in DdeCreateDataHandle ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9513

1 1

[PATCH v2 0/4] MR9508: Draft: winex11: Track more window state to avoid unnecessary requests.
by Rémi Bernon 18 Nov '25

18 Nov '25

We don't track the corresponding property changes, because it seems like they sometimes are different from what was requested [^1], and that would defeat the purpose of this MR. This shouldn't matter and there's actually no reason for the properties to change as these are direct property change requests. [^1]: At least for me on XWayland, the differences seem mostly about x/y position hints, and they might come from XWayland quirks. -- v2: winex11: Track requested _NET_WM_ICON to avoid unnecessary requests. winex11: Track requested _NET_WM_WINDOW_STATE to avoid unnecessary requests. winex11: Track requested WM_HINTS to avoid unnecessary requests. winex11: Track requested WM_NORMAL_HINTS to avoid unnecessary requests. https://gitlab.winehq.org/wine/wine/-/merge_requests/9508

1 5

[PATCH v8 0/6] MR9470: rometadata/tests: Add some tests for IMetaDataImport
by Vibhav Pant (＠vibhavp) 18 Nov '25

18 Nov '25

-- v8: rometadata/tests: Add tests for IMetaDataImport::{EnumProperties, GetPropertyProps}. rometadata/tests: Add tests for IMetaDataImport::GetCustomAttributeByName. rometadata/tests: Add tests for IMetaDataImport::{EnumFields, GetFieldProps}. https://gitlab.winehq.org/wine/wine/-/merge_requests/9470

3 7

[PATCH v2 0/6] MR9468: mmdevapi: Various
by Matteo Bruni (＠Mystral) 18 Nov '25

18 Nov '25

The mmdevapi side of !9438 -- v2: mmdevapi/tests: Conditionally apply todo_wine to SetSampleRate() tests. mmdevapi/tests: Simplify handling of failure to get a capture endpoint. mmdevapi/tests: Get rid of questionable error handling. mmdevapi/tests: Test capture session state in render:test_session_creation(). mmdevapi/tests: Accept any digit before the process ID in the session instance identifier. mmdevapi: Share NULL GUID session. https://gitlab.winehq.org/wine/wine/-/merge_requests/9468

3 7

[PATCH 0/4] MR9504: Reparse points, part 5.
by Elizabeth Figura (＠zfigura) 18 Nov '25

18 Nov '25

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

4 7