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.
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.
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.
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.
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.
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.
>> 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.
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.
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.
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.
1 reply →