On Mon Nov 24 15:43:33 2025 +0000, Bernd Herd wrote:
Am Freitag, dem 21.11.2025 um 14:12 -0600 schrieb Esme Povirk (@madewokherd):
Merge Request https://gitlab.winehq.org/wine/wine/-/merge_requests/9519%C2%A0wurde von Esme Povirk überprüft
-- Esme Povirk started a new discussion on configure.ac: https://gitlab.winehq.org/wine/wine/-/merge_requests/9519#note_123300
> + enable_twaindsm="no"; > + fi > +fi
This way of doing it won't work correctly when we're building multiple architectures in a single tree. I think this should be similar to enable_dpnsvr below.
I'll likely take a look into this over the weekend... But I'm insecure here.
I still think that twaindsm should be provided on all architectures,
That surprises me. If you have an old twain 1.x compatible data source, that does not support the TWAIN 2.x extensions with the callbacks, that old data source needs to find the DSM using the "twain_32" name. As does sane.ds if being called from an old version 1.x DSM. So such an old Data Source cannot be used with twaindsm.dll, it must be used by twain_32.dll, else it won't work. Even if you just make a copy of twain_32.dll as twaindsm.dll and use that, an old Twain 1.x data source will likely fail. It will also fail with the twaindsm.dll provided by twain.org. https://github.com/twain/twain-dsm/blob/master/TWAIN_DSM/src/readme.doc Describes that problem in chapter 3.3.3: "TWAIN Drivers that want to use twaindsm32.dll need to add the flag SF_DSM2_DS to the TW_IDENTITY SupportedGroups member. This is to trigger the application that they can use twaindsm32.dll. When a TWAIN Driver is opened it can check the TW_IDENITY SupportedGroups flag. If the DSM has set SF_DSM2_DSM the TWAIN Driver knows that it has been opened by twaindsm32.dll. The twaindsm32.dll after successfully opening a DS can immediately send a DG_CONTROL/ DAT_CALLBACK/ MSG_REGISTER_CALLBACK triplet message to the DS. This message will contain the TW_CALLBACK structure with handle to the DSM_Entry function. If the DS does not receive this message it will default to the old method of LoadLibrary() and GetProcAddress() and assume it is being called by the TWAIN_32.DLL. TWAIN Application that want to support both twaindsm32.dll and TWAIN_32.DLL should first review all the drivers by using TWAIN_32.dll using getFirst() getNext on all the drivers. By checking the TW_IDENTIY SupportedGroups flag against SF_DSM2_DS the app knows that the TWAIN Driver can use the twaindsm32.dll. The TWAIN Application can safely use the twaindsm32.dll to open this TWIAN Driver by name. The application does not set the SF_DSM2_DSM or SF_DSM2_DS flag to indicate they want to use the twaindsm32.dll the DSM will do this." That sounds lake an awfully complex process. The only good reason to add this complexity for 32-Bit is if an application profits from the TWAIN 2.x extensions and thus the twaindsm.dll. And I don't think wine's dlls/twain_32 supports all TWAIN 2.0 features yet. Compared to 64-Bit: "Since Microsoft is not installing the DSM in 64-bit versions of Windows, this is the only DSM that TWAIN Applications and TWAIN Drivers need to look for." So we can expect all 64-Bit data sources to know how to handle this. If an application really wants to use the TWAIN 2.0 extensions in twaindsm.dll for 32-Bit, it can still install the TWAIN organization Version on 32-Bit... I read that some users successfully use TCP/IP-Based TWAIN Data Sources Drivers designed for Windows unter Wine. Twain has a driver database and it seems 64-Bit TWAIN for Windows is usually only offered by higher-class devices.
though at the moment it's unclear to me where it should look for data sources on arm64.
I have no idea of the ARM64 architecture yet. The twain spec says: "The name of the TWAIN directory is "twain_32" for 32-bit Sources and "twain_64" for 64-bit Sources (on 64-bit systems only)." (PDF-Page 645). Shouldn't that be sufficient? Or do we need to distinguish betwen ARM64 and AMD64 binaries on the same machine? Does ARM64 Architecture mean that I can compile up to 30 year old WIN32 source codes with few changes and run it on a raspberry pi? Could be cool. :-)
I see. I did not know that making twaindsm work on 32-bit would be that complex. In that case, it does make sense to wait until there's a clear benefit to providing it.
ARM64: Come to think of it, in theory, we could install ARM64X binaries in twain_64. ARM64X combines ARM64EC (so it works with emulated x86_64 code, but is itself native) and native ARM64. I do not know whether any applications would take advantage of the ARM64 side in practice.