benjamin.ducke@ufg.uni-kiel.de wrote:
As far as I understand, we need two things:
1. A native Windows graphics device, so we won't need an X Server
for the graphics output.
2. A BSD style sockets interface, so the d.* commands can communicate
with the graphics device.
Correct.
Now, as far as I understand, point (1) has been taken care of via the W11
driver which is already in the current GRASS code base (?)
Correct.
That would leave the sockets problem.
I am not 100% sure about this, but it seems all we need is to adapt the
code for native win, so that the Windows sockets interface will be used for
that platform?
Its specifications seem to indicate that WinSocks can handle BSD style
sockets as well: http://tangentsoft.net/wskfaq/general.html.
Yes and no.
Although WinSock is modelled on the "BSD sockets API", the problem is
that the BSD sockets API isn't actually a self-contained API, but an
extension to the core Unix API.
So, while WinSock provides BSD-style socket(), bind(), listen(),
accept(), connect() etc functions, it differs in one very important
aspect.
The descriptors which those functions return on Unix are normal file
descriptors, which work with read() and write(), and can be passed to
fdopen() to get a FILE* which works with the <stdio.h> functions.
OTOH, the WinSock versions return an abstract handle which doesn't
appear to be compatible with the POSIX functions in the MSVCRT.
Looking at MSDN, it appears that you ought to be able to convert the
SOCKET to a descriptor using _open_osfhandle(), but I never got it to
work.
Or do we need a more complex compatibility layer, such as provided by
the Mozilla cross platform SDK:
http://www.xulplanet.com/tutorials/mozsdk/sockets.php ???
There's no need to go that far. It would be easier to just have
separate Unix and Windows versions of all the relevant functions than
to use a third-party layer such as NSPR or APR.
If anyone could cut out the work that needs to be done more precisely
for me, I would like to give it a try ...
Essentially, the code in lib/gis/unix_socks.c (which will use WinSock
SOCKETs) needs to be reconciled with the code which requires
descriptors, namely:
lib/raster/io_sock.c
lib/raster/rem_io.c
lib/driver/main.c
lib/driver/connect_sock.c
lib/driver/command.c
You can probably get around the use of read() and write() by using
recv() and send() instead. The latter functions are part of WinSock,
so work with SOCKETs.
Note that you'll need to use -DUSE_TCP to use TCP sockets instead of
Unix-domain sockets.
Alternatively, you might be able to use Windows named pipes instead;
AFAICT, those are closer to Unix-domain sockets than to Unix named
pipes.
--
Glynn Clements <glynn@gclements.plus.com>