[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
