[gpsd-dev] Mingw port

[Ukygerkgubiekd Ukygerkgubiekd]

Hi, and thanks for GPSd!
My name's Matt.

I'm wanting to raise the topic of a Mingw/Windows port once again, and show 
some code so you can see the challenges ahead.
So here is an experimental, very hackish port to Mingw (native GCC on Windows):


git://github.com/ukyg9e5r6k7gubiekd6/gpsd.git

Under Debian x64, the mingw branch compiles without warnings and passes all 
regression tests.
Until recently it was splint clean, but recently splint began choking with an 
internal error on libgpsd :-(


Under Windows XP, a minimal configuration compiles cleanly, but I have done 
almost no testing.
cgps.exe can generate network traffic (TCP SYN dport 2479), and some of the 
test*.exe binaries seem to work.

I'm not really intending for folks to pull this, though you may like to 
cherry-pick some of the SConstruct changes.
There's a lot of stuff that's stubbed out, or completely untested.


as the code notes, SOCKET is different to fd on Windows (which is again 
different to Win32 HANDLE).
 
On this particular point, it's fairly easy to use the existing socket_t typedef 
to handle this difference.
This level of abstraction is sufficient to get a TCP-only libgps and its 
dependents.
Some of this has ugly Win32 API calls, where Windows lacked POSIX or *NIX 
functionality, mostly for libgpsd.

I think we have to accept that if we want to get a fully-functional daemon and 
clients on Windows.
So abstraction and modularisation is going to be necessary to hide the ugliness 
and keep things clean.

For example, 

However, Windows has a completely different set of APIs for serial comms, and 
for timing/handshaking/waiting etc.

To get drivers, the daemon and the regression tests working under Windows hence 
requires some abstraction layer over those differences.

My idea is that such a layer could also incorporate the existing differences 
between shm, dbus, QT, sockets and fds.
Your comments appreciated!

Matt