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?
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!)
ah, i forgot
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.
Continuing the discussion from IMPORTANT BREAKING CHANGE: JUCE will now use dynamic linking for the Windows runtime by default:
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
Wow. Didn’t think I’d ever see this
let’s just hope they won’t break other things
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.
(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.