On 11/28/18 10:53 PM, Lucas Cordiviola wrote:
The thing with Windows is this as a general rule:
sure. this is all true for dependencies. however, as soon as DLLs are "manually" opened by the caller (aka "plugin loading"), i think this is no longer true.
- A - the same dir as the calling dll, in this case the same dir as
gem.dll.
well, *this* is not true in general. Pd does some extra magic to allow for this to happen.
anyhow, what i really want to say is, that you *might* well be out of luck when you try to bundle codecs together with Gem. in detail:
consider ..../extra/Gem/Gem.dll. the Gem.dll itself has very few external dependencies (basically msvcrt/stdc++, OpenGL, and freetype/ftgl; thats about it) esp. it has *no* direct dependency on any video loading framework like QuickTime.
however, Gem.dll will look for backend plugins, and might eventually find ..../extra/Gem/gem_videoQT.dll. (sidenote: this does not necessarily happen while Gem.dll is being loaded; this means that the Pd-specific hack to also look for DLLs besides the currently-being-loaded externals (in our case "..../extra/Gem/") is not in effect!). gem_videoQT.dll is a backend that depends on QuickTime, but is implemented in a way that it doesn't use any hard dependency. when't it's loaded it will try to find some "QuickTime.dll" (or somesuch) in the default locations, open that library and initialize it (and if it fails, it will print out a nice error message).
now the real fun only starts now: i *suspect* that QuickTime itself uses a plugin-system to load (additional) codecs. these codecs would be dll-files that are installed "somewhere on the system". typically they are not installed "besides the main.exe" (and most likely, they are also not installed into C:\Windows\system32) but probably in some QuickTime specific location (e.g. %CommonProgramFiles%), where QuickTime is hardcoded to look for (just like Pd is hardcoded to search for externals in a few "well known" places). if this was the case, you would need to put your codec files in one of these "well known" places, rather than "besides pd.exe" or "besides gem.dll".
now this is all speculative and it might not be true in the specific case of QuickTime (i somehow seem to remember that QuickTime has most/all codecs built-in). what is true however, is that we are not dealing with ordinary dependency resolution, so much of what applies there might not apply here.
fgmdsar IOhannes