I think it is unlikely that they would have written processor specific
software. Maybe some byte ordering problems, but these should have been
handled in separate wrappers. Chances are they only have to compile on
MacIntel to create a so called 'fat binary'. But it is work.
Maybe Don can comment?
Unfortunately (or fortunately? ;o)) I have no experience with the new
Macs.
However, speaking purely theoretically, even if we ignore the obvious,
there are major differences between Windows and Mac drivers due to how
the two platforms work. On the other hand, it's still unclear AFAIK if
Intel Macs can be "convinced" to run Windows, for example? But even if
they did, there are just far too many variables to guess.
Byte ordering is system specific, but that should not be a problem
because file formats like TIF can handle both and proper software can
convert if necessary after reading the TIF header.
Anyway, for what it's worth, this is a blurb from the developer's
notes about what happens when the "module" (read: TWAIN) is loaded on
a Mac. Do note that all this is before the new Intel Macs!
--- start ---
For the Macintosh environment, the module will consist of a Fat file
in the System Folder, with the data fork being a
CFM library, usable from PowerPC Macs. The resource fork will contain
all of the resources necessary to run the module
along with a resource of type 'MAID' which will represent the object
code needed to run from 68k Macintoshes. On the
PowerPC the client will call GetDiskFragment() and pass the result
into a UPP descriptor for the MAID entry point. On
68k the client will load the correct code resource, lock the handle,
and then typecast the data as a pointer to the MAID
entry point.
--- end ---
Don.