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.