Dynamic vs static linking on Windows and Inno Setup

[Ivan_C]

Hello guys !

Since a very recent Windows 10 update (see there for more information related with JUCE : https://forum.juce.com/t/important-brea ... ault/25276), it is now best practice to link dynamically the Windows runtime library to our compiled plug-ins. If we don't do so, users might run into the "no more than 64 different plug-ins linked statically loaded in the DAW" issue on Windows 10.

In practice, is not only a matter of linking statically or dynamically the runtime librairies. Indeed, in Windows 10, when the specific update has been applied, the universal runtime library is supposed to be available. But in other cases, either simply because we are on Windows 7 to 8.1 or because the computer is not up to date, the runtime might not be available.

So, how do you handle this issue ? Do you care about the static linking issue or not anyway ?

If you care, that means that you have to provide the users a way to download what he needs to run the plug-in anyway. I see different options there :

• Ignoring the issue and compiling everything in static
• Telling the user that he has to update Windows or to get the last version of Visual Studio Redistribuable
• Including in the installer a script to run the Visual Studio Redistribuable which is in the installer binary
• Including in the installer a script to run the Visual Studio Redistribuable which needs to be downloaded on the fly (maybe the most elegant solution)
• Providing two versions of the installer, one with plug-ins statically linked recommended for Windows 8.1 and less, one with dynamic linking for Windows 10 (kill me already for compiling, copying and setting everything there)
• Not telling anything to user, not providing any installer, but still compiling everything dynamically

So what's best pratice among the real world commercial plug-ins developers ? And if you go for option Redistribuable in the installer, would it be possible to share your experience ? I wonder if it is even possible to download automatically the VS Redistribuable with Inno Setup.

Thanks in advance !

[Miles1981]

I'm doing the last one, just adding a comment in the download page.
Still, I think you could just ship with the content of the redist folder, perhaps adding ucrtbase.dll as well, and install them locally?

[stratum]

There is a similar problem in linux concerning thread local storage. In some linux distributions it's pretty small and limits the number of shared libraries a process can load. It's pretty annoying. Congrats to microsoft for introducing a similar problem to windows.

[syntonica]

Perhaps a small note with link to MS to download would be appropriate, but it's extra effort I shouldn't have to make. The redistributable should be part of the OS, period. We shouldn't have to worry about which OS the user has, per se, and do they need it or not and have they updated. I'm statically linked (for now), if only because I know that MS won't be able to pull the rug out from underneath me and break my plugin and I have other more pressing issues.

[Miles1981]

if only because I know that MS won't be able to pull the rug out from underneath me and break my plugin and I have other more pressing issues.

Well, apparently, they did...

[syntonica]

I can assure you--any bugs are MINE and mine alone!

[lorcan]

Still using static linking here.
I guess I should be a good citizen and change that in the near future.
Detecting wether an runtime update is needed at install and redirecting to Windows Update seems like a good strategy to me, although I'm afraid some impatient users will just skip this part only to find out later that the plug-in doesn't start / crashes.

By the way, according to this, real world numbers are more like 90 slots min
https://www.steinberg.net/forums/viewtopic.php?t=134715

[Ivan_C]

Thanks to everyone who contributed there !

lorcan > nice find, and the FLS plug-in is quite handy ! However, if I'm not wrong, the numbers reported there have been obtained on computers which don't have Windows 10 + the last updates. The whole point of my topic here is that one of the last Windows 10 updates has changed the number of FL slots available. So, with such a computer, the FLS plug-in might report a number lower than 64 ! I just checked my Windows 8.1 computer and that number is around 91, so we might expect that real world values on Windows 10 + last updates is around 40-50 !

[lorcan]

@Ivan_C On my Win10 x64 rig, all latest updates applied, I get 120 slots with Reaper x64, 93 with Cubase 9.5 x64.
But apparently, according to Yvan Grabit plugins built with MSVC 2015+ use 2 slots, so that would indeed translate to less than 60/45 different types of plug-ins .
Haven't bothered to test the actual limit myself - I've probably never used more than 15 plugs in a session myself anyway.

[Miles1981]

I've probably never used more than 15 plugs in a session myself anyway.

But is that the number of plugins you have? Because all the plugins are loaded at some point, so if they deplete the FLS, the others after may fail to load.

[lorcan]

But is that the number of plugins you have? Because all the plugins are loaded at some point, so if they deplete the FLS, the others after may fail to load.

No, I have gazillions of them. But those unused plug-ins should only get loaded once at scan time, right ?

[Miles1981]

Yes, but that what it takes to deplete the FLS. As Ivan said, it's only n fibers per plugin, nor per plugin instance.

[Ichad.c]

lorcan > nice find, and the FLS plug-in is quite handy ! However, if I'm not wrong, the numbers reported there have been obtained on computers which don't have Windows 10 + the last updates. The whole point of my topic here is that one of the last Windows 10 updates has changed the number of FL slots available.

The "problem" seems to be much older than Win10:

https://hydrogenaud.io/index.php/topic,110142.0.html

I actually tried to do a little end-user thread over at the effects section, but it derailed into a Win vs Linux debate, lol.

viewtopic.php?f=6&t=499252&hilit=death

My uneducated guess would be that this "problem" is only now becoming a real headache because of the recent Intel vs AMD competition, and people only now finding a reason to upgrade their old Sandy's or Ivy's. Look at the Win7 vs Win10 usage charts for the past year, it seem that a general update cycle is in swing. AMD also made their HEDT cpus pretty affordable, which is quite ironic if you have a Threadripper but can't utilize it to it's full extent because of static linking.

[lorcan]

Yes, but that what it takes to deplete the FLS. As Ivan said, it's only n fibers per plugin, nor per plugin instance.

I know it's per plug-in type, not instance.
But I don't understand why a plug-in type would deplete the FLS if it's not instantiated.
AFAIK, most hosts scan a newly installed plug-in once when it's first seen, and then use cached data on subsequent launches.

[Miles1981]

Yes, but at some point, it will load all the plugins to scan them. There is a risk then (if it is "dumb" to scan all of them and only then unload them) to flag working plugins as deficient when it's actually FLS depletion, even if it's only temporary.