@jimwatters wrote:
How is Apple getting around this on 64bit if they are passing pointers?
I don’t know. My app was 32-bit, so I was able to use it to pass along an Objective-C self pointer.
However, according to the file command, the TWAIN binary for OS 10.5 supports four architectures: ppc7400, ppc64, i386, and x86_64. OS X also supports thread-local storage (not that it’s hard to implement on your own). And, of course, you can just be dirty and use a global, if you are sure it won’t be an issue for your app.
Modifying the application name might unwanted have side effects. Some DS choose to store the last used settings for each Application name that opens it. If the name keeps changing you might not get the settings you expected.
In that connection, I noticed that the DSM will let you open multiple appId blocks, as long as the product names are different (it doesn’t consider the manufacturer or product family fields). I assume that’s what you would need to do if you wanted to drive multiple devices simultaneously. The message queue that the Windows window handle supports is per-thread, and the handle is per DSM app, not per source. So, to drive eight scanners at once, you would start up eight threads, each of which would open the DSM with a slightly different product name … ScannerMaster 1, ScannerMaster 2, etc.
BTW, I found that my problem with the dummy software datasource hanging under DSM 2 went away if I supplied a window handle on the open. I had ripped out the window handle code, so I put it back in.