Ye I watch in horror as the poor Zig devs are rushing into the abyss. Like, 'how hard can it be maintaining a minimal posix compatibility layer for Windows?'. Or something.

"Despite your apparent emotional defeat, my take on this is that you successfully pioneered the way forward, and I think the Zig project can carry the torch from here. "

Reading through that thread, it really doesn’t sound like the main Zig developers are going to pursue this.

E.g., I believe the comment you quote is appreciatively acknowledging the hard work a contributor put it, but isn’t accepting the general plan to drop mingw. Generally, the core Zig dev seems to keep gently shifting the conversation back to current Zig goals, not taking on new ones.

(I'm one of the people from the thread)

Although this issue has degraded into a conversation at this point, which is a bit unfortunate and honestly my fault, I feel it's important to mention that the main contributors here (myself, other Zig devs, Andrew Kelley, and others) all know each-other, have either met in person or online, etc. and I believe are all just trying to improve the status quo.

There isn't any decision on "should we drop mingw or not" because we don't actually know what that would look like at all, and that's not really what the issue is about. Better phrased the title would be "Issues with libc headers Zig ships on Windows" Most importantly, our goal is just to improve the status quo of C/C++ dev not just drop mingw out of some philosophical reasoning. If Zig takes on that burden, there needs to be super solid reasoning behind it and it would require some serious investment. If you read Andrew's messages closely, you'll see that is what he is really reiterating constantly.

I don't think anybody in that thread is really opposed to closing the issue and saying we just need to improve/contribute back to MinGW, Wine, etc. In fact, that's the current status quo and thus far, I would say, the most reasonable approach.

It's cool that these conversations are happening with some momentum, though. I'm not aware of many other places where people are actively discussing improving the status quo of Windows C/C++ development.

Good to know, thanks.

I have no fear of abysses:

https://github.com/ziglang/glibc-abi-tool/

https://github.com/ziglang/zig/blob/master/tools/gen_stubs.z...

bring it on

Heh dear God :)

Hi JB! Funny to cross paths with you in this context. I don't know if you remember me but I was a rookie programmer who got the pleasure of joining the VideoLan Conference in Dublin back in 2014, and then Paris the next year, and you were very kind to me.

The GitHub issue title here is unfortunately misleading. I have renamed it to "ideas to improve windows header files and libc". Also, I hope it is clear that I rebutted the points made by the OP, because I completely agree with your summary that the mingw-w64 people are skilled, nice and very clever and think about all use cases.

If any drive-by HN readers work at Microsoft, please help us with this issue: https://github.com/microsoft/win32metadata/issues/766

Yeah, i've been using MinGW (and now MinGW-w64) for practically decades now, originally via MSYS and later via MSYS2 and i never remember having and real issues with it - i even did some DirectX programming with it.

The only thing i remember being an issue at some point (and perhaps still is) is that it relies on msvcrt.dll that theoretically isn't part of the Windows platform but in practice that DLL has been there since Windows 98 and the chances of this ever being a real problem are zero - so it is really an "issue" about discussions with hairsplitting pedants than a practical one :-P.

If you squint closely, you'll see my issue is not hairsplitting but rather a practical one about trouble with MinGW headers not being super up-to-date (missing DirectX 12 APIs, etc.)

I'm a huge fan of MinGW-w64, though. I would bet most involved in the issue are. We all win by improving the status quo - I'm just a buffoon figuring out the best way to do that :)

DirectX 12 API is a pretty small case to throw all the project to trash.

Notably since DirectX headers are always a different case compared to the rest of the Windows SDK

I'm a massive fan of your work on VLC, but I feel that's a bit of a mischaracterization..

The author of the issue spoke about his troubles with MinGW in four bullet points at the top that are not related to DirectX at all, whether you agree or disagree with those the fact is most people (including Andrew Kelley) rebutted many of his arguments, and Andrew even reached out to MinGW devs on IRC to chat about the topic of contributing upstream. That seems a reasonable approach to me.

I chimed in on the issue because DirectX 12 was the problem _I_ faced, explained what I learned, complained I still don't have a super official way to get up-to-date DirectX headers that are compatible with MinGW, and ultimately said I gave up on working on the issue out of frustration.

Throughout the issue there are people suggesting throwing out all of MinGW would be reckless, heck even I concluded that would not be possible for multiple reasons in my write-up.

I think people are reading too much into the title and trying to make this out to be some sort of attack on MinGW, I really do not think that was anyone's intent - we're just exploring if we can improve the status quo..

Note that with the hairsplitting bit i wasn't referring to the missing MinGW headers but to complaints about MinGW linking against msvcrt.dll when that DLL has been around since Windows 98.