dll vs exe plugins
Moderators: MattKingUSA, khz
- briandc
- Established Member
- Posts: 1442
- Joined: Sun Apr 29, 2012 3:17 pm
- Location: Italy
- Has thanked: 58 times
- Been thanked: 28 times
- Contact:
dll vs exe plugins
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
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
Have your PC your way: use linux!
My sound synthesis biome: http://www.linuxsynths.com
My sound synthesis biome: http://www.linuxsynths.com
Re: dll vs exe plugins
I think exe files are standalone apps, not plugins. You can run them with "wine <name>.exe"
-
- Established Member
- Posts: 92
- Joined: Sun Mar 29, 2009 10:45 pm
- Has thanked: 22 times
- Been thanked: 6 times
Re: dll vs exe plugins
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.
-
- Established Member
- Posts: 2326
- Joined: Sat Jun 21, 2014 8:37 pm
- Been thanked: 256 times
Re: dll vs exe plugins
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
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
- Established Member
- Posts: 1442
- Joined: Sun Apr 29, 2012 3:17 pm
- Location: Italy
- Has thanked: 58 times
- Been thanked: 28 times
- Contact:
Re: dll vs exe plugins
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?
@glowrak guy: what's an .msi file?
Have your PC your way: use linux!
My sound synthesis biome: http://www.linuxsynths.com
My sound synthesis biome: http://www.linuxsynths.com
Re: dll vs exe plugins
Microsoft Software Installer.briandc wrote:what's an .msi file?
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).
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
-
- Established Member
- Posts: 2326
- Joined: Sat Jun 21, 2014 8:37 pm
- Been thanked: 256 times
Re: dll vs exe plugins
The native linux u-he plugins have a .so extension, so the ability to launch them as a standalone, would dependbriandc wrote: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.
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)
-
- Established Member
- Posts: 2326
- Joined: Sat Jun 21, 2014 8:37 pm
- Been thanked: 256 times
-
- Established Member
- Posts: 2326
- Joined: Sat Jun 21, 2014 8:37 pm
- Been thanked: 256 times
Re: dll vs exe plugins
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!
could be modified to work with linux vsts? That would be low cpu fun!
- briandc
- Established Member
- Posts: 1442
- Joined: Sun Apr 29, 2012 3:17 pm
- Location: Italy
- Has thanked: 58 times
- Been thanked: 28 times
- Contact:
Re: dll vs exe plugins
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!glowrak guy wrote: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!
@Jeff, thanks for the details about the .msi extension!
brian
Have your PC your way: use linux!
My sound synthesis biome: http://www.linuxsynths.com
My sound synthesis biome: http://www.linuxsynths.com
Re: dll vs exe plugins
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.
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.
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
- briandc
- Established Member
- Posts: 1442
- Joined: Sun Apr 29, 2012 3:17 pm
- Location: Italy
- Has thanked: 58 times
- Been thanked: 28 times
- Contact:
Re: dll vs exe plugins
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.j_e_f_f_g wrote: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.
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
Have your PC your way: use linux!
My sound synthesis biome: http://www.linuxsynths.com
My sound synthesis biome: http://www.linuxsynths.com