- Wine-GitLab - list.winehq.org

[PATCH v3 0/3] MR9217: dlls/twain_32: Fix segfault when application unloads and reloads twain_32.dll
by Bernd Herd (＠herdsoft) Oct. 28, 2025

Oct. 28, 2025

# Fault secnario If an application loads twain_32.dll for every scan and unloads it when done with scanning, it very likely crashes when the user chooses to scan a second time within the same process. Unloading twain_32.dll is not uncommon behaviour. # Internal error cause When sane.ds gets loaded the first time, it retrieves the address of the DSM_Entry function from twain_32.dll and stores it in a variable SANE_dsmentry in the sane.ds global data. When the DS gets closed, the sane.ds does not get unloaded due to an old workaround in dlls/twain_32/dsm_ctrl.c:275: ``` twRC = currentDS->dsEntry (pOrigin, DG_CONTROL, DAT_IDENTITY, MSG_CLOSEDS, pData); /* This causes crashes due to still open Windows, so leave out for now. * FreeLibrary (currentDS->hmod); */ ``` When the application program closes the DSM (twain_32.dll) and reloads it, there is a hight probability that it will be loaded in a different memory location. So the exported DSM_Entry function is located at a different address. But the code in dlls/sane.ds/sane_main.c:60 does not update the pointer if SANE_dsmentry is not NULL: ``` if (SANE_dsmentry == NULL) { HMODULE moddsm = GetModuleHandleW(L"twain_32"); if (moddsm) SANE_dsmentry = (void*)GetProcAddress(moddsm, "DSM_Entry"); ``` So SANE_dsmentry still points to where the twain_32.dll was loaded the first time it loaded the sane.ds. Which is now an invalid address. When later the DS wants to notify the application of an event (DS Closed, Image transfered..) it calls SANE_Notify in sane_main.c:357: ``` void SANE_Notify (TW_UINT16 message) { SANE_dsmentry (&activeDS.identity, &activeDS.appIdentity, DG_CONTROL, DAT_NULL, message, NULL); } ``` And here the crash occurs due to the invalid pointer in variable SANE_dsmentry. # Suggested Solution There are many ways how this problem could be solved. The solution suggested here is based on an extension of the TWAIN protocol in Version 2: The DSM transfers the entry points to it's callback functions in a message: DG_CONTROL / DAT_ENTRYPOINT / MSG_SET That message was already implemented in sane.ds and gphoto2.gs. And both also set the flag DF_DS2 in the identitiy information SupportedGroups, so the DSM knows it is allowed to send that message. So this approach is not a workaround, but an additional feature that solves the problem in the way intended according to the TWAIN specification. This also means that the patch should solve the problem in closed source TWAIN drivers a user might install. However [sane.d](http://sane.de)s and gphoto2.ds do not fill the TW_IDENTITY information in the response to the DAT_IDENTITIY / MSG_OPENDS message. This is different from the behaviour observed on windows. For that reason the DF_DS2 flag in SupportedGroups is also not set, and thus a change in sane.ds is neccessary to make the DAT_ENTRYPOINT solution work. This is also not just a workaround but a change of the behaviour so it becomes closer to what is observed on windows. # Test scenario software I've written a small 163 lines C application program to reproduce the erroneous behaviour. It is called unloaddsm.c and I'll attach it to this merge request. It is meant to be cross-compiled with mingw-w64. It loads the DSM, opens the DS (withour showing the UI), closes the DS, unloads DSM, re-loads DSM, re-opens the DS and then displays the UI (User Interface) when the user then clicks "cancel" or presses escape, this causes the call of SANE_Notify that leads to the crash. It also shows the TW_IDENTITY fields that sane.ds did not fill. I ran the same program with a 32-Bit windows TWAIN driver on Windows 10 and there the idendity fields were filled. With the patch applied, the error does not occur any more in sane.ds. ``` Archive: /tmp/unloaddsm.zip Length Date Time Name 5283 2025-10-18 23:31 unloaddsm.c 77104 2025-10-16 14:02 twain.h 161 2025-10-18 15:57 Makefile ``` -- v3: dlls/sane.ds: when opening a DS, return the identitity information of the opened device to the caller. Matches windows behaviour and neccessary for the change in dsm_ctrl.c to work dlls/twain_32: Avoid crash when application unloads twain32_dll and reloads it for a second scan by implementing TWAIN feature DG_CONTROL / DAT_ENTRYPOINT / MSG_SET https://gitlab.winehq.org/wine/wine/-/merge_requests/9217

