Forum Discussion
Trying to MSIX package LOB application that needs TWAIN access
So I think this isn't possible but I just wanted to ask.
I've a LOB application that needs to access TWAIN scanning devices.
How this works in a normal environment is that the TWAINDSM.dll (TWAIN Data source manager) is loaded from c:\windows\system32
This then scans the C:\Windows\twain_32 or C:\Windows\twain_64 depending on if the app is x86 or x64
The scanning manufacturers will have their TWAIN drivers installed to c:\windows\twain_32 (or 64) as subfolders and the TWAIN Data source manager scans these subfolders for available TWAIN devices that can be connected to.
All this breaks down in an MSIX environment because the container doesn't have access to C:\windows\twain_32\ManfactureDriverN folder
It can see the folders and when the TWAINDSM tries to initialize the driver it fails, most likely due to sandbox limitations.
Does anyone know of a solution to this, or apps like this will always need to stick to MSI packaging because of this limiation.
Thanks.
3 Replies
Hi Timothy,
Thanks for responding. Yes I believe you are right, the container does have access to the folder. I probably phrased it wrong or I misunderstand some of the limitations when running in an MSIX container.
I'm not installing any TWAIN drivers here as part of the package. They are already installed on the machine outside of the package by the driver install tools provided by the associated manufacturer for a scanner device, Fujitsu, Canon, Brother, etc.
It is the TWAINDSM.dll loaded from C:\windows\system32 that accesses this system folder in C:\windows\twain_64\ but it attempts to perform LoadLibrary calls for the installed TWAIN drivers. Does an MSIX container allow LoadLibrary calls from this folder and its subfolders or are they restricted to C:\windows\system32\ only and some other limited paths?
There can be any number of sub folders in this c:\windows\twain_64\ location, each one provided by a different scanning device.
The TWAINDSM.dll allows for debug logging to be enabled.
When I run the application outside of an MSIX container it is able to scan the folder fine and load the drivers
[091023184 dsm.cpp 410 0 0000000000000A04] TWAIN Working Group [091023184 dsm.cpp 411 0 0000000000000A04] TWAIN 64 Source Manager (Image Acquisition Interface) [091023184 dsm.cpp 412 0 0000000000000A04] version: 2, 5, 0, 0 [091023185 dsm.cpp 2382 0 0000000000000A04] Acme Twain -> DSM [091023185 dsm.cpp 2391 0 0000000000000A04] DG_CONTROL/DAT_PARENT/MSG_OPENDSM [091023185 apps.cpp 383 0 0000000000000A04] Application: "Acme Ltd." [091023185 apps.cpp 384 0 0000000000000A04] "Acme Twain" [091023185 apps.cpp 385 0 0000000000000A04] "Acme Twain" version: 1.0 [091023185 apps.cpp 386 0 0000000000000A04] TWAIN 2.3 [091023240 apps.cpp 1648 203 0000000000000A04] Loaded library: C:\WINDOWS\twain_64\sample2\TWAINDS_Sample64.ds (TWAINDSM_USEAPPID:1) [091023244 dsm.cpp 2446 123 0000000000000A04] TWRC_SUCCESSWhen running the application inside an MSIX container, it will fail to load the driver for the scanner
[171018814 dsm.cpp 410 0 000000000000969C] TWAIN Working Group [171018814 dsm.cpp 411 0 000000000000969C] TWAIN 64 Source Manager (Image Acquisition Interface) [171018814 dsm.cpp 412 0 000000000000969C] version: 2, 5, 0, 0 [171018814 dsm.cpp 2382 0 000000000000969C] Acme Twain -> DSM [171018814 dsm.cpp 2391 0 000000000000969C] DG_CONTROL/DAT_PARENT/MSG_OPENDSM [171018814 apps.cpp 383 0 000000000000969C] Application: "Acme Ltd." [171018814 apps.cpp 384 0 000000000000969C] "Acme Twain" [171018814 apps.cpp 385 0 000000000000969C] "Acme Twain" version: 1.0 [171018814 apps.cpp 386 0 000000000000969C] TWAIN 2.3 [171018818 apps.cpp 1557 126 000000000000969C] Could not load library: C:\WINDOWS\twain_64\sample2\TWAINDS_Sample64.ds [171018818 apps.cpp 680 126 000000000000969C] Condition Code: DS or DSM reported error, application shouldn't display an error [171018819 dsm.cpp 2446 123 000000000000969C] TWRC_SUCCESSYes, LoadLibrary works just fine in the package, and usually as expected.
Starting with the simple case of dlls directly in the native System32 folder, and/or the virtual VFS\SystemX64 folder. The LoadLibrary call will check the folders using the standard search sequence you normally would get, except that the package VFS will be a layer over the native. This means that it sees both sets of files that have different names, but if the same filename is in both, then it sees the package one.
There are situations where the list of where to look might be different in an MSIX package. And that occurs if the installer either alters the PATH variable or adds an "App Paths" registration into the registry. In either case, we can modify the AppXManifest file to add an extension called "LoaderSearchOrder" to add additional folders. A maximum of 5 can be added.
So if your installer created a "C:\Windows\System32\foobar" folder and dropped dlls into it, and then either changed the PATH variable or added an App Paths registration, you would add a LoaderSearchOrder for "VFS\SystemX64\foobar". (Assuming an x64 OS in all of this).
All this breaks down in an MSIX environment because the container doesn't have access to C:\windows\twain_32\ManfactureDriverN folder
Well, as written that isn't true. The app running in the MSIX container would have access to that folder, whether or not it is inside the package or on the native system.
More likely, you are attempting to install the twain driver as part of the package. The kernel cannot see your driver as MSIX does not support drivers of any kind being inside the package. If you treat the driver as an independent dependency, the driver may be installed natively and the application inside the MSIX container may then use it.
Make sense?
