Loading External .dll into AviSynth (LoadDll Plugin Inside)

[3ngel]

Hi,
i don't know if this function is already present and i'm not aware of it.
There is a way to load a /system32 .dll directly into .avs without having to put them in the above directory?
Some plugins need external dll to be present in /system32.
There is a way to load them like simple plugins, so they can be stored in other directories other than /system32?
Thanks

UPDATE:
Thank to tsp there is now a plugin "LoadDll" you can download here

[Fizick]

you can put DLL (not plugin) to any folder, if you add this folder to Path in Windows setting.

[3ngel]

I would like a solution Windows independent like

LoadSystemDll("Path/Test.dll")
LoadPlugin("PluginThatNeedSystem32dll")

EDIT: In this way you can do simple Autoloading packages with those plugin who requires many external .dlls installed.

[Fizick]

system DLL is used (called) not by Avisynth but by specific plugin directly.

[3ngel]

But avisynth could do a wrapping method so when the plugin calls the .dll the dll is already in memory (loaded by avisynth with the previous LoadSystemDll)

[Fizick]

probably in some other world it could be done so way,
but in our case in existed avisynth and plugins it is implemented differently. (they all must be edited and recompiled).

can you live without it?

[3ngel]

Eheh, ok i can live without it (*sigh*)

[foxyshadis]

Not implicitly! If you take them off, all the sudden half your tools won't start. (THANKS A LOT LEADTOOLS. Stupid broken installers.)

[setarip_old]

@3ngel

Assuming you have placed the .DLL in your "AVISYNTH" folder, try typing the following line from the "Run" box (available by clicking on the Windows "Start" radiobutton:

c:\windows\system\regsvr32 C:\AVISYNTH\system32.dll (Note the SPACE after "regsvr32")

[foxyshadis]

That'll only work on win9x (on nt it's in system32), but since it's on the path using just "regsvr32" works. But here, he's trying to use a standard dll, not a COM server, so loadlibrary won't pick it up even if it does register.

It's possible to read the registry to find the avisynth plugin folder, but there's no requirement for it to be there, so... best to use Ian's solution.

[3ngel]

@IanB
but SetWorkingDir() is a avisynth command? (in the case i'll try)

Next i would like to do a simple observation. I don't know in what lang avisynth is written, but in C++ there is a simple LoadLib() that load a .dll in memory.
I don't think is so complicated to wrap the function in a object (assuming is C++) that load a .dll in memory with a "Global Scope" in order to be visible by the plugin called next.
At the end of the script there would be (obviously) another function to unload the .dll from memory UnloadSystemDll()
Is so complicated?

EDIT: In case the plugins are mapped as "out of process" threads you could implement a wide-system hooking technique as explained here.

[3ngel]

Either install the support .DLL's in the same directory as the Plugin

The point is that some badly written plugins, dumbly look for .dlls only in system32 directory, and not in current dir.
In the late case there would be no problem at all

I don't see that it a job for Avisynth to preload arbitary .DLL's.

I disagree on this point, 'cause being Avisynth the "server environment" it has do make available all the instruments to make "client plugins" works in an optimal (including a portable) way. And this includes the possibility to make available to the plugins, external (or even why not modified or optimized) system dlls.

[3ngel]

@IanB
Mine was not a critic, obviously, i was just politely discussing
I didn't want to put the "problem" on you, i was just showing a situation that can happen.
From a user point of view, i am not able to fix the dumb plugin so i expect a little help from the server.
The problem is exactly the opposite: the needed library are not static linked.
Honestly i don't see all this risk.
When a plugin requires external.dll and it's badly written, and it doesnt' find in memory, nor system32 dir, the only thing Avysinth would do is only Preload the needed library (that i specify) in memory, so instead of looking for the disklibrary it finds already in memory. It doesn't involve knowing the name of the functions.
In the specific situation, one of is fft3dfilter that requires fftw3.dll to be put forcefully in system32 (it doesn't work in current dir).

[foxyshadis]

Ah, but that's because avisynth plugin folder isn't the current working directory, it's the host's. If you put it in virtualdub's folder, and load the script in vdub, it'll load it just fine. (Unless you modified a shortcut to vdub to point to another folder as the cwd, which is one way around all this. But then I think vdub itself wouldn't be too happy.)

[Fizick]

i get this message private from 3ngel, but it is not private.

... i thougt that fftw3.dll was called by your plugin fft3dfilter.dll and so i wasn't able to explain myself why fftw3.dll was not autodownloaded being in the same dir as fft3dfilter.dll. According to Loadlibrary() specification (and my knowledge) among many places to search there is with no doubt current dir. For this reason i asked you to fix the "bug" 'cause i thought you used absolute path.
But now i realized fftw3.dll is called by avisinth itself, infact if i put the fftw3.dll in the same dire as the .avs the library is downloaded.
...

1. fftw3.dll is called not by avisynth itself, but my plugin via LoadLibrary("fftw3.dll").
2. But current path for DLL search is not your the avs dir, but folder of host application (virtualdub or other), that loads the avisynth.

[3ngel]

and manually lookin the same folder as fft3dfilter.dll was loaded from if the first LoadLibrary fails

I had not the "courage" to ask for that, having had the impression Fizick was a little "upsettable" when talking about his plugin, but it would be great if this addition would be made

[Fizick]

Put non-plugin DLL at plugin folder is (was ?) bad practice.

[3ngel]

I don't understand why you say this.
Putting dll in plugin folder makes it much more simple for plugins to work, and obviously totally portable.

[tsp]

if you put a non-avisynth plugin dll in the avisynth autoload folder avisynth will waste a small amount of time figuring out that the dll is not a plugin when the script is loaded.

[3ngel]

We are not talking about autoloading folder, but in separate dir (that is external plugin dir).