Re: [gpsd-dev] [PATCH]: Handle lack of TIOCEXCL and TIOCNXCL on cygwin

[Matt]

On 06/09/14 23:37, Eric S. Raymond wrote:
[snip]
> > It's really quite trivial to port gpsd to cygwin. The challenge is
> > with mingw.
> > For example, under Win32, serial/USB devices are accessed via
> > totally different APIs.
> >
> > The naive approach would be to introduce thin abstraction layers
> > over the POSIX/Win32 API calls:
> > non-system-specific libgps[d]APIs in header files, and
> > system-specific code in the corresponding *.c files, which contained
> > ugly '#ifdef _WIN32' directives.
> >
> > Eric, would you accept a series of patches along the lines above?
> Yes, though I'd probably end up reorganizing the hell out of the resulting
> code to keep the Windows stuff properly isolated.
No, rest assured, precisely this sort of isolation is my intention.
The exploratory cygwin/mingw port I did previously makes me believe that 
this is possible, with some refactoring of the existing code so that 
serial/usb/etc access is abstracted away nicely.
> > serial.c is the first cab off the rank: serial port access via the
> > Win32 API is totally different to the current code.
> Let's give that a try.
>
> I do have misgivings.  I don't really want the support burden implied
> by hundreds of millions of clueless Windows users if the port is
> anything but fire-and-forget.
There is potentially a great deal of work involved in doing this 100% 
properly.
The most fire-and-forget would probably be a so-called .NET assembly for 
the client (I know nothing about .NET by the way), and a Windows 
'service' for the server (this I do know).
Each involves a significant amount of Windows-specific code, which 
thankfully I think we can isolate cleanly.

A significant amount of effort, but worth it to get further testing 
exposure/use cases/mindshare.

I earnestly hope that you over-estimate the support burden of naive 
Windows developers!
> Thus, whether we end up carrying it as
> an official port will depend on (a) how stable and non-intrusive the WIN32
> porting hacks look once they're done, and whether (b) you and I can set up
> regression and qualification testing that I have confidence in.
My intention is to focus on getting a Windows port of gpsd talking to 
one of my devices, serial USB bluetooth or whatever. This will be a 
major step; once communication occurs at all, we can start along the 
long road of getting the packet parser/recogniser working.
> These are things we can't really estimate in advance.  They have to be
> tried out.  Thus, I consider this an exploration mission.
Yeah, exactly. The thing is, I already did an explorative port a couple 
of years ago, so I have some (little) idea what challenges lie ahead of us.

Getting binaries compiling shouldn't be that hard or intrusive. It's 
getting access to Win32 serial ports and making sense of the data that 
worries me. I'm [sightly] scared of the packet recogniser.