November 2025 - Wine-GitLab

[PATCH 0/1] MR9485: ole32: fix property deletion memory leak in IPropertyStorage
by Jiajin Cui (＠jin-king1) Nov. 17, 2025

Nov. 17, 2025

Fixed a memory leak in IPropertyStorage_fnDeleteMultiple when deleting properties by name. Previously, when deleting a property by its name, the code only removed the property from the propid_to_prop dictionary but failed to clean up the bidirectional mapping between property names and IDs in the propid_to_name and name_to_propid dictionaries. This resulted in orphaned dictionary entries and memory leaks. The fix ensures proper cleanup of both dictionaries when deleting properties by name by: 1. Looking up the property name in the name_to_propid dictionary 2. Removing the property from propid_to_prop dictionary 3. Also removing the bidirectional mappings from propid_to_name and name_to_propid dictionaries Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9485

3 2

[PATCH 0/1] MR9483: dlls/sane.ds: Avoid segfault with backends that have integer array options like 'test'
by Bernd Herd (＠herdsoft) Nov. 17, 2025

Nov. 17, 2025

# Segfault in ui.c for backends with array integer options Some Backends offer options that are an array of TYPE_INT values. So opt.size \> sizeof(int). The code in ui.c then calls ``` sane_option_get_value( id - ID_BASE, &i ); ``` In ui.c:181 and expects one integer value to be transfered to i, but a whole array of integers is transfered, overwriting the stack and causing a segmentation fault. # Reproducting the crash Notably the test-Backend offers "red-gamma-table". Just uncomment "test" in ``` /etc/sane.d/dll.conf ``` And try to open the TWAIN user interface and a segfault occurs. But there are also other SANE backends with such options. # Solution For integer options with a size != sizeof(int), no controls for editing are to be generated. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9483

3 2

[PATCH 0/1] MR9479: dlls/sane.ds: Load last settings from registry immediatly when opening the DS
by Bernd Herd (＠herdsoft) Nov. 17, 2025

Nov. 17, 2025

This allows combining the capability negotiation with the application program with the user interface. # Capability values ignored with User Interface The recent patch to save sanner parameters from the twain user interface to the registry restores these parameters from the registry while displaying the dialog box. Settings performed by the application program via the capabilities mechanism are thus overwritten from the registry and ignored. So negotiated parameters are only honoured if the Twain user Interface is not being displayed. In that case _all_ old settings from the previous scan with UI displayed are ignored. # Solution in this merge request The TWAIN 2.4 specification says on Page 4-2 (PDF-Page 76): ``` At the time of loading the data source, all current values for the appropriate capabilities would be set to values that have either been restored from a previous session, or those that are “preferred” by the data source. This current value will remain until it has been explicitly changed by the calling application, or that application issues a MSG_RESET. ``` This is the approach choosen for this merge request: The new function SANE_LoadOptions loads parameter values from the registry when the data source is being opened and transfers them to the sane parameter store. The code in InitializeDialog, that loaded data from the registry, is restored to an older version and does not handle the registry at all. Instead dialog controls are filled based on the information in the SANE parameter database. Saving changed parameters remains as before. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9479

3 3

[PATCH v6 0/6] MR9397: dlls/sane.ds: Support ADF-Scans and fix TWSX_MEMORY
by Bernd Herd (＠herdsoft) Nov. 17, 2025

Nov. 17, 2025

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. # -- v6: dlls/sane.ds: Read frame data until EOF in native transfer mode https://gitlab.winehq.org/wine/wine/-/merge_requests/9397

3 8

[PATCH v2 0/3] MR9446: dmsynth: Fix instrument selection
by Anton Baskanov (＠baskanov) Nov. 17, 2025

Nov. 17, 2025

-- v2: dmsynth: Don't rely on the FluidSynth bank selection logic. dmsynth: Factor out instrument fallback logic from synth_preset_noteon(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9446

4 9

[PATCH v5 0/3] MR9382: win32u: Keep internal pixel format and surfaces on the DCs.
by Rémi Bernon Nov. 17, 2025

Nov. 17, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58846 Wine D3D resets the window pixel format to its original value when an internal pixel format was requested and the context done being used, and requests the internal pixel format again before it is used again. When internal pixel format and window pixel format don't match this causes any previously created OpenGL surface with a different format to be released (and destroyed as no context is current with it), creating a new one with the new format, back and forth. What we actually need here, is to keep the wined3d OpenGL client surface, with the internal pixel format, alive as long as it is being referenced by wined3d, as well as any OpenGL client surface that may have been created, with the window pixel format, by the application itself. It's not possible to rely on DCs for application-created OpenGL surfaces, as the application is free to release its DC and retrieve another one later on for the same window while still expecting it to use the same OpenGL surface. However with wined3d, we know that the DCs are being kept referenced until the context is being destroyed so we can safely use them to store the wined3d OpenGL surface. -- v5: win32u: Get rid of window internal pixel format. win32u: Keep the D3D internal OpenGL surfaces on the DCs. win32u: Set the DC pixel format too in wglSetPixelFormatWINE. https://gitlab.winehq.org/wine/wine/-/merge_requests/9382

2 6

[PATCH 0/2] MR9500: In CreateProcess(), set std handle when passing a pseudo-console.
by eric pouech (＠epo) Nov. 17, 2025

Nov. 17, 2025

This MR tests and fix the std handles in child process when using CreateProcess with extended information and passing a pseudo-console handle. >From the added tests, and other manual testing (see linked bugzilla entry), it turns out native overrides the (bound) std handles from the parent console with handles on the passed pseudo-console for the child process. But happily inherits other kind of handles. As side notes: - resetting the std handle in RTL_USER_PROCESS_PARAMETERS being console handles could be optimized: potentially, native could just test if the passed handles are bound to the passed console and reset them if not. - hijacked an unused bit in ConsoleFlags to discriminate when to recreate the std handles in child (didn't check-out how native does it though). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9500

3 3

[PATCH 0/6] MR9488: comctl32/trackbar: Add a helper to get the pen color for drawing tics.
by Zhiyi Zhang (＠zhiyi) Nov. 17, 2025

Nov. 17, 2025

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

3 8

[PATCH v2 0/6] MR9499: msado15: Set cursor position on provider side.
by Piotr Caban (＠piotr) Nov. 17, 2025

Nov. 17, 2025

-- v2: msado15: Improve _Recordset::EOF implementatio. msado15: Improve _Recordset::BOF implementation. msado15: Set cursor position on provider side. https://gitlab.winehq.org/wine/wine/-/merge_requests/9499

2 6

[PATCH 0/6] MR9499: msado15: Set cursor position on provider side.
by Piotr Caban (＠piotr) Nov. 17, 2025

Nov. 17, 2025

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

2 6