I was testing a recently built plugin (built with VS 2019 using dynamically-linked run-time libs) on a machine running Windows 8.1 (fully updated) and ran into the “missing VCRUNTIME140_1.dll” error. Installing the latest MSVC++ 2015-2022 redistributable fixed this, as expected.
Now, I was under the impression that:
Since some time when MS made some changes related to these run-time libs (around 2019?), these MSVC++ run-time libs are now part of the operating system (and get updated along with Windows Updates), so it is no longer necessary to redistribute them along with my plugin.
This is supposed to just work for Windows 10, and for Windows 8.1 the run-time libs should have got installed through Windows Update when updating to the latest version of Windows 8.1.
Is the above correct for Windows 10?
And why is it that on that (fully updated) Windows 8.1 machine it didn’t work (and the libs were missing)?
I think that only the C runtime (UCRT) works in the way you describe (i.e. it’s preinstalled on Windows 10 machines). For C++ programs, you still need to link against a vcruntime dll.
The C and C++ compiler-specific runtime support library, vcruntime , contains the code required to support program startup and features such as exception handling and intrinsics.
In Visual Studio versions before Visual Studio 2015, the C Runtime Library (CRT) was included as a redistributable DLL, in msvc version .dll. Starting in Visual Studio 2015, the functions in the CRT were refactored into the vcruntime and the UCRT. The UCRT is now a system component in Windows 10 and later, managed by Windows Update. It’s available on all Windows 10 and later operating systems.
It sounds like the vcruntime and UCRT are separate libraries, and only the UCRT is installed by default.
@reuk Ah, yes, I now vaguely remember something about a “split”. That explains it then. Thanks!
@reFX No reason other than smaller plugins, smaller installers, and having my plugin work with the latest security fixes for the run-time DLLs, but all of these are not that critical for a plugin. So, yeah, I had made the change (following JUCE) due to that limitation with loaded DLL FLS (?) slots (can’t remember exactly), but after MS increased that limit to 4000 IIRC, maybe it’s just way easier to use static linking again.
That security fix argument is bunk (IMO). Plugins usually only use a tiny portion of the runtime library and I’d rather have 100 kB longer files, and the knowledge of a stable API, than the support headache of telling people to download several MB long runtimes they might otherwise not need at all. Also if the runtime changes, but the plugin doesn’t know about that specific change, can you guarantee that your plugin works correctly?
We’ve used static linking since reFX exists (so over 20 years now) and never ever had a single problem that turned out to be caused by statically linking our plugins.
