in this case, the "put it besides the exe" might work or not (e.g. afaik, Pd will *not* find externals you put in the same path as pd.exe).
The thing with Windows is this as a general rule:
Pd loads an external (gem.dll for example)
if the external is calling a dependency dll (i.e gem.dll is calling foo.dll) there are certain places Windows will auto-handle (not sure which order)
A - the same dir as the calling dll, in this case the same dir as gem.dll.
B - the same dir as the main.exe, in this case next to pd.exe.
C - global system folders as "C:\Windows\System32" or "C:\Windows\SysWOW64", this last is tricky as this is the correct place where 32bit.dll's should go on a 64bit-OS. "syswow64" stands for "Windows On Windows 64" here goes 32bit dlls. On a 64bit-OS "system32" holds 64bit dlls.
Mensaje telepatico asistido por maquinas.
On 11/28/2018 5:47 PM, IOhannes m zmölnig wrote:
On 11/28/18 7:49 PM, me.grimm wrote:
when does your class start?
i think antoine is right... DLL's can just be put in the same directory as executable.
hmm, i guess this is a bit misleading. windows will search in a couple of paths (including the path were the executable resides) to find DLLs required for the executable to run ("dependencies"). however, codecs - while technically being DLLs - use a completely different loading mechanism: files are scanned for in known directories and then loaded on-demand ("plugins"). this makes it possible to install additional codecs, and is very similar to Pd's external loading. in this case, the "put it besides the exe" might work or not (e.g. afaik, Pd will *not* find externals you put in the same path as pd.exe).
i cannot comment on the original issue.
fgmdsar IOhannes
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list