[PD] (GEM) running pix_film without installing quicktime?

Lucas Cordiviola lucarda27 at hotmail.com
Thu Nov 29 00:10:42 CET 2018


I'm not a Gem user so i might be missing a lot of knowledge.

What i have exposed is only based on work with "http://www.dependencywalker.com/"<http://www.dependencywalker.com/> and some Pd externals.

Tests loading externals without Pd shows the Windows-Auto-Handling that I've described. This of course could not be the case for Quicktime or Gem.


:)

Mensaje telepatico asistido por maquinas.

On 11/28/2018 7:56 PM, IOhannes m zmölnig wrote:

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.




3) 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





_______________________________________________
Pd-list at lists.iem.at<mailto:Pd-list at lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20181128/514d1dc9/attachment-0001.html>


More information about the Pd-list mailing list