[sane-devel] Thread code review and testers

[Chris Bagwell]

On Mon, Nov 7, 2011 at 10:55 AM, Michael Cronenworth <mike at cchtml.com> wrote:
> Michael Cronenworth wrote:
>>
>> I'll try the latest git checkout plus this patch and see if it works any
>> better for me.
>
> The latest git + only your patch now compiles on the first try. However, the
> resulting DLL doesn't find the scanner. sane-find-scanner.exe finds the USB
> device, but scanimage.exe and my program that uses libsane.dll do not find
> the scanner.
>
> I had a feeling it is looking for the config file to reference the USB
> vendor ID and product ID, but it cannot find it. I moved the *.conf files
> into the same directory as the runtime DLL and EXE files and now the scanner
> is found. Scanning works, too.

Glad to hear its working!  Your doing better then me so far... but I'm
almost there.

So far, I can't get the preloaded backends to kick in from
libsane-1.dll.  Did you do anything special to get it working?

I just committed a fix to libtool that lets us now correctly build
each individual backend as its own DLL.  I'm not sure I'll get the
urge to fix this soon but it wouldn't be hard to get the dll backend
to load these DLL's now that we are correctly building them.

After that DLL build fix, I can copy libsane-epson2-1.dll to same
directory as scanimage.exe but name it libsane-1.dll and now the
epson2 backend is working with scanimage.exe.

It correctly detects my network epson scanner but then fails to open
the socket correctly.  Hopefully, it will be a simple fix.

>
> I would guess that between .21 and .22 that the config file handling
> changed? It would be nice to have the Windows binaries look for the config
> files in a few sub-directories besides the current directory. (./etc, ../etc
> ./)

The logic was modified but don't see exactly any difference in
behaviour.  The best solution right now is to set SANE_CONFIG_DIR to
where ever you store them.  Maybe in future we can modify to use
standard Windows DLL search logic and look inside same directory as
.exe.  I've never done that before but I guess it wouldn't be hard.

>
> Unfortunately this trick doesn't make the 64-bit DLL work. Something else is
> wrong.

I'm glad to hear in your other post that 64-bit is now working for you as well!

I'm sure there are tons of people that would like to run a native
Windows executable (non-cygwin) from command line/background task to
do some scanning.

Chris