 |
|
| View previous topic :: View next topic |
| Author |
Message |
spike
Joined: 27 May 2005
Posts: 69
Location: Vashon, WA
|
 Posted: Tue May 11, 2010 2:24 pm Post subject: 64-bit problem in TWAIN 2.1 spec and Twain.h |
 |
|
I'm porting my EZTwain library to 64-bit Windows (x64) and I think I have noticed a potential problem in the TWAIN 2.1 spec and Twain.h
Throughout the spec, Native image transfer is described as transferring a TW_UINT32 i.e. a 32-bit word or DWORD. But on Windows what is being transferred is a global HANDLE, and in 64-bit model, that's a 64-bit value.
Now maybe 64-bit HANDLEs actually only use the low 32 bits - but I suspect not. If I'm correct, then both Twain.h and the TWAIN spec need to be corrected.
The definition of DAT_IMAGENATIVEXFER has always been a bit 'funny' and inconsistent with other DATs, so this could be a good time to make things consistent, as well as portable and correct.
We would add the following structure to Twain.h: | Code: |
/* DAT_IMAGENATIVEXFER. Used to pass an image from DS to app. */
typedef struct {
TW_HANDLE hNative; /* Windows: global memory handle */
/* Mac OS: PicHandle */
/* *nix: ptr to malloc'd block?? */
} TW_IMAGENATIVEXFER, FAR * pTW_IMAGENATIVEXFER;
|
...and make this edit:
| Code: | | #define DAT_IMAGENATIVEXFER 0x0104 /* TW_IMAGENATIVEXFER */ |
In the spec, find all references to DAT_IMAGENATIVEXFER, replace use of 'TW_UINT32' with TW_HANDLE member of TW_IMAGENATIVEXFER structure. And maybe also document what is passed by this triplet on Unix/Linux.
Since I'm the one complaining, I'm willing to submit a detailed set of edits for the spec, if somebody wants.
Boy, I hope I'm not the first person to code a native transfer in 64-bit?? |
|
| Back to top |
|
 |
dpenney
Joined: 21 Nov 2005
Posts: 63
|
| Posted: Thu May 13, 2010 9:06 am Post subject: Re: 64-bit problem in TWAIN 2.1 spec and Twain.h |
|
|
| spike wrote: | | Throughout the spec, Native image transfer is described as transferring a TW_UINT32 i.e. a 32-bit word or DWORD. But on Windows what is being transferred is a global HANDLE, and in 64-bit model, that's a 64-bit value. |
A TW_HANDLE is a Windows HANDLE which, on x64, is 64-bits. The specification probably refers to a TW_HANDLE as a 32-bit value because that's the way it was defined back when they wrote the 1.x spec. It never got updated in the 2.x spec. You can still find references to 16-bit Windows in the specification! Fortunately, the TWAIN header defines TW_HANDLE correctly.
| spike wrote: | | Boy, I hope I'm not the first person to code a native transfer in 64-bit?? |
Nope. Try the TWAIN 2.1 sample application provided by TWG. It (sorry for the pun) handles native transfers correctly using 64-bit handles.
- |
|
| Back to top |
|
|
spike
Joined: 27 May 2005
Posts: 69
Location: Vashon, WA
|
| Posted: Fri May 14, 2010 12:17 am Post subject: 64-bit problem in TWAIN 2.1 spec and Twain.h |
|
|
Hi Doug - Well, I'm glad to hear there is working code, I'll check out the sample app.
However, I want to clarify that the problem with the spec and native transfer is not what you speculate. Quite the contrary: The spec says repeatedly and consistently that native transfers transfer a TW_UINT32. Not a '32-bit value' a TW_UINT32. That's what it says in the comments in Twain.h, and that's what it says throughout the 2.1 spec. It's absolutely consistent, including the sample code fragments embedded in the spec.
None of the discussions of native transfer mention TW_HANDLE.
While you and I can be confident that TW_HANDLE must be 'what they meant', anybody who naively writes application or driver code based on the TWAIN specification is going to get it wrong. Imagine the bugs! A driver that does Native transfers successfully *until* it happens to generate a handle above the 4GB line. Or an application with the same bug, plus it has a 32-bit variable being overwritten with a 64-bit value. Which works fine until you move the variable into a struct or class with 4-byte alignment...
I think the 2.1 spec needs some major work to cover either Unix/Linux, or 64-bit platforms. Currently you can't write code for any of those platforms by reading the spec. |
|
| Back to top |
|
|
dpenney
Joined: 21 Nov 2005
Posts: 63
|
| Posted: Fri May 14, 2010 6:39 pm Post subject: Re: 64-bit problem in TWAIN 2.1 spec and Twain.h |
|
|
| spike wrote: | | ...The spec says repeatedly and consistently that native transfers transfer a TW_UINT32. Not a '32-bit value' a TW_UINT32. That's what it says in the comments in Twain.h, and that's what it says throughout the 2.1 spec. It's absolutely consistent, including the sample code fragments embedded in the spec. |
The documentation is wrong all over the place but it's still just a documentation problem. Spec 2.1, page 3-30 says the 6th parameter (pData) "is a pointer to a handle variable...If running under the WIN32 environment, this is a 32 bit window handle". That's our clue that it's going to point to what ever size a handle is on x64.
| Quote: | | While you and I can be confident that TW_HANDLE must be 'what they meant', anybody who naively writes application or driver code based on the TWAIN specification is going to get it wrong. |
Very true. The TWAIN spec is way too vague in places and just plain wrong in others, not to mention it has a few contradictions. Developers shouldn't have to guess what it means or figure it out by trial and error. The specification is suppose to spell it out.
I bet the problem is the TWG has too many programmers and not enough technical writers (maybe none). Programmers like to write code not documentation.
| Quote: | | I think the 2.1 spec needs some major work to cover either Unix/Linux, or 64-bit platforms. Currently you can't write code for any of those platforms by reading the spec. |
There are even some pitfalls when coding Win32 from the spec. It's a sure sign that a spec is poorly written when you can't code from it. I remember it was tough going when I first got involved in TWAIN. A clear, concise TWAIN specification would have made that road much smoother.
- |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
