Re: [gtk-vnc-devel] Porting gtk-vnc to Windows (MinGW)

[Anthony Liguori <anthony codemonkey ws>]

Richard W.M. Jones wrote:
> I made a little attempt to port gtk-vnc over to Windows using MinGW & 
> MSYS, because we'd like to use gtk-vnc on Windows in various projects.

Fantastic.  I've contemplated a Windows port so I'm very excited to see 
people working on this!

> The port isn't going to be entirely straightforward, so here are my 
> notes, and attached is the output of 'make -k' after a few iterations 
> so you can see while files don't compile.

Just a quick note, be careful attaching large things on SF lists.  They 
require admin approval so they'll get delayed a little bit before they 
show up.

> (1) getcontext/makecontext:
>
> These are obviously missing on Windows.  Win32 has similar functions 
> 'GetThreadContext' and 'SetThreadContext', and there is an 
> implementation I found of the Unix functions in terms of the Windows 
> functions:

Actually, the similar features are CreateFiber et al.  These provide 
support for coroutines as first class objects.   Unfortunately, these 
aren't very popular APIs and some strange behaviors may be encountered 
using them on various versions of Windows.

I think a good thing to do, and I can help out here as I have some time 
off right now, is to do a thread-based coroutine implementation using 
GThreads.  That should make things Just Work on Windows and on Unices 
that don't support ucontext.

The basic idea behind thread-based coroutines is that you maintain a 
condition and each coroutine becomes a proper thread.  Each thread has 
an id.  There is a per-thread variable that is the currently running 
thread id.  The condition that each thread waits on is whether its 
thread id == the currently running thread id.

This forces the threads to run in lock-step with each other and makes us 
very portable.

> http://www.codeproject.com/KB/threads/ucontext.aspx?df=100&forumid=15621&exp=0&select=847762 
>
>
> I've mirrored the source files from the above page here; the license 
> is LGPLv2:
>
> http://annexia.org/tmp/win32_ucontext/
>
> So that is some hope that the continuation/coroutine stuff can be 
> ported with not too much work.
>
> (2) Socket calls:
>
> gvnc.c:13:24: error: sys/socket.h: No such file or directory
> gvnc.c:14:24: error: netinet/in.h: No such file or directory
> gvnc.c:15:23: error: arpa/inet.h: No such file or directory
> gvnc.c:17:19: error: netdb.h: No such file or directory
>
> When I ported libvirt, I found that most socket calls could be 
> replaced just by modifying the header files to include <winsock2.h>, 
> as in:
>
> #ifndef HAVE_WINSOCK2_H
> #include <sys/socket.h>
> #include <netdb.h>
> #include <netinet/in.h>
> #include <netinet/tcp.h>
> #else
> #include <winsock2.h>
> #endif
>
> A few other changes were needed in libvirt but they weren't very 
> invasive.

Is it possible that glib insulates us from this stuff?  The other 
problem with winsock is that you cannot do a read() from a socket file 
descriptor on Windows (you have to do a recv()).  It should be okay to 
just switch over to always doing send()/recv() since right now, we only 
ever deal with socket file descriptors.

> (3) getaddrinfo:
>
> With libvirt we found that the best idea was to use the Gnulib 
> implementation of getaddrinfo and a handful of other functions.  
> Gnulib is a source library of useful functions which replaces 
> functions where they are broken or missing on a platform (but 
> otherwise leaves code unchanged).  More about Gnulib here: 
> http://www.gnu.org/software/gnulib/
>
> Gnulib also contains wrappers which add missing macros such as 
> F_GETFL, O_NONBLOCK.

Sweet.  Does O_NONBLOCK actually work with gnulib on Windows?  Winsock 
normally supports asynchronous notification by using Window messages so 
you need to create a dummy Window.  This can be pretty insulated in the 
gvnc code of course.

> Would gtk-vnc developers be happy with patches which pull in parts of 
> Gnulib?

I don't mind at all although if O_NONBLOCK doesn't work with sockets on 
Win32 (and I suspect it doesn't), it may be easier to just use the 
winsock gethostbyname function (especially since winsock provides a 
proper asynchronous gethostbyname!).

> (4) Shared memory X11:
>
> Windows completely lacks any X11 calls or Unix shared memory (shmctl 
> etc.)
>
> My reading of the code in vncshmimage.c is that it detects at runtime 
> if MIT-SHM is available and can run with it enabled or disabled.  To 
> get this working under Windows, I think would require #ifdef-ing out 
> any code which uses anything other than pure gdk calls in this file. 
> (However my reading may be wrong ...)

Yup.  I tried to take that into account when writing the code.

> Some shm code also leaks into vncdisplay.c, eg. calls to shmctl to 
> clean things up.

I may actually just remove shm code from the tree since I haven't nailed 
down the protocol extension.

>     -    -    -
>
> Any comments?

Great stuff!  Looking forward to the results.

Regards,

Anthony Liguori

> Rich.
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gtk-vnc-devel mailing list
> Gtk-vnc-devel lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/gtk-vnc-devel