Death of the installer-less plug-in?

[DuX]

Is there really no alternative to using MS Visual C++?

[Xenakios]

Is there really no alternative to using MS Visual C++?

Possibly MinGW but you'd have hell of a time convincing all plugin developers to switch to that.

[BlitBit]

Is there really no alternative to using MS Visual C++?

Possibly MinGW but you'd have hell of a time convincing all plugin developers to switch to that.

Does anybody know whether projects compiled with MinGW are affected? Or are only projects that link against Visual C++'s runtime affected?

I have a project that's built with MinGW and DependencyWalker only shows the following four dependencies:

• GDI32.DLL
• KERNEL32.DLL
• MSVCRT.DLL
• USER32.DLL

These DLLs should be available on every Windows system, shouldn't they?

[Xenakios]

I have a project that's built with MinGW and DependencyWalker only shows the following four dependencies:

• GDI32.DLL
• KERNEL32.DLL
• MSVCRT.DLL
• USER32.DLL

These DLLs should be available on every Windows system, shouldn't they?

Yeah, I just checked that myself too. However the dll dependencies don't tell if the binary itself has statically linked parts from some Microsoft libraries. (I'd imagine they don't but at the moment I am not 100% sure about that.)

[BlitBit]

I have a project that's built with MinGW and DependencyWalker only shows the following four dependencies:

• GDI32.DLL
• KERNEL32.DLL
• MSVCRT.DLL
• USER32.DLL

These DLLs should be available on every Windows system, shouldn't they?

Yeah, I just checked that myself too. However the dll dependencies don't tell if the binary itself has statically linked parts from some Microsoft libraries. (I'd imagine they don't but at the moment I am not 100% sure about that.)

Any symbols that we can search for with objdump that would reveal whether Microsoft libraries are linked?

The following command can be used in a shell to dump the symbols (The "t" parameter instructs to dump the symbols, "C" activates name demangling and "w" sets the output width to more than 80 characters):

Code: Select all

objdump -tCw Plugin.DLL

Of course it helps to redirect everything to a file:

Code: Select all

objdump -tCw Plugin.DLL > Symbols.txt

[camsr]

Using mingw, compile your project with the -v option (verbose output) and check for any commands starting with -l (like -lgdi32). Whether or not the linked libraries actually exist in the dll image can be checked in the linker's map file. To output the map file, use this option, -Wl,-map,mapfilename

[camsr]

Is there really no alternative to using MS Visual C++?

There's a thousand alternatives that will compile a DLL and a VST.

[layzer]

just because installer-less plugins are no longer made doesnt
mean installer-less plugin death, ill keep right on using the existing ones

i love my PORTABLE daw

[DuX]

Is there really no alternative to using MS Visual C++?

There's a thousand alternatives that will compile a DLL and a VST.

If I remember correctly, Intel C+ compiler is the best and MinGW performs just as well as MS VC, so why don't more people use it? What's this obsession with Microsoft? Is it like a faith thing or something? These guys want to be the only "toy seller" on Earth, obviously. I can't understand why monopolists like that get so much support. That's no good. Power corrupts and they will use it against us. Like this thing with stopping the VC++ support for older OSes. This is really mean.

[camsr]

It's just easier to make a DLL with MSVC. I had to do a lot of reading to make a decent DLL with mingw.

[aciddose]

Not in response to any particular post:

Not to mention, the compiler has absolutely nothing to do with this issue.

MinGW-GCC can't legally statically link any version of MSCRT because they don't have the rights to do so, and neither do you unless you are explicitly granted that right. (For example in the license for VisualStudio.)

Visual Studio is an IDE. If you want to question why people use a particular IDE I suggest you dig a hole in the ground and place your head inside. (It smells better, and you clearly wouldn't know the difference anyway.)

Microsoft's compiler and linker come with Visual Studio: Why do people use it? It works.

Intel's compiler places "if (CPUID != "Genuine Intel") { shitty_code(); } else { fast_code(); }" in all your code. This is why people prefer not to use this compiler, although it does produce very good code for Intel CPUs this code has ridiculous dependencies which render it completely non-portable to any other platform. Intel has every right to write a compiler/linker which specifically targets their CPUs. Programmers have every right not to use it.

I use GCC and used MinGW in the past (I wouldn't use it on Windows, I'd just install cross-compilation features for GCC on Linux.)

GCC doesn't come with an IDE and GDB is an awful, difficult to use debugger on Windows without any of the ease-of-use and Windows-specific features Microsoft's debugger has.

I even hate using GDB on Linux. It works fine (usually), but only with 10x the effort.

[Ichad.c]

going back to the original thread topic: it looks like that each plugin uses at least one or two FLS slots PER THREAD. If that's correct, this means that plugins that uses multi-threading (to load samples and so on), will use more FLS slots. I have to deeply test this, but I suspect that 64 is not the amount of different plugins, but the amount of DLL instances.

Unfortunately, this will leave us small developers with very few choices:
a) including the latest VC redist with the plugin installer (increasing the installer's size)
b) not supporting old versions of Windows any longer (pre Vista SP2)

As for Windows versions from Vista SP2 to 8.1, users need to update their OS in order to support Microsoft Universal C Runtime: https://support.microsoft.com/en-us/hel ... in-windows

I'm already aware that there will be a lot of angry users emailing why they have to install more software in order to get our plugins to work and others asking why XP will be no longer supported.

Yip it is a "damned if you do, damned if you don't" type situation. If we don't fix it there is limitations or worst case - some old projects might not open in your DAW(if some plugin-ins were updated and suddenly use more slots like MSV 2013 -> 2015).
If we do fix it, it's the usual -> why is there suddenly an installer?
Aciddose does raise some good issues about installers though, some are really implemented poorly.

Ironically DAWs are bearing most of the criticism for now, as is UAD plugs - as this issue basically nullifies their use.

[Ichad.c]

I use GCC and used MinGW in the past (I wouldn't use it on Windows, I'd just install cross-compilation features for GCC on Linux.)

GCC doesn't come with an IDE and GDB is an awful, difficult to use debugger on Windows without any of the ease-of-use and Windows-specific features Microsoft's debugger has.

I even hate using GDB on Linux. It works fine (usually), but only with 10x the effort.

I use MinGW-w64 on windows, because I'm a hobbyist programmer - it was my personal "screw you MS" moment when I was learning programming. But you are right GDB is a real pain to use.

[Guillaume Piolat]

We'll continue to offer installer-less plug-ins since it allows you to easily back-up your VST plugin folder, or put that folder on DropBox and enjoy zero-installation setup.

[Guillaume Piolat]

If I remember correctly, Intel C+ compiler is the best and MinGW performs just as well as MS VC, so why don't more people use it?

Intel Compiler is usually the best for optimizings loop, it's almost impossible to beat it with assembly. Even something as simple as memcpy will usually get faster with ICC. However it seems GCC and LLVM have been catching up along the years.
You can see their output for a tricky loop at: https://godbolt.org/g/QL3UtR