windows support
As mentioned in #14 I wanted to support windows, but some problems arose, namely
The winapi doesn't have a standard API for accessing the default DNS server as configured at the interface.
It seems the approach would be to iterate over all interfaces listed in the registry under HKLM:\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces, then find the currently active one and then query the DhcpNameServer key. this then would either require a dependency on zigwin32, or direct calls to the win32 api, as the zig standard library does not expose the required calls.
With
I believe standard library shells out to some native windows api without reading dns name servers ~ @lun-4
do you mean during DNS lookups in the stdlib? As far as I could tell from the winapi docs, there are only API's for querying a domain directly, through windows, but this library would require a connection object. we could do target specific extern to winapi's, which would be inline with what the stdlib does, but still have nasty dns registry lookups. If you have a better approach, I'd be happy to hear it, otherwise I can look around a bit to see what other libs are doing.
okay, this made me look at stdlib and (zig 0.13.0):
while (true) {
const rc = ws2_32.getaddrinfo(name_c.ptr, port_c.ptr, &hints, &res);
switch (@as(windows.ws2_32.WinsockError, @enumFromInt(@as(u16, @intCast(rc))))) {
since zigdig's core purpose is to be upstreamed, then we should look as much as stdlib's behavior as possible. this implies only adding windows support on getAddressList() since that's the primary API stdlib will expose for dns, and leave a @compileError if someone tries to use connectToSystemResolver() on windows.
Alright, I'll take a stab at implementing this
should this issue be closed now that the PR is merged?
Yes, I'll close this