ideas to improve windows header files and libc

[marler8997]

Here's what MinGW provides for Zig:

• C/C++ headers for the win32 APIs (means we can compile C/C++ code without depending on Visual Studio)
• An implementation of libc for Windows

(Let me know if I'm missing something here)

The problems I've been having with MinGW

• it seems to have alot of bugs (this may not be accurate, just my limited experience)
• it's difficult to contribute to (patches over email, non-responsive, can take months to integrate changes)
• MinGW's goals don't always align with Zig's, so sometimes it doesn't make sense for them to fix things that Zig needs
• IMO, it's not "compatible enough" with MSVC so most projects need to add explicit support for MinGW. MinGW doesn't care to be more compatible and is OK with projects needing to put in work to support it alongside MSVC.

Every software has bugs, but MinGW's main problem here is that it's difficult, time consuming and slow to fix them. I think if this wasn't the case, I would have no issue continuing to use MinGW and submitting patches.

So what can we do? A big chunk of work is going to be getting C/C++ headers for the win32 APIs. Because Microsoft has released the https://github.com/microsoft/win32metadata project, and we are already using it to generate Zig bindings, we can enhance that project to generate C/C++ headers as well. I anticipate the initial work to support this would be just a few weeks.

That leaves us with the 2nd chunk of work, an implementation of libc for Windows. This work is already planned (https://github.com/ziglang/zig/issues/2879). With this it may be feasible to drop MinGW with work that's already planned and leveraging existing tools.

Thoughts, concerns?

P.S. Long term goal here is to completely replace the need for Visual Studio using this proposal and https://github.com/ziglang/zig/issues/8973

[nektro]

windows linker is provided by llvm (and soon self hosted compiler) not mingw

[mirh]

FWIW mingw did some major headers update in the last year or so (possibly even surpassing the mach sdk)

[gan-lin]

Here are what I know:

For C:

1. UCRT is redistributable (without debugging symbols): https://learn.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-170 , which means it can be included freely in any project;
2. Part of UCRT is open sourced (under MIT license): https://www.nuget.org/packages/Microsoft.Windows.SDK.CRTSource

For C++:

1. Microsoft standard C++ library (MSSTL) is open sourced: https://github.com/microsoft/STL
2. Win32 API interface is published as a winmd file, and from it we can generate headers: https://github.com/microsoft/win32metadata (there are discussions above, but according to https://github.com/microsoft/win32metadata/issues/1488 , it seems to be MIT licensed.)

I compared the files from "open sourced UCRT part" and UCRT in Windows SDK:

• The headers are almost identical so it can be used interchange;
• Suppose that each obj file is compiled from a cpp file, then I compared source code files in open sourced UCRT with obj files in libucrt.lib: most files are there; math functions (\<math.h> and \<complex.h>, or, libm) and a few compiler-generated functions (CFG?) are missing.

So I think it is possible to use the open sourced UCRT with the redistributable to form a build environment. But I'm not familiar to the problems about ABI.

[gan-lin]

However, I found that vcruntime.h (#included by corecrt.h) may not be open sourced or redistributable. This has already been listed by zig libc. I've not considered before, and I wonder whether there is a solution.