Re: Windows port

Milon Firikis (milonf@ariadne-t.gr)
Mon, 31 Aug 1998 02:05:39 +0300

Ian Grant wrote:
>
> Rather than port SANE to Windows, couldn't someone write a TWAIN driver
> for Windows that talks to saned? This would allow people to use their free
> Windows OCR s/w etc that comes with the scanner, provided they have a
> Windows box on their network. It would also enable their Windows machines
> to scan from any scanner on their network.
>
> Ian
>

The above post reflects my opinions almost 100 percent.

Some spots other people missed.

* I don't care if somebody wants to port anything to anywhere since he
is doing the job and not me.

* Porting issues.

SCSI
----
SANE uses a lot the generic SCSI interface. If you miss this you have to
do one of the followings:
a) write a generic SCSI driver (with UNIX semantics) for windows
systems. (ala solaris)
which means that
i) you introduce new instabilities to the system.
ii) you have to maintain different drivers for various Windows
versions.
b) implement the sane_scsi_* commands in sane_scsi.c The place is
already #ifdefed a lot, so some windows #ifdefs won't heart so much.

INTERFACE
---------

Get prepared to code a lot of networking stuff since GTK does not have a
native win32 port so you can't use xscanimage to scan, though plain
scanimage would do it fine I guess. Most of that code should be the
TWAIN interface that it is so badly wanted from most of us, in order to
get working Windows applications scanning. While you are there you could
also code the net middleware that Ian Grant is talking about.

UNIXisms
--------

Some (most) of the SANE backends (drivers) are using pipe() and fork()
in order to use asynchronous I/O. I have already stated that I am
against such UNIXisms in a backend's code, but since I can't code
something better I am keeping my mouth shut. The guy that he is
maintaining the OS/2 port of the SANE had an interesting idea about some
platform independent threading. I certainly believe that a Windows Port
is a good thing because it will address to these matters in a (I hope)
platform independent way, at least as much as sane_scsi.c is.

It is also plausible to use the cygnus solution and leave the fork()
pipe() and other unix stuff as it is. It is ought to work since these
guys at cygnus have ported more difficult stuff than SANE which I must
say is almost ANSI compatible.

All in all:
I believe that a windows port will be a good thing for SANE, and that it
is also feasible for somebody to do it in a non infinite period of time.
Other than the difficulties I already mentioned, I don't think there
are any other obstacles in the way to a windows port. Am I missing
anything?

Milon Firikis

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com