<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I gave up on running named on Windows long ago, so I generally
      support this direction.</p>
    <p>However, I do use the diagnostic tools (dig, delv, rndc,
      nsupdate) for troubleshooting.  It can be helpful to diagnose from
      the client environment (e.g. thru the same firewalls, anti-virus,
      buggy network stack, and APIs).  The BIND tools are better than
      the windows tools, and using the same tools everywhere is always
      beneficial.<br>
    </p>
    <p>Would reducing support to just the diagnostic tools be a helpful
      middle ground?</p>
    <p>It seems to me that they're much simpler (mostly if not all
      single-threaded) and easier to maintain.  Do they have the same VS
      issues? (I haven't built on windows for some time.)<br>
    </p>
    <p>I don't include tools that assume a local named instance in the
      "diagnostic" category - e.g. named-journalprint, dnstap, etc.  
<br>
    </p>
    <p>First order discriminant function is whether the tool talks to
      the network (to make DNS queries[no, not named!], including
      control) - yes: prefer to keep</p>
    <p>FWIW - YMMV.<br>
    </p>
    <pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 
</pre>
    <div class="moz-cite-prefix">On 29-Apr-21 07:35, Ondřej Surý wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:%3CDB685A3B-2275-4721-8CC2-7AE640EF42B8@isc.org%3E">
      <pre class="moz-quote-pre" wrap="">Hi,

we’ve been discussing the /subj for quite some time and we are either thinking about deprecating the BIND 9 on Windows completely or just handing it over to the “community supported” level.

There are couple reasons for the move:

* Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 features we extensively use (stdatomic.h) which makes us to write a horrible horrible shims on top of Windows API
* No BIND 9 developer uses Windows even as secondary platform
* BIND 9 doesn’t compile on Windows 10 nor with VS2019 and that would require extensive work
* Windows now has WSL2 (<a class="moz-txt-link-freetext" href="https://docs.microsoft.com/en-us/windows/wsl/install-win10" moz-do-not-send="true">https://docs.microsoft.com/en-us/windows/wsl/install-win10</a>) that can be used to run BIND 9 natively

We think that the resources that would require us to support new Windows and Visual Studio versions would be better spent elsewhere and therefore we would like to deprecate the official support for Windows since BIND 9.18 (the next ESV, to be released in 2022), the Windows support for BIND 9.16 will be kept intact.

Now, there are two options:

a) The support will be completely dropped and the official way to run BIND 9 on Windows would be using WSL2
b) A volunteer will step up and improve the Windows implementation to support newer platforms and make it up to par with POSIX platforms.

1. Let me be absolutely clear here - we are not interested to keep the Windows port just on the life support, that would miss the point. It has been neglected for too long and if we are to keep it, there are several other areas that would need an improvement - the installer, the system integration and the build system would have to be extensively improved as well.

Thanks,
Ondrej
--
Ondřej Surý (He/Him)
<a class="moz-txt-link-abbreviated" href="mailto:ondrej@isc.org" moz-do-not-send="true">ondrej@isc.org</a>
</pre>
    </blockquote>
  </body>
</html>