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


:sweat_smile: ah, i forgot :smirk:


What do i have to do to build against the universal windows runtime.

  • Visual Studio 2015 SP3
  • Change the runtime to dynamic dll
  • edit: Target Windows 10?

Is that all or do i need to set something else like the target platform or toolset?

edit: i’m not able to show into the compiler and linker settings anymore, since the multi target change. This makes things even harder to verify.


Which Windows 10 Update was it? When it was distributed? Does anybody know?


Is it “set in stone” that this is how it’s going to be - are there any discussions with Microsoft on why? I imagine DAW developers have talked to MS about the issues that this change causes.
Maybe (although unlikely so) they didn’t realize what this will cause to plugin-heavy applications?
If it turns out this is a mistake on their part, they are quite quick on fixing issues. But I imagine the damage is already done if they have such an update in the pipeline…

What about legacy binaries of plugins statically linked with the runtime - the DAW would not be able to load more than 64 plugins of THAT type, correct? Even if they have a way to do this, I guess, DAW’s aren’t going to deny loading of plugins with embedded runtime, right?


Yes. I know, that Steinberg had a few discussions with Microsoft and weren’t able to convince them.

One solution is for the major DAW vendors to all include the universal runtime in their installers. I’m preparing a mail-out to the major DAW developers, to ask them to include this. This way, plug-ins without installers would still work (granted it would mean that the customer has a newish version of the DAW installed).

It depends. 64 is the worst case. Since VS2017 the static runtime takes up two FLS slots. So if the user loads 64 statically linked different plug-ins created with VS2017 - then loading will fail. If you open the same plug-in twice then this only counts once as it only needs to load the dll once.


I suppose that this is going to help Microsoft better support ARM. The use of DLLs will allow the transpiled/emulated executables to work with native libraries which don’t pay any performance penalty.


So I changed the Runtime compile option in my project to /MDd for my Debug build and I received a compile error (C1128) while building the JUCE code.

I have the JUCE code as a separate project in my plug-in… so I added the compile flag /bigobj to the JUCE project and it got rid of the error.

Just a heads up.



Fatal error C1128: Debug build requires /bigobj

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

Just saw this Announcing Windows 10 Insider Preview Build 18312 - FLS Slot Limit Increase

As PCs get more powerful, musicians have created increasingly complex projects with more tracks, more instruments, and deeper effects chains. As a result, some of those musicians were running up against a FLS (Fiber Local Storage) slot allocation ceiling that prevented them from loading into their DAWs (Digital Audio Workstations) as many unique plugins as they’d like. This build greatly raises that per-process FLS slot allocation ceiling, allowing loading potentially thousands of unique plugins. Beyond musicians, this change will positively impact any application that dynamically loads hundreds or thousands of unique DLLs that have statically-linked Visual C++ runtimes, or otherwise allocate FLS slots.

So it seems Microsoft is listening to musicians after all :slight_smile:


Wow. Didn’t think I’d ever see this


let’s just hope they won’t break other things :wink:


I know this is an ancient thread, but FWIW, the limit of 128 has been around since around Vista. We haven’t changed that code in a very long time. It exists as 128 on Windows 7, 8, 8.1, 10, Vista, etc. We’ve also had a number of reports of people hitting this limit on Windows 7, and then running the FLS Checker plugin and seeing that they have the same limit as on Windows 10.

Dynamic linking is good to reduce the amount of duplicate code in the process (with 50 DLLs loaded and static linked to the runtime, you get 50 copies of that common code in memory), and to allow servicing of the runtime for security, bugs, etc. I get the convenience of static linking, though. So in Windows 10 going forward, if testing goes well, the limit will be a bit over 4000, rather than 128.

Official announcement:



(didn’t see the latest post here as it was below)

We’ll try not to break other things. Let us know if we do. :slight_smile: