TWAIN FAQ Excerpts
The information below are excerpts from the FAQ page
found in the TWAIN
Working Group's website.
TWUNK_16.exe
Question: What is the exact role of the 16-bit TWUNK_16.EXE for 32-bit Windows TWAIN scanning? Is it possible to disable it?
Under MS Windows there are two TWAIN Data Source Manager modules, the 16-bit TWAIN.DLL and the 32-bit TWAIN_32.DLL. Each one when loaded will attempt to start the other one through one of the TWAIN Thunker modules (TWUNK_16.EXE or TWUNK_32.EXE) so it could enumerate all the TWAIN Data Sources installed on the system, both 16 and 32-bit. Without TWUNK_16.EXE TWAIN_32.DLL (and the application that loaded TWAIN_32.DLL) would be unable to see any 16-bit Data Sources. And without TWUNK_32.EXE TWAIN.DLL would be not able to see 32-bit Data Sources.
One problem usually reported about TWUNK_16.EXE is seeing it being loaded in memory when a 32-bit TWAIN Application loads TWAIN_32.DLL, even tough there are absolutely no 16-bit TWAIN Data Sources installed.
The TWAIN Thunker could be disabled manually under Windows 9x or NT by removing TWUNK_16.EXE and TWUNK_32.EXE from the %System% directory (e.g. the "Windows" or "WinNT" directory, the directory where Windows is installed). Without TWUNK_16.EXE 32-bit TWAIN Applications could still load TWAIN_32.DLL and use 32-bit Data Sources. Same thing is true for TWUNK_32.EXE and 16-bit TWAIN Applications and 16-bit Data Sources.
Under newer versions of Windows such as Windows 2000 and XP the TWUNK_16.EXE and TWUNK_32.EXE files (along with TWAIN_32.DLL and TWAIN.DLL) are considered system protected files and if they are removed Windows will attempt to restore them immediately from the original installation files.
A second problem often reported about TWUNK_16.EXE is have it remaining loaded in memory after a 32-bit TWAIN application is closed or crashes. The explanation for this would be that a 32-bit TWAIN Application (such as Imaging under Windows 2000) would always cause the 16-bit TWAIN thunker to be loaded (even if no 16-bit Data Sources are installed the 32-bit TWAIN Data Source Manager - TWAIN_32.DLL - needs to search for 16-bit sources; again, TWUNK_16.EXE is a 16-bit program that communicates with the TWAIN_32.DLL over DDEML and allows a 32-bit TWAIN Application to access transparently 16-bit Data Sources together with 32-bit ones). If the application crashes, TWUNK_16.EXE could be left running in background (the system won't shut it down automatically) along with any 16-bit Data Source DLLs that could be loaded with it. The solution would be to manually shut down TWUNK_16.EXE after an application crash, before to restart the application. From Windows 2000 or NT go to the Task Manager (Ctrl + Alt + Del), see the list of running processes and kill the TWUNK_16.EXE one (also WOWEXEC.EXE if you there are not other 16-bit applications running at that time).
TWAIN and Visual Basic
Question: Is it possible to write a Windows TWAIN Application using Visual Basic or other high level programming language that doesn't allow modifying the main application's message loop?
Yes, it is possible, but it will be much easier if you use one of the TWAIN ActiveX/COM controls/libraries available on the market today. The use of memory pointers, handles, TWAIN capability containers and the need to alter the main application's message loop make it difficult to use a high level language such as Visual Basic.
The recommended solution to develop a Visual Basic (or other high level language) TWAIN Application is to use one of the TWAIN ActiveX/COM controls/libraries available on the market today. Some of these ActiveX controls are very well developed and would let the application use the full TWAIN programmatic functionality that TWAIN Data Sources might support - in most cases using a very simple set of ActiveX control properties, methods and events, saving the transferred images to disk files in formats easily recognized by the image/picture controls in Visual Basic and other similar languages.
To develop very basic, simple, limited usage TWAIN application support, a Visual Basic application could do the following:
1. Open the Data Source
2. Set MSG_XFERCOUNT to 1
3. Enable the Data Source modally (TW_USERINTERFACE.ModalUI set to TRUE)
3. Start a local message loop (using PeekMessage/GetMessage and TranslateMessage
Win32 APIs) to wait for the first message to come from the Source.
4. If MSG_XFERREADY is received, transfer one image then end the transfer.
5. Discard any pending transfers if there are any and disable the Data Source.
6. This means no complex capability negotiation, just one image transfer
per MSG_ENABLEDS/MSG_DISABLEDS sequence.
7. If MSG_CLOSEDSREQ is received instead of MSG_XFERREADY, consider the session
canceled and disable the Data Source. Such an application would need to load
TWAIN_32.DLL and connect to its exported
DSM_Entry.
|
|
 |
|
