Umm, Don? With all (cough, cough) due respect:
you don't know what you're talking about.
Umm, Rafe? With all (cough, cough) due respect: you are clearly not a
programmer.
"OS calls all over the place." The horror!
Keep an eye on the ball and pay attention to *context*!! Not "all over
the place" as in "many" but as in "out of sequence or superfluous".
When the same calls are made repeatedly (not to poll!) or specific
calls are out of *required* sequence, etc - that's a mess! The horror
indeed! No wonder the program falls over even if you just look at it.
Umm, Don. That's what happens. That's the way it's done.
Umm, Rafe. That's not what happens. That's not the way it's done e.g.
you don't read the file first and then open it! (That, BTW, is just a
simple abstract illustration, so don't get hung up on it literally.)
Now I grant you some folks over-use OS facilities,
On the contrary! Calling the OS when a feature is available is *the*
preferred way of doing things for a number of reasons e.g. why
re-invent the wheel and future-proofing - to name two.
but it would
be hard to prove that from the object code. It's hard enough
to do even if you *have the source.*
Now I *know* you're not a programmer. Looking at the source code you
may *think* the program is doing one thing, but only stepping through
the machine code will actually tell you what *really* happens. CS 101.
That's what bugs are! The programmer *thinks* the source is doing one
thing, but the actual code does something else. Debugging 101.
You can't claim to know anything of the structure of a modern
application (like NikonScan or Vuescan) from the object code.
There are layers of abstraction and hierarchy that would take
a lifetime to divine.
I don't know how many times I've repeated this but you folks just
never seem to learn. Perhaps you should laminate this:
When Don makes a statement it's based on fact. If the fact is not
included it's only because of space constrains and/or to make the
message easier to comprehend. Do not read into that! Don does *not*
bluff! So, when Don is challenged he calmly produces the goods.
Therefore, since you asked...
NOTE: You will need a hex editor for this. The hex digit in front is
the offset from *file* start!
I've partially disassembled two NikonScan TWAIN module versions (3010
& 3013). Specifically, LS5000.md3 because that's what drives my LS50
so the following applies *ONLY* to this module and version!!! <===!!!
*----------- version 3010 ------------------------------------------
* 100650A3 - change from 31 to 34 hex to turn on multiscanning
*----------- version 3013 ------------------------------------------
* 10065013 - change from 31 to 34 hex to turn on multiscanning
This will turn e.g.:
100650A1 83 C1 31 add ecx,31h * add 49 caps
into
100650A1 83 C1 34 add ecx,34h * add 52 caps
Actually, this doesn't really turn on multiscanning per se, but fools
TWAIN into thinking it's talking to an LS-5000. The 49/52 is the
number of capabilities (I call "caps" above) each scanner has.
So, turning on multiscanning for the LS-50 this way won't do you much
good because the firmware in the scanner will override it. However,
doing this will make NikonScan drop down the box (!) and let you set
multiscanning but that won't do anything due to the firmware override.
What's more useful is increasing maximum exposure for all channels
(Master, RGB & Gray). Having found where and how it's done I set it to
+16 (instead of the default +2). Don't bother asking, BTW... I will
tell you, however, that max EV values are stored as double precision
floating point.
Now, what were you saying, Rafe...?
Don.