3 6

[PATCH 0/3] MR9214: dlls/gphoto2.ds: Fix bug. Return the DIB as a GlobalAlloc handle according to TWAIN spec instead of a HBITMAP
by Bernd Herd (＠herdsoft) Oct. 28, 2025

Oct. 28, 2025

DG_IMAGE/DAT_IMAGEMEMXFER/MSG_GET returned the newly downloaded image as a HBITMAP handle Created by CreateDIBSection, which is in conflict with the TWIN Specification that requires a GlobalAlloc'ed handle filles with BITMAPINFO struct and bitmap data. The Handle must also be 64-Bit on 64-Bit WIN32. The code in dlls/sane.ds already did this correctly. Without this change the gphoto2.ds will likely not work with usual windows software with TWAIN support. Also contains a correction that after each image being transfered, the source needs to recuce the number of remaining images to transfer, else it will never reduce the currentState from 6 to 5 causing an error message when closing the data source. The newly created GlobalAlloc memory block contains the DIB in bottom-up order (biHeight \> 0), not top-down as before (biHeight \< 0). This meets the approach in sane.ds -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9214

3 4

Re: [PATCH v2 0/1] MR9301: winemac.drv: Explicitly track the shape layer used for letter/pillarboxes. - approved
by Alexandre Julliard (＠julliard) Oct. 28, 2025

Oct. 28, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9301

1 0

Re: [PATCH v2 0/6] MR9300: vccorlib140: Platform::Exceptions stubs and tests. - approved
by Alexandre Julliard (＠julliard) Oct. 28, 2025

Oct. 28, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9300

1 0

Re: [PATCH v2 0/4] MR9297: ntdll: Add wow64 support for IOCTL_SCSI_PASS_THROUGH_DIRECT. - approved
by Alexandre Julliard (＠julliard) Oct. 28, 2025

Oct. 28, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9297

1 0

Re: [PATCH v2 0/1] MR8558: kernelbase: Release console_section in case of an allocation failure in alloc_console. - approved
by Alexandre Julliard (＠julliard) Oct. 28, 2025

Oct. 28, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8558

1 0

Re: [PATCH v2 0/1] MR8342: user32/tests: Make sure testtext has enough null bytes at the end. - approved
by Alexandre Julliard (＠julliard) Oct. 28, 2025

Oct. 28, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8342

1 0

Re: [PATCH v4 0/1] MR9169: include: Add missing AddrBStore to STACKFRAME in imagehlp.h - approved
by Alexandre Julliard (＠julliard) Oct. 28, 2025

Oct. 28, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9169

1 0

[PATCH 0/7] MR9302: msxml3/tests: Add some SAX tests for PI nodes.
by Nikolay Sivov (＠nsivov) Oct. 28, 2025

Oct. 28, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9302

2 7

[PATCH 0/1] MR9301: winemac.drv: Explicitly track the shape layer used for letter/pillarboxes.
by Tim Clem (＠tclem) Oct. 28, 2025

Oct. 28, 2025

The content view's layer can have internal sublayers from Cocoa, so assuming anything about the hierarchy is dangerous and can result in us removing backing layers for visible content. --- Fixes solid grey fullscreen windows in some games. It's not clear to me why the content view layer only sometimes has sublayers; it may be a macOS version difference or something, but either way we should not assume anything about what's going on in there. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9301

3 2

[PATCH 0/6] MR9300: vccorlib140: Platform::Exceptions stubs and tests.
by Piotr Caban (＠piotr) Oct. 28, 2025

Oct. 28, 2025

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

2 8

[PATCH v2 0/1] MR7410: test-linux32: Disable broken tests that are already released broken
by Damien Zammit (＠zamaudio) Oct. 28, 2025

Oct. 28, 2025

This should allow the CI to fully pass on this merge request. If it does, master branch could have CI tests enabled to ensure any actual broken test caused by a merge request is visible just by the CI status, and master can also reflect the passing status. Signed-off-by: Damien Zammit <damien(a)zamaudio.com> -- v2: test-linux32: Disable broken tests that are already released broken https://gitlab.winehq.org/wine/wine/-/merge_requests/7410

4 4

[PATCH 0/2] MR9299: ole32, combase: Add tests for COM context switching and delayed marshaling.
by Vibhav Pant (＠vibhavp) Oct. 28, 2025

