October 14, 2014 at 9:34 am #22981
There should be guidelines concerning use of 1.x/2.x.
Should an application (not driver) install TWAINDSM.DLL if not installed ? What if TWAIN_32.DLL is present and driver(s) present already ? What if not ?
If installprogram of application is shipped with newer version of TWAINDSM.DLL should it update it ?
If application is 64 bit should it install and/or update both 32 bit and 64 bit TWAINDSM.DLL ?
What will happen if both TWAIN_32.DLL AND TWAINDSM.DLL is present and 2 applications loads one each and both tries to access the scanner at the same time. (Assuming scannerdriver recognize 2 applications attempting to use it at the same time)November 20, 2014 at 8:53 pm #26211
Applications and drivers should both install TWAINDSM. The supplied MSI wrapper checks the version number, so that the latest version is always installed.
An application should install the machine word size appropriate for it (32 or 64 bit). The same applies to drivers. If an application or driver can support both 32 and 64 bit, then it should install both versions of TWAINDSM.
The TWAIN DSM is not involved in device locks, this is the responsibility of each TWAIN driver, so it doesn’t matter which TWAIN DSM is used (TWAINDSM or TWAIN_32), it should work just fine. Put another way, whatever happens when two applications use different DSMs will be identical to what happens if they both use the same DSM.November 21, 2014 at 8:17 am #26212
Thanks for reply. One more question. Seems like TWAIN_32.DLL presents WIA drivers while TWAINDSM.DLL does not (at least 32 bit version). Is this correct ? If so why ? Any configuration ?
(WIA drivers is usually very limited in functionallity so personally I think it is good, “novice” user might be using WIA driver by mistake)
For the future it might be wise to have some kind og possiblity for an app to check if a driver is a WIA driver or a “pure” Twain driver.November 21, 2014 at 11:58 am #26213
Microsoft created a compatibility layer so that scanner vendors could supply just a WIA driver and yet TWAIN applications would still be able to access the device.
It wasn’t necessarily bad idea, but it was implemented so poorly (Microsoft underestimated the complexity of the problem) that the TWAIN Working Group decided to exclude it from driver searches in the open source TWAINDSM for the very reason you mention: confusion among end users.
As stated previously, the stance of the TWAIN Working Group is that there is no reason for an application to use TWAIN_32.DLL. If they switch to TWAINDSM.DLL, they’ll get the same quality experience, with some extra benefits, such as full support for TWAIN 2.0 DSM features, debugging access to the source code, and built in logging.