IMPORTANT BREAKING CHANGE: JUCE will now use dynamic linking for the Windows runtime by default

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).

32

More details:
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.

4 Likes

:man_facepalming: :see_no_evil:

Thanks a ton, Microsoft. :face_with_symbols_over_mouth: :tired_face:

1 Like

Reaper did a change regarding that a while back :

1 Like

That’s wrong on so many levels… Thanks for the information, I suppose I’ll have to update all my plugins at some point because of this.

1 Like

grrr, thanks for the heads up

Wow, I don’t see why they have done this, is it solving any other problem at least ?

I see this solving a problem only for Microsoft themselves : by strongly pushing the use of the dynamic runtime, they can get security fixes onto the end user machines via Windows Update. Microsoft practically never adds new features or enhances existing ones in those updates. It’s all about keeping the system patched for security related problems.

For developers of things like audio plugins and end users of those, this is just going to cause additional work and hassle. For example many plugin developers haven’t looked into making proper installers for their plugins. Now they may be forced to doing that so that they can get the needed Microsoft runtime shared libraries onto the end user’s machines…And of course then many picky plugin end users are then going to complain “why does this simple plugin need this big installer?”, “what is it installing on my system?” etc…

1 Like

Well, on newer systems, it seems that we don’t have to install anything… But for old systems :confused: But this is so annoying…
I still wonder how this universal runtime will work int he long run. I’m happy there is one, as Python modules devs won’t have to use the same compiler as Python itself, and for apps like the one I’m work on, it’s also a good thing not to worry about which runtime is destroying what data, but still…

Exactly, on Windows 10 your Plug-In still won’t need an installer.

And for Windows versions 8.1 - Vista, your plug-in will work without an installer if the customer has applied all the updates to their OS.

To be honest, I see the problem with the patchy way Windows update will seemingly randomly update different components of the OS at different unpredictable times.

Take macOS as a comparison: It’s no problem for a plug-in developer to tell their customers that their plug-in needs at least, say 10.8.6 - i.e. it won’t run on a fresh install of 10.8. Updates and update version numbers are clearly communicated on macOS and it’s easy to manually force macOS to update. This can’t be said for Windows where certain updates only seem to appear a few days after you install a fresh copy of Windows.

I’m not exactly sure, apparently it has some performance improvements especially for mobile. That’s what I heard at ADC.

I think the notable word there is “all”. So are we to tell DAW users they have to let Windows Update install absolutely every update on Windows 7/8/8.1? I am personally quite conservative with what and when I let Windows Update install anything, and I would expect a notable amount of other people dealing with audio are the same. Those updates are likely not going to improve their audio workflows in any way but on the other hand do have a chance they may break something.

I suppose it also simplifies memory management in general. Static runtime means that whoever allocates memory also have to deallocate it. With shared runtime, no more problem like that.
So static was better for making sure people didn’t mess up, but it was just several memory heaps each time (I suppose it has to be several heaps).

It’s the universal runtime, I hope more and more DAWs are migrating to at least VS2015, so these computers would have the runtime, whatever version it is (even the earliest version should be fine).

Right well…Maybe it’s going to be OK for most users then. However there are oddities like Cockos Reaper that are built with extremely old Visual Studio versions.

I am still skeptical if the “Universal” runtime really is that universal. Has anybody here investigated that more deeply?

What about Windows 7? Does Microsoft distribute the Universal runtime with regular updates?

1 Like

https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows

Seems to be a regular update on windows 7, or?

7 is posterior to Vista, so according to what Fabian said, should be good?

And according to your link, it is updated automatically.
Otherwise, you can make people install the update through the link you gave (thanks for it BTW!)