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

[Eric S. Raymond]

Matt <address@hidden>:
> Er, I think it was me a couple of years back, I dunno :-)
> Just call me Matt.

There was somebody else - IIRC, a Dave somethingorother with a British
typing accent.
 
> There are two possible goals to a cygwin/mingw port:
> 
> 1. A libgps DLL that is capable of being linked into client
> applications, which can connect to gpsd on another fully-supported
> machine and give Windows client programs the most natural method of
> access to unchanged gpsd running on currently-supported platforms;
> and
> 2. A gpsd binary that runs on Windows and provides equivalent
> functionality to gpsd on POSIX systems.
> 
> Cygwin can definitely support the first use case, but probably not
> the second.
> For the second to work, we should talk to the native Windows APIs.

Understood.
 
> Eric, I take it that you understand the difference between cygwin
> and mingw? Briefly:
> - Cygwin is an attempt to provide a POSIX/Linux-like API on Windows,
> complete with 'fork' emulated in a DLL;
> whereas
> - Mingw is a port of the GNU toolchain to Windows, with open source
> headers matching the Windows ABIs.

Also understood.

> 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.

> 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.  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.

These are things we can't really estimate in advance.  They have to be
tried out.  Thus, I consider this an exploration mission.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>