Oct. 28, 2025

When `RoGetAgileReference` is used with `AGILEREFERENCE_DELAYEDMARSHAL`, the returned `IAgileReference` also contains a reference to the apartment the object belongs to. Thus, when `IAgileReference::Resolve()` gets called, the object will get marshaled inside the owning apartment, not the caller's apartment. This seems to be made possible by the `IContextCallback` interface. It provides a way to (ab)use the marshaller to execute arbitrary code inside a COM context, which is an additional bit of state nested inside apartments. An apartment can contain multiple COM contexts, and the standard marshaller will keep track of which context a marshaled interface is bound to. All method calls through that marshalled pointer will be wrapped around a context-switch, even when the caller is in the same apartment. Additionally, creating an instance of the class `CLSID_IContextCallback` allows us to create new contexts inside an apartment. C++/WinRT makes use of `IContextCallback` to [implement support for C++ coroutines ](https://github.com/microsoft/cppwinrt/blob/ebace4abb8f48b6b9a612e8b84667e6044976a47/strings/base_coroutine_threadpool.h#L51)(co_await, et al) inside application STA code. Another use of COM contexts seems to be the UI code in WinRT applications, where certain objects can only be `Released`/destructed from the apartment they were created in. (I was able to find another instance of `IContextCallback` usage in the wild [here](https://github.com/Open-Shell/Open-Shell-Menu/blob/4ebeadd949d0550642…, to get an `IAccessible` implementation that has apartment-affinity). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9299

3 7

[PATCH 0/1] MR9298: ntdll: Remove unused parameter from linux_query_event_obj().
by Marc-Aurel Zent (＠mzent) Oct. 28, 2025

Oct. 28, 2025

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

2 1

[PATCH 0/1] MR3228: Update heap.c removed return NULL at line 985. Prevents Wing Commander...
by James Carthew (＠dmjc) Oct. 28, 2025

Oct. 28, 2025

Update heap.c removed return NULL at line 985. Prevents Wing Commander Prophecy and Secret Ops for loading/playing. Fixes WINE bug 55176. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3228

5 4

Re: [PATCH v8 0/5] MR9209: vccorlib140: Implement Platform::Exceptions.
by Piotr Caban (＠piotr) Oct. 28, 2025

Oct. 28, 2025

I'm going to move some patches from this MR to a new one to make future reviews easier (this comment is mainly to make sure there's no work duplication). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9209#note_119861

1 0

[PATCH 0/4] MR9297: ntdll: Add wow64 support for IOCTL_SCSI_PASS_THROUGH_DIRECT.
by Akihiro Sagawa (＠sgwaki) Oct. 28, 2025

Oct. 28, 2025

This is the second part intended to replace !8120. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58257 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9297

2 4

Re: [PATCH v8 0/5] MR9209: vccorlib140: Implement Platform::Exceptions.
by Piotr Caban (＠piotr) Oct. 28, 2025

Oct. 28, 2025

Some of the recent fixes where added to wrong patches (first patch has base set incorrectly, it's fixed in second patch). Another problem is that there's something wrong with how the WinRT exceptions are handled/implemented. With code from this MR it's not possible to mix native and builtin ucrtbase and vccorlib140 (we're getting ACCESS_VIOLATION while using exception throwing functions). While it might be not critical I would like to understand what's going on. I'm planning to look into it more. I guess it might be some kind of side-effect of trying to make these exceptions working with older exception handlers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9209#note_119856

1 0

[PATCH v3 0/6] MR9032: opengl32: Support wow64 buffer storage and persistent memory mapping using Vulkan.
by Jacek Caban (＠jacek) Oct. 28, 2025

Oct. 28, 2025

