[sane-devel] sane-backends-WIN32

Oliver Rauch Oliver.Rauch@Rauch-Domain.DE
21 Jun 2004 20:35:21 +0200


Thnaks for that hint. I will test if this works with cygwin.

Oliver

Am Mon, 2004-06-21 um 15.12 schrieb Dave Burns:
> I hope I'm not completely out of context since I only get the digest and
> have not been following this thread. But the following caught my eye:
> 
>   "With xsane the stdout and sterr are not available because it is compiled
> as GUI."
> 
> As a WIN32 programmer for years, I know this doesn't have to be true. Use
> the following code to open a Win32 console window and rewire stdout/stderr
> to its output. Wrap the whole thing in a conditional that's true if you want
> debug output. Hope this helps. If I'm off topic, apologies.
> 
> db
> 
> 
> 
> #include <windows.h>
> #include <io.h>               /* For _open_osfhandle( ) */
> #include <fcntl.h>            /* For _O_TEXT */
> 
> {
>   int hCrt_StdOut;
>   int hCrt_StdErr;
>   FILE *hf_stdout;
>   FILE *hf_stderr;
> 
>   /* First create the console. This only opens the window. This will fail if
>      we are already running from a console window (which means we don't need
>      to connect any output streams). */
>   
>   if (AllocConsole()) {
>     HANDLE stdoutBuffer;
>     CONSOLE_SCREEN_BUFFER_INFO bufferInfo;
>     
>     /* Now connect the Win32 STD_OUTPUT pipe to the c-runtime stdout stream
> */
>     
>     stdoutBuffer = GetStdHandle(STD_OUTPUT_HANDLE);
>     hCrt_StdOut = _open_osfhandle((long) stdoutBuffer, _O_TEXT);
>     hf_stdout   = _fdopen(hCrt_StdOut, "w");
>     *stdout = *hf_stdout;
>     /*    setvbuf(stdout, NULL, _IONBF, 0);*/
>     
>     /* Now connect the Win32 STD_ERROR pipe to the c-runtime stderr stream
> */
>     
>     hCrt_StdErr = _open_osfhandle((long) GetStdHandle(STD_ERROR_HANDLE), 
>                                   _O_TEXT);
>     hf_stderr   = _fdopen(hCrt_StdErr, "w");
>     *stderr = *hf_stderr;
>     setvbuf(stderr, NULL, _IONBF, 0);
> 
>     /* now we increase the buffer size to 9999 lines. We only do this
>        if we created a console so that we don't mess with a user's
>        existing console. */
>     
>     GetConsoleScreenBufferInfo(stdoutBuffer, &bufferInfo);
>     if (bufferInfo.dwSize.Y < 9999)
>       bufferInfo.dwSize.Y = 9999;
>     SetConsoleScreenBufferSize(stdoutBuffer, bufferInfo.dwSize);
>   }
> }
>  
> 
> -----Original Message-----
> From: sane-devel-admin@lists.alioth.debian.org
> [mailto:sane-devel-admin@lists.alioth.debian.org] On Behalf Of
> sane-devel-request@lists.alioth.debian.org
> From: Oliver Rauch <Oliver.Rauch@Rauch-Domain.DE>
> To: sane-devel <sane-devel@lists.alioth.debian.org>
> Organization: 
> Date: 19 Jun 2004 13:44:12 +0200
> Subject: [sane-devel] sane-backends-WIN32
> 
> Hello.
> 
> Here a little experience report with sane-backends on WIN32.
> I used xsane-win32-0.94-sane-1.0.14-complete-no-gimp.zip for my tests with a
> UMAX Powerlook III SCSI-scanner on Windows 2000.
> 
> I can create debugging messages with
> set SANE_DEBUG_UMAX=12
> or
> set SANE_DEBUG_SANEI_SCSI=128
> and scanimage. 
> 
> With xsane the stdout and sterr are not available because it is compiled as
> GUI.
> 
> The status is:
> 1) xsane recognices the scanner without any changes.
> 2) The xsane interface comes up with correct options
>    => INQUIRY is done without problems
> 3) Starting a scan or a preview makes two problems:
>    a) SCSI Buffer size seems to be limited to 32KB,
>       that is too small for this scanner in Color mode.
>       Increasing the size by umax.conf options does not work.
>    b) the START_SCAN command returns with I/O Error.
> 
> The SET_WINDOW command and SEND_GAMMA_DATA in grayscale mode does not make
> any problems.
> 
> It is encouraging that the INQUIRY, SET_WINDOW and SEND_GAMMA_DATA commands
> work without problems. I do not have an idea why the START_SCAN command
> fails.
> 
> Please also report your experiences with sane-backends on WIN32.
> I think that we only have to do some little sourcecode changes to make it
> work. If we succeed with this then SANE gets the chance to be THE SCANNER
> DRIVER STANDARD and may be one day the manufacturers start writing their own
> (windows) drivers as SANE driver.
> 
> Best regards
> Oliver
> 
> 
> 
> --__--__--
> 
> Message: 2
> Date: Sat, 19 Jun 2004 14:09:17 +0200
> From: Kees Lemmens <C.W.J.Lemmens@ewi.tudelft.nl>
> To: sane-devel@lists.alioth.debian.org
> Subject: [sane-devel] Re: strange rattle in epson 610 with 2.6.7 kernel
> 
> Hi,
> 
> First problem : rattle epson 610 (solved)
> -------------
> 
> Just installed sane 1.0.13 and this works fine under 2.6.7. However turning
> back to sane-1.0.12 immediately gives the alarming rattle back ...
> 
> BTW: I used this script to test without having to reboot/reinstall :
> ####################################################################
> #!/bin/sh
> 
> #SANE=/opt/sane-1.0.13 # Newer xsane release
> SANE=/usr/             # Standard sane-1.0.12 from Slackware 9.1
> 
> export LD_LIBRARY_PATH=$SANE/lib/
> export LD_PRELOAD=$SANE/lib/libsane.so
> 
> exec /usr/bin/xsane $*
> ####################################################################
> 
> Second problem : compile 1.0.14 under Slackware fails
> --------------
> 
> Whatever I try sane-1.0.14 doesn't compile under Slackware 9.1 !!
> configure fails to detect the presence of basic routines like "strdup",
> "getenv" and others under Slackware 9.1, thereby making it impposible to
> compile (at least on my system).
> 
> Any ideas ?
> 
> giant:/tmp/sane-backends-1.0.14 252 % make making all in include
> make[1]: Entering directory /tmp/sane-backends-1.0.14/include'
> make[1]: Nothing to be done for all'.
> make[1]: Leaving directory /tmp/sane-backends-1.0.14/include'
> making all in lib
> make[1]: Entering directory /tmp/sane-backends-1.0.14/lib'
> gcc -c -DHAVE_CONFIG_H -I. -I. -I../include/sane -I../include
> -DPATH_SANE_CONFIG_DIR=/opt/sane-1.0.14//etc/sane.d
> -DPATH_SANE_DATA_DIR=/opt/sane-1.0.14//share    -DV_MAJOR=1 -DV_MINOR=0
> -I/usr/local/include/gphoto2 -g -O2 -W -Wall getenv.c
> getenv.c:13:4: #error "Missing getenv() on this platform.  Please
> implement."
> getenv.c: In function getenv':
> getenv.c:6: warning: unused parameter name'
> make[1]: *** [getenv.o] Error 1
> make[1]: Leaving directory /tmp/sane-backends-1.0.14/lib'
> make: *** [all-recursive] Error 1
> 
> giant:/tmp/sane-backends-1.0.14 254 % less include/sane/config.h ...
> /* Define to 1 if you have the getenv' function. */
> /* #undef HAVE_GETENV */
> ...
> /* Define to 1 if you have the strcasecmp' function. */
> /* #undef HAVE_STRCASECMP */
> 
> /* Define to 1 if you have the strdup' function. */
> /* #undef HAVE_STRDUP */
> 
> 
> Bye,
> Kees Lemmens
> 
> On Fri, Jun 18, 2004 at 09:40:03AM +0200, Kees Lemmens wrote:
> > Hi,
> > 
> > I have an Epson Perfection 610 which worked fine for 2 years with 
> > 2.2.x and 2.4.x.
> > 
> > Today I compiled 2.6.7 and now it suddenly produces strange and 
> > alarming sounds after the scan is finished and it returns to initial
> position.
> > 
> > I thought the scanner failed, but after rebooting in 2.4.26 it works 
> > fine again, so I am afraid it must be something in the 2.6.x kernel 
> > combined with the sane 1.0.12 backend that I use (the one provided 
> > with Slackware 9.1).
> > 
> > Any suggestions ? Should I just install the latest backend or is it 
> > something else ?
> > 
> > --
> > Bye,
> > Kees Lemmens.
> > ----------------------------------------------------------------------
> > -
> > NOTICE: I consider all HTML based email as SPAM : forward => trash
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> sane-devel mailing list
> sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> 
> 
> End of sane-devel Digest
> 
>