We have decided to dynamically link to the Windows runtime by default if you are building for Windows. If you do not override the default setting in the Projucer, then this means that you must ensure that the Windows runtime is installed on your customer’s computer for your plug-in/app to work. Unfortunately, this is necessary to workaround a limitation in a recent Windows update (see notes below).
When building your app/plug-in you need to choose if you want to include the windows runtime statically in your binary or if you link to them dynamically. Up until now, most plug-in developers would statically link their apps/plug-ins with the runtime in release builds to avoid dependency issues on the customer’s computer (DLL hell). This used to be the default for JUCE projects as well.
Unfortunately, in a recent Windows 10 update, Microsoft changed the maximum number of fiber local storage (FLS) slots a process can have. Effectively, this limits how many plug-ins with static runtime linkage can be loaded into a DAW. In the worst case, this limits the total number of plug-ins to a maximum of 64 plug-ins. There is no workaround for DAW vendors and the only solution is to push plug-in vendors to use the dynamic runtime.
Luckily, Microsoft has been busy fixing runtime dependency issues with the introduction of the universal runtime.
If you are only targeting Windows 10, then the C++ runtime is now part of the system core components and will always exist on the computers of your customers (just like kernel32.dll, for example). If you are targeting Windows versions between Vista and Windows 10, then you should build your plug-in with the latest updated version of VS2015 or later, which ensures that it’s linked to the universal runtime. Universal runtime is part of the system’s core libraries on Windows 10. On Windows versions Vista to 8.1, it will be available on your customer’s computers via Windows Update. Unfortunately, if your customer has just installed Windows 8.1 to Vista on a fresh computer, then there is a chance that the update mechanism for the universal runtime hasn’t triggered yet and your plug-in may still fail. Your installer should prompt the user to install all the Windows updates in this case or you can deploy the universal runtime as a redistributable with your installer. If you are targeting earlier versions of Windows then you should always include the runtime as a redistributable with your plug-in’s installer.
More information on the availability of the universal runtime on different OSes and the best way for you to distribute the runtime can be found in the “Distributing Software that uses the Universal CRT” section in this document.
Hat-tip to Steinberg for making us aware of this problem.
EDIT: Re-worded to avoid ambiguity.