I'm opening this MR as an RFC. It's an initial attempt to support OpenGL persistent memory mapping in the new wow64. The implementation is not complete yet (details below), but it's intentionally kept as simple as possible for a proof of concept. Since we can't control where OpenGL maps memory, the idea is to use the available Vulkan extension with enough glue between them. Because of how GL–VK interop works, this requires creating a memory object on the Vulkan side and importing it into OpenGL. Once that's done, all operations on such buffers are performed through GL, except for mapping, which is handled by Vulkan. This is achieved by hooking `gl*BufferStorage` and reimplementing it on top of `glImportMemoryFdEXT` for mappable buffers. Recently introduced buffer wrappers make further tracking of these buffers straightforward. If we move forward with this, the feature will need to be enabled based on available driver capabilities (for now, it's force-enabled). Some parts might also be worth moving into win32u. This alone seems enough to claim persistent memory support and thus expose OpenGL 4.6 on the new wow64. Performance looks good in my limited testing, although that hasn't been a focus yet. Possible improvements include: - Currently only GL buffers created with `gl*BufferStorage` are affected. Other cases still fall back to the slow memcpy path. - The draft just picks the first host-visible coherent memory type exposed by Vulkan. We could try harder to pick an optimal type taking into account GL flags. - The draft allocates a new Vulkan memory and fd for each mapped buffer. This is inefficient for small buffers, for which a suballocator could help. - The draft always picks the first GPU reported by Vulkan. We may need to ensure that the selected device matches the one OpenGL actually uses. An alternative would be a new OpenGL extension. A driver-level solution could be more efficient, and it would certainly be nice to have. However, since such an extension doesn't exist yet, and even if we have it soon, I think it's still valuable to have a fallback solution that works with existing drivers. -- v3: opengl32: Support wow64 buffer storage and persistent memory mapping using Vulkan. opengl32: Wrap buffer storage functions. opengl32: Use stored extensions in filter_extensions. opengl32: Use stored extension list in is_extension_supported. opengl32: Compute supported extensions in make_context_current. opengl32: Split extensions by null bytes in the registry. https://gitlab.winehq.org/wine/wine/-/merge_requests/9032

2 7

[PATCH 0/6] MR9295: mmdevapi: Add a SW synth MIDI device.
by Anton Baskanov (＠baskanov) Oct. 28, 2025

Oct. 28, 2025

This is an alternative approach to !7233: instead of creating an actual driver, just add a SW synth device in `mmdevapi`. Other differences from !7233: - Get rid of `struct swmidi` and put everything in global variables. - Use static initialization for `cs`, remove `swmidi_init()` and `swmidi_exit()`. Whole series for reference: https://gitlab.winehq.org/baskanov/wine/-/tree/mmdevapi-swmidi?ref_type=hea… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9295

2 6

[PATCH v9 0/7] MR6783: winegstreamer: Fix memory/resource leaks in media sources.
by Conor McCarthy (＠cmccarthy) Oct. 28, 2025

Oct. 28, 2025

Streams hold a reference to the source, but this reference should not be taken until `Start()` is called because freeing the media source depends on release in `Shutdown()` of the stream's reference to the source. We could create the streams in `media_source_create()` and take source refs for them in `Start()`, but that's potentially confusing and fragile. Streams can persist after the media source is destroyed. In that case, they cannot access the source object and it should be released and set to null. Windows behaviour is to release references to the source in `Shutdown()`. If we don't do this and a buggy app were to leak a stream object, the media source object would also leak and `wg_parser_destroy()` would not be called. -- v9: mf/tests: Fix object leaks caused by the test source and stream. mf/session: Shut down both the sink activate object and the media sink if present. winegstreamer: Release stream references to the media source in Shutdown(). winegstreamer: Do not create MF stream objects until the media source is started. mf/tests: Add some checks for session object leakage. mfplat/tests: Test video stream release after media source release. mfplat/tests: Add more media source refcount checks. https://gitlab.winehq.org/wine/wine/-/merge_requests/6783

2 8

Re: [PATCH v3 0/1] MR9151: winevulkan: Update to VK spec version 1.4.329
by Oscar Barenys (＠oscarbg) Oct. 28, 2025

Oct. 28, 2025

sorry to ask here: VK 1.4.330 includes a "bunch" of extensions.. an update would be nice, if possible :-) thanks.. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9151#note_119830

1 0

[PATCH 0/1] MR9256: kernel32: Don't rename GetCurrentThreadId.
by Alex Henrie (＠alexhenrie) Oct. 27, 2025

Oct. 27, 2025

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

5 12

Re: [PATCH v11 0/6] MR9147: rometadata: Implement CIL assembly/metadata reader + some IMetaDataTables methods. - approved
by Alexandre Julliard (＠julliard) Oct. 27, 2025

Oct. 27, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147

1 0

Re: [PATCH v3 0/1] MR9187: Fix native TWAIN transfer mode for 64-Bit wine: pData points to a HGLOBAL,... - approved
by Alexandre Julliard (＠julliard) Oct. 27, 2025

Oct. 27, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9187

1 0