Home › Forums › TWAIN Classic › 64-bit TWAIN only sees 64-bit TWAIN drivers?
- This topic has 11 replies, 5 voices, and was last updated 5 years, 3 months ago by Mark.
- AuthorPosts
Is this still true? It would be a terrible limitation – I just got my EZTwain library to build in 64-bit, but it sees *none* of the 6 (32-bit) TWAIN sources I have installed…
Yes. 64bit TWAIN Applications only work with the 64bit DSM and the 64bit DSM only sees 64bit Data Sources.
Jim Watters
Hi Jim – I was hoping you’d see my post!
This seems like a disaster to me!
I don’t want to explain to my customers, especially the .NET folks, that I have a 64-bit EZTwain library for them to use in their applications, but it’s useless, because they can’t count on it seeing any particular scanner their end-user has installed, even though the scanner is installed and working as a TWAIN scanner!Are the scanner vendors happy with this? I’m sure I could write a bridge from 64 to 32-bit, at least for Windows. Seems to me that would be a lot less expensive than re-writing all those drivers?
I do understand what you are talking about.
There is a Thunking layer in Windows 32bit twain_32.dll that allows 32bit Apps to communicate with 16bit DS.
This was before my time and I don’t know of the consequences of having this layer. How long did it take driver developers to embrace 32bit?
I have not heard of complaints from scanner vendors. There are currently very few 64bit TWAIN Applications. We do want those drives re-written and updated to TWAIN 2.x any way. And at that point it is pretty easy to also pump out a 64bit version. Scanner vendors that want to support WIA on 64bit must provide a 64bit WIA driver. WIA driver is required to pass WinQual.
So scanner vendors should build their 32 & 64 bit TWAIN 2.x drivers then use WIA-on-TWAIN to obtain WIA drivers and the world is a better place.
Apple went though a similar problem when they went to OSX. Application and DS had to be rewritten.
It is possible to add a Thunking layer to the TWAIN2 DSM. In fact it is an open source and anyone can submit a patch. 🙂
This is from the 9.1 twain.h header file. There is a bit more info in there on thunking as well.
SDH – 03/23/95 – WATCH
The thunker requires knowledge about size of data being passed in the lpData parameter to DS_Entry (which is not readily available due to type LPVOID. Thus, we key off the DAT_ argument to determine the size. This has a couple implications:
1) Any additional DAT_ features require modifications to the thunk code for thunker support.
2) Any applications which use the custom capabilities are not supported under thunking since we have no way of knowing what size data (if any) is being passed.If this is a real issue, then people should speak up.
Jim Watters
For end-users, the big problem is “legacy” products. It doesn’t make business sense for hardware vendors to invest engineering time in drivers for products that are not currently shipping.
As mentioned, it generally isn’t hard to build both 32- and 64-bit DS’s from the same (portable, well written) source code. For us, the big problem is some of our builds include third party libraries provided as 32-bit binaries. We have not been able to get the vendors to provide 64-bit libraries because nearly all applications are still 32-bit; the demand for 64-bit libraries is negligible. That’s our problem but I bet other hardware vendors have their own obstacles.
When (if?) TWAIN 2 becomes ubiquitous, vendors will release both 32- and 64-bit drivers. Providing a twunk would help bridge the gap as it did for the 16- to 32-bit transition.
–scanner vendors should build their 32 & 64 bit TWAIN 2.x drivers then use WIA-on-TWAIN to obtain WIA drivers and the world is a better place.
Well, no argument – I want a better world too – which of course means better TWAIN drivers. 8)
Hi Doug! Heh – I know about 32-bit-only libraries! Just getting around to building 64-bit versions of EZTwain.
So I guess I’ll go have some interesting conversations with my customers about 64-bit TWAIN…
OK, so I wrote a 64-bit to 32-bit TWAIN bridge: It makes your 32-bit TWAIN sources appear as 64-bit sources. It doesn’t handle *all* the DAT_ formats, but it does capabilities, native and memory transfers, and some other stuff, enough to be useful for basic scanning.
I’m looking for people who would be interested in trying a very early alpha release.
You can contact me via the [pm] button below, or: support@dosadi.com
Update: I’ve got a TWAIN 64-to-32 bit bridge 1.0, and I’m seeking beta-testers. It should work with any 64-bit TWAIN application running on Windows. You need at least one 32-bit TWAIN device, and you need to have or install the 64-bit TWAIN DSM, link available on twain.org.
The preliminary product page is here:
http://www.dosadi.com/twain-bridge.htmI am willing to be an alpha tester for the bridge. The preliminary product page link seems to be dead.
Yikes, let me see if I can find the code for that! I’ll probably have to just open-source it on GitHub or something, I am going to have minimal time to work on it in future.
RaymanI’m currently facing the same problem that I need to use a scanner with 32 bit only drivers from within a 64 bit application. Is the software bridge and an installation guideline available somewhere here?
Thanks!
StefanMarkAll thunking systems work the same way. A separate process in the targeted architecture is launched (32-bit in this case), and some kind of IPC goes on between it and the 64-bit application. If you need access to the scanner’s user interface, you’ll need to write something yourself, unless you can get access to Spike’s solution. If you only need to set some values and scan, you might look at something like ExactCode’s cliscan, which is a command line interface to TWAIN drivers, and see if that does the trick.
- AuthorPosts