[OatmealDome]

Dolphin is a GPLv2+ application, and the runtime is under a proprietary license. We currently rely on the "system libraries" exception in the GPL to allow linking with the runtime in the first place. If we ship the runtime with Dolphin, it might not be considered a "system library" anymore.

There's some past discussion in this PR, where we made a change to automatically install the runtime DLLs but ended up reverting it: https://github.com/dolphin-emu/dolphin/pull/11068

(this is based off my own recollection of what others have told me, it might be out of date or wrong)

[MayeulC]

Honestly, given the feedback on the Microsoft site, that makes sense: the redistributable is backwards-compatible, not forward-compatible. Same as with glibc.

IMO, the correct option here is to compile against an older version of the build chain. This is the solution offered by Microsoft, and something you would do on Linux for glibc compatibility as well.

The other option would be to compile without MSVC, using mingw, wine headers, etc.

[gary_0]

> compile without MSVC, using mingw

I believe there are a few open source projects (such as Inkscape[0]) that provide Windows builds this way rather than having to deal with Microsoft's toolchain and runtime. But given its heavy reliance on DirectX APIs and other system libraries, I'm not sure how feasible that route would be for Dolphin.

I do wonder if there would be a performance benefit to compiling with GCC/clang on Windows, as I've seen fairly recent builds of MSVC emit some pretty lousy code in certain cases, and it lacks many of the options that GCC/clang provide, such as an exact equivalent of -fno-math-errno and the like.

[0] https://wiki.inkscape.org/wiki/Compiling_Inkscape_on_Windows