Hey, just a follow-up with a recent real life example.
I’ve spent few days hunting a problem on Windows that got introduced by a fix to outgoing UDP selection code. While having bugs in normal (and this was really one-liner), it’s abnormal to not have tools for debugging the problem. Here’s the (incomplete) list of things that would have to be fixed: 1. Automatic crashdump collection in our CI - it should work, but it simply doesn’t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries 2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a “cookbook” for developers. 3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives) 4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <— the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly. It’s beyond our capacity to pursue this any further. Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 29. 4. 2021, at 13:35, Ondřej Surý <ond...@isc.org> wrote: > > 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 > (https://docs.microsoft.com/en-us/windows/wsl/install-win10) 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) > ond...@isc.org >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
