[bind10-dev] Windows support status

[Shane Kerr]

Francis,

On Fri, 2011-04-22 at 14:26 +0000, Francis Dupont wrote:
> I first tried to build libraries as DLL but in fact the DLL idea is
> very bound to C and is incompatible with C++, so I changed my mind
> and built static libraries. Note if we create a C++ -> C wrapper
> to use bind10 libraries from C, wrapped objects will be good
> candidates for DLLs.

Interesting... this exact same problem exists in Unix, and would
probably be solved in the same way (C++ -> C wrappers).

> I found two problems which can't be simply solved (so I stopped at
> the cc library, I ported only exception and dns libraries):
>  - the cc library uses local (aka PF_UNIX) sockets. The obvious fix
>   is to moved to local TCP/IP sockets or to switch to something else,
>   but this is not trivial and needs some coordination.

As discussed, we're probably going to be replacing the existing msgq
communication channel stuff. We have a ticket for this:

http://bind10.isc.org/ticket/765

It's currently lower priority than getting our TSIG and logging working,
but will probably pop up at the beginning of the next 6-week release
planning. :)

>  - open socket file descriptors are transmitted using a PF_UNIX socket
>   feature. This is highly not portable but the function can be
>   performed another way on Windows so I proposed a two step plan:
>    * offer as an alternative the use of /proc (note the idea is
>    not to replace PF_UNIX, /proc is in fact less portable but
>    its interface is very closed to the second step)
>    * use WSADuplicateSocket() on Windows (the another way)

I'm still not sure why /proc would be helpful here. The code is in
src/lib/util/io/fd_share.{cc,h} and is about 200 lines, although that is
closer to 150 without header copyright boilerplate. Make a completely
separate implementation for Windows seems like the easiest way forward,
IMHO.




Another issue for a straight Windows port is the Boss process (the main
BIND 10 program). It uses the Python subprocess module, so there should
not be too many issues in terms of starting/stopping processes, but the
signal handling will need to be investigated (probably skipped
completely in Windows).

A more tricky issue is that ideally BIND 10 will be a "nice" Windows
program, with a graphical installer (and configuration?) and integration
with Windows start-up and so on. I'd like to see a nice system tray
thingy for integrating with the resolver, for example.

An even bigger issue is that AFAICT everybody runs BIND 9 on Unix
systems, so nobody really cares about BIND under Windows. Maybe we can
change that though?

--
Shane