dll vs exe plugins

[briandc]

Hi all,
up till now I've used apps like FeSTige and Reaper with wine to open .dll-type plug-ins.
But if I want to use a .exe-type plug-in, what should I do? Do I have to configure it in Wine somehow?


Thanks in advance!
brian

[varpa]

I think exe files are standalone apps, not plugins. You can run them with "wine <name>.exe"

[juki]

As far as i know .exe files are just softwares installers for Windows, or files that will launch a software. I already installed WinVSTs using their .exe installers doing like told above (wine <name>.exe). I never had problems to use them with Reaper after. If configured properly to open .exe files with WINE, you can also double click on them.

[glowrak guy]

the .dll plugin files can ususally be run with fst or fsthost command, using wine. This will not
supply any host features, so using instruments with built-in preset load/save in the gui
may be preferred.

the .exe files are executables, not plugins, as noted above.

There are a few apps, that come in both standalone, and plugin, with slightly different
features, where you might want to run both the exe and the fst'd dll to save loading a host app.
Amplitube 3 is one of these.

msiexec -i name.msi will install a .msi file.
Cheers

[briandc]

Thanks guys for your help. I'm especially curious to test out some recent .exe VSTi's like the ones from u-he. Arturia has some interesting synths that I'd like to test too, at least the demos. Just to see.

@glowrak guy: what's an .msi file?

[j_e_f_f_g]

what's an .msi file?

Microsoft Software Installer.

Microsoft created this tool for Windows developers. The tool helps developers make an installer for their software. The installer can have lots of useful features such as creating a restore point, version checking, creating start menu entries and/or desktop shortcuts, automatically creating an uninstall utility, installing different versions of files based on the OS version (so for example one installer can install a 32-bit version of its software if run on XP, but a 64-bit version if run on Win7 64-bit) etc.

So, lots of Windows developers use this tool to create their installer. When the tool creates an installer, it names the installer with an .msi (instead of .exe) extension. I won't bother getting into why that's so. Let's just take a layman's approach and say that an .msi file is a Windows executable (ie, program) that specifically installs some Window software. (But technically it isn't).

[glowrak guy]

Thanks guys for your help. I'm especially curious to test out some recent .exe VSTi's like the ones from u-he. Arturia has some interesting synths that I'd like to test too, at least the demos. Just to see.

The native linux u-he plugins have a .so extension, so the ability to launch them as a standalone, would depend
on the shared object's content and permissions, and the developers desired usage, and using an appropriate command.
I don't know yet if these are designed to be able to run standalone outside a vsthost. Maybe one of the devs can explain
the possibilities.
(and thanks Jeff, for some details about msi)

[glowrak guy]

Abique confirmed these u-he plugins require a vst host.
Cheers

[glowrak guy]

jack-dssi-host loads dssi files with .so extensions, I wonder if this app
could be modified to work with linux vsts? That would be low cpu fun!

[briandc]

jack-dssi-host loads dssi files with .so extensions, I wonder if this app
could be modified to work with linux vsts? That would be low cpu fun!

Agreed. I don't know how many times I saw an .so file and thought, "oh, I can open this with jack-dssi-host!" -Obviously it wasn't always the case though!

@Jeff, thanks for the details about the .msi extension!


brian

[j_e_f_f_g]

A .so (shared object) file is essentially the linux equivalent of a windows .dll (dynamic link library) file. They both have the same purpose. They aren't executables, so they can't run by themselves. Instead, the code in them is run by an executable. (For the following discussion, I'll refer to a .so file as a "dll").

It's true that the code for a DSSI synth is put into a dll. But so too is the code for an LV2 effect plugin. And so are lots of gnome and kde graphics code. And code that connects you to the internet. Lots of different types of code are put into a dll.

But in order to be a DSSI synth, a dll must have particular code in it which identifies it as a DSSI synth. An LV2 dll will not contain this code. Neither will a gnome nor kde graphics dll, nor the dll that connects you to the internet. Only a DSSI dll has this "dssi identity code" in it. (The code is put there by the developer).

So too, a LV2 dll has particular code in it which identifies it as a LV2 plugin. This "LV2 identity code" is different than the "dssi identity code". And only a LV2 dll has this "LV2 identity code" in it.

So assume you take a gnome graphics dll, and tell a DSSI host to load it as a DSSI synth. The host is going to look for that "dssi identity code", but not find it. Then, the host is going to tell you it's not a DSSI synth (or tell you it can't load it, or say it's a corrupt file... whatever... it's going to tell you there's an error).

In conclusion: A DSSI synth is put into a .so file. But that doesn't mean every .so file is a DSSI synth.

[briandc]

A .so (shared object) file is essentially the linux equivalent of a windows .dll (dynamic link library) file. They both have the same purpose. They aren't executables, so they can't run by themselves. Instead, the code in them is run by an executable. (For the following discussion, I'll refer to a .so file as a "dll").

It's true that the code for a DSSI synth is put into a dll. But so too is the code for an LV2 effect plugin. And so are lots of gnome and kde graphics code. And code that connects you to the internet. Lots of different types of code are put into a dll.

But in order to be a DSSI synth, a dll must have particular code in it which identifies it as a DSSI synth. An LV2 dll will not contain this code. Neither will a gnome nor kde graphics dll, nor the dll that connects you to the internet. Only a DSSI dll has this "dssi identity code" in it. (The code is put there by the developer).

So too, a LV2 dll has particular code in it which identifies it as a LV2 plugin. This "LV2 identity code" is different than the "dssi identity code". And only a LV2 dll has this "LV2 identity code" in it.

So assume you take a gnome graphics dll, and tell a DSSI host to load it as a DSSI synth. The host is going to look for that "dssi identity code", but not find it. Then, the host is going to tell you it's not a DSSI synth (or tell you it can't load it, or say it's a corrupt file... whatever... it's going to tell you there's an error).

In conclusion: A DSSI synth is put into a .so file. But that doesn't mean every .so file is a DSSI synth.

Makes sense. In fact, it's kind of what I imagined was happening, even though I wouldn't recognize the code of any of the formats if they fell on me. -Part of not being a programmer I guess. But it makes sense.

So it makes me wonder: maybe someday we'll have synths that have *all* the codes in them, so that they can be opened/read by any type of executable..? I imagine that at this point we don't need any other types of file format, seeing we already have .dll, .so, LV2, etc... Of course, if any of these codes are "copyrighted" in some way, then it would be a hinderance...


brian