Is anyone still compiling Windows with Static Runtime?

Over the past few weeks I’ve had a pretty sizable number of users complaining our plugins are not showing up in a Windows 10 environment in both Ableton & FL Studio.

We’ve not been able to recreate the issue locally, but we also didn’t compile the plugins with static runtime libraries included.

I was under the impression that all windows 10 machines had the runtime libraries included and dynamic linking was safe, but perhaps this isn’t the case?

Has anyone ever seen something similar? We’ve compiled in VS 2019 with I believe the 142 toolset (latest) – but no one in the team is a native windows dev so a bit at a loss for what else it could be.

Every single developer I know uses static linking. It’s the only safe way and it usually only adds around 200kb to your artifacts.


Nice – thanks for the quick reply! That would explain us being the only ones not showing up lol

FYI you can also look at this thread:

TL;DR: the announcment of switching to dynamic linkage was soon after obsolete (luckily) because Microsoft lifted some limitations that makes it safe to use the more convenient static linkage again.

1 Like

If you static link, you don’t get bug and exploit fixes, and you also load more code into the process.

It’s the “only safe way” only if you completely ignore those issues. :stuck_out_tongue: But it is easier, at least at first.

You can dynamically link and ensure the runtime libraries are present at install time. IIRC, this is covered in the JUCE docs. It’s entirely possible something else is happening. Have you gotten any event logs or other diagnostic information? Do you have any Windows 10 version information?



Thanks Pete & everyone,

So – last night I did a build with the lib statically added. To be honest, I’m not even sure what all of this means 100% – but after doing this, it did solve the issue for all of the users (at least which got back to me)

Which means that there are some windows 10 machines out there that somehow do not have the necessary libs installed locally for the dynamic link.

You can dynamically link and ensure the runtime libraries are present at install time. IIRC, this is covered in the JUCE docs.

Unfortunately I’ve not seen anything like this in the docs – I would love to do that but it seems like it would take a lot of custom Delphi programming in innosetup which is what we’re using for windows installers.

I think for now well be forced to turn the static linking on, as the silent failure just doesn’t result in any sort of meaningful steps for the user on how to resolve.

Basically, when you dynamically link a lib, your program expects to be able to find it (as a .dll file on Windows) on the system it’s running on. When you statically link, the lib is actually built into your final executable so there are no external dependencies.

The app packaging tutorial mentions the static vs. dynamic consideration, but doesn’t actually show an example of how you’d include the runtime libraries in your installer if you want to link dynamically.

Using InnoSetup, you can download the VC++ Redistributable installer and include it in your distribution package, and run it during your setup process. This StackOverflow answer shows some decent exampless. Ideally, you’d do something like the second answer suggests and add a bit of code to check if the redistributable already exists before unpacking and running the installer.

1 Like

This goes slightly off topic now, but since we have @Psychlist1972 Pete contributing, wouldn’t it be a possibility moving forward, that Windows ships the necessary runtimes?

That would save so much pain and makes it more attractive to dynamically link and make Windows better and more uptodate.


The MSVCRT revs faster than Windows, typically, so we don’t include it in a Windows release. In general, we don’t distribute any dev tool runtimes unless something in the OS relies upon it.

I know this is why many statically link, but once you’ve set this up once, you can reuse it as required. Most installer tools already have actions built in to handle the merge module approach.

Full guidance:


BTW, Linux has a similar setup with shared libraries vs static, so I would think that macOS does as well.


All our plugins as well as my personal open source plugin work uses the dynamic linked runtime. I found it to be much easier especially when integrating third party libraries that are built against the dynamic linked runtime. Installing the redistributable along with the plugin installer is also quite simple and I‘m not aware of any problems with that.

1 Like

Where does one grab the redistributable from? And what if it’s detected as existing already? Overwrite with your perhaps newer or older version?

In the link Pete posted above all that is covered.

TL;DR: You get the vcredist_foo.exe installer from the microsoft servers and this exe installer will check if it’s already exists and will not overwrite newer ones. You just need your installer script to run the vcredist_foo.exe that fits your plugin.

1 Like

Derp missed that thanks @daniel

I would advise against dynamically linking. From the last 20+ years of VST experience, I can tell you that you will get people manually moving the .dll files across computers, never having installed the runtime. Your plugin won’t even load and the error message is about some missing DLL that no non-power user will understand. Or they install some other piece of software, that installs some outdated or updated version of the same runtime, causing you problems now. Google “dll hell” and you will understand.

The argument that you’re missing out on bug-fixes or that there may be exploits in the current version you’re statically linking is extremely thin, unless you use a LOT of very Windows specific system calls, you won’t be affected by any of those “bugs” or “exploits”. I would argue that dynamically linking is a lot more dangerous, because code you have no control over might magically get changed without your knowledge or consent. What if Microsoft release a new version of the runtime that causes problems with your plugin, because they “corrected” some behavior and the new version is the de-facto correct one, then you will have to change your plugin to make it work again. You better hope it works with the old and the new version, because you have zero control over which versions people might have installed, sometimes through other software that installed its “best runtime”.

Pick the path of least resistance and simply statically link. Your users will thank you. Less hassle and problems during installation. The fewer external dependencies you have, the better.


We’ve been dynamically linking for several years now and haven’t had any reports of issues lately at all. We do include the runtime libs in our installer (using mergemodules instead of the runtime installer exe).

1 Like