Why not script automatic C-o injection?

Ultimately, the problem is the tool turning against the user. Maybe it is time to get a new tool.

RISC-V is rapidly growing the strongest ecosystem.

>MingW is evil

Care to elaborate?

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.

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.

Yup. Measurements are king.

And an objectively good setup is not expensive.

A cheap pair of Sennheiser HD600 for headphones will last effectively forever and sound great paired with a very competitively priced Topping DX3Pro+ for external soundcard/amplifier.

RISC-V is not a core, it is an ISA.

Beware chips with high performance microarchitectures compliant with RVA23 are coming later this year.

Same difference. You can't get high performance without more complex instructions like ARM or x86.

We'll have to agree to disagree.

Fortunately, this will be determined in practice in just months, not years from now.

That's self-inflicted.

If a person celebrated a political assassination, I wouldn't want anything to do with them either, and I surely would not employ them.

Charitable of you to assume good faith or truth from the accusers.

Nothing wrong with LibreSSL, really.

If it's good enough for openbsd, it's good enough for you as well.

Particularly, they put in a lot of work on making it a drop-in replacement for openssl, and in making the portable version work well in many platforms.

Only for distributions to fail to take the sorely needed step of actually making the switch.

Amber is where it's at.

Sounds like textbook criminal negligence.

A public prosecutor should take this on.

If interested in rejuvenation, I would suggest investigating LEVF's Robust Mouse Rejuvenation.

RMR1 done and shows promise, RMR2 started recently.