[jezek2]

I wish open source projects would support MingW or at least not actively blocking it's usage. It's a good compiler that provides an excellent compatibility without the need of any extra runtime DLLs.

I don't understand how open source projects can insist on requiring a proprietary compiler.

[delta_p_delta_x]

There are some pretty useful abstractions and libraries that MinGW doesn't work with. Biggest example is the WIL[1], which Windows kernel programmers use and is a massive improvement in ergonomics and safety when writing native Windows platform code.

[1]: https://github.com/microsoft/wil

[vitaminCPP]

I fail to see why this would not work with gcc if it works with clang. The runtime?

[delta_p_delta_x]

'MinGW' is not GCC; it's an ABI, and from the developer perspective it is also the headers and the libraries. You can have GCC MinGW, Clang MinGW, Rust MinGW, Zig MinGW, C# AOT MinGW.

To answer your question, the headers.

[sitzkrieg]

if you want to link msvc built libraries (that are external/you dont have source), mingw may not be an option. for an example you can get steamworks sdk to build with mingw but it will crash at runtime

[quikoa]

Agreed I also like to see more support for MingW especially from open source projects. Not even a passing mention in this blog post.

[forrestthewoods]

Eww no. MingW is evil and no project should ever use it.

Just use Clang + MSVC STL + WinSDK. Very simple.

[rdiddly]

From the capitalization I can tell you and the parent might not be aware it's "minimal GNU for Windows" which I would tend to pronounce "min g w" and capitalize as "MinGW." I used to say ming. Now it's my little friend. Say hello to my little friend, mang.

[forrestthewoods]

I typically refer to it as “piece of garbage poop I don’t let infect my system”.

[snvzz]

>MingW is evil

Care to elaborate?

[forrestthewoods]

I've been shipping Windows software for 20+ years. Not one project I have ever worked on was based on MinGW. It's a gross hack that is ABI incompatible with the predominate ecosystem.

In the year 2026 there is no reason to use MinGW. Just use Clang and target MSVC ABI. Cross-compiling Linux->Windows is very easy. Cross-compiling Windows->Linux is 1000x harder because Linux userspace is a clusterfuck of terrible design choices.

If a project "supports Windows" by only way of MinGW then it doesn't really support Windows. It's fundamentally incompatible with how almost all Windows software is developed. It's a huge red flag and a clear indicator that the project doesn't actually care about supporting Windows.

[troad]

>> It's a gross hack

*taps on the name of this site*

If I'm writing some cross-platform bit of software, my interest in supporting Windows is naturally in producing binaries that run on Windows.

Why on earth should I give a flying toss how "almost all Windows software is developed", or which kinds of ABIs are BillG-kissed and approved? Good god. Talk about fetishising process over outcome.

[forrestthewoods]

I just eyerolled so hard I gave myself a migraine.

If your focus is on outcome that I promise and assure you that using MinGW will make producing a positive outcome significantly harder and more frustrating.

With modern Clang there really isn’t a justifiable reason to use MinGW.

[jezek2]

I think the issues you're referring to are related to C++ ABI which is inherently incompatible between different compilers (and sometimes versions). This can be sometimes issue for plugins, though sane programs always use C wrappers.

I never had issues with C ABI, calling into other DLLs, creating DLLs, COM objects, or whatever. I fail to see what is fundamentally incompatible here.

[forrestthewoods]

Yes if you go pure C API and write libraries that conform to this and don’t pass owned memory around then sure that works.

MSVC is ABI stable since 2015. Many libraries that distribute pre-compiled binaries that rely on this stability. ~None of them include MinGW binaries in their matrix. (Debug/release X MT/MD).

Being a good citizen means meeting people where they are. Libraries and programs should expect to be integrated into other build systems and environments. I have literally never ever in my career worked in a Windows dev environment that used MinGW. The ~only reason to use MinGW is because you primarily use Linux and you want to half-ass do the bare minimum.

[jezek2]

Interestingly I've never used Visual Studio on Windows (only for a brief time for ARM based PDAs where I could experience the infamous MFC which was okay to me despite the hate).

I've used Borland C++ and Watcom C/C++ back in the day and MinGW after that. Also COM was invented for interoperation between languages/compilers.

Being a good citizen means to not use the inherently unstable C++ ABI directly. You can use C API or even COM for that. Relying on it is cute but it's accidental and it will break in the future. Microsoft can't guarantee that it will stay stable because C++ is always evolving, forcing to break the compatibility.

Open source projects shouldn't depend on proprietary compilers (they can support them, but not as the only option). It just undermines the purpose of it.

The reasons I use MinGW is because it produces better compatible binaries on Windows, allowing me to support all Windows versions from Windows 2000 to latest with a single binary (and sometimes 64bit if there is a need/advantage) and it doesn't require me to bundle dozens of DLLs (or worse, installing them system-wide) and artifically limit the compatibility for no reason.

Breaking the compatibility is hostile to the users who can't or want to always use the latest Windows.