Portable version of GStreamer 1.5.2 on Windows

[Josh Doe]

On Wed, Aug 26, 2015 at 6:35 AM, Harry <mckameh at wanadoo.fr> wrote:
> To follow Windows rules, and also Linux rules, the code needs do nothing except of course load the DLL/library.
>
> The OS automatically searches all the possible paths.

This is true for the common shared library, where an executable or
shared library is linked to another library, and at run-time that
library is found in an OS dependent manner. However, plugins have a
sort of reverse dependency, so the standard OS mechanism is of no use.
GStreamer, along with any other plugin system, must have a way to know
which shared libraries (plugins) it should attempt to load. One way
would be to use a simple list of filenames, another would be to scan a
directory for shared libraries, load each one, and check if the
appropriate symbols are exported. In the case of GStreamer, it does
such a scan, looking for a symbol "gst_plugin_desc that is a struct of
type GstPluginDesc"
(http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPlugin.html#GstPluginDesc).

Plugins are located in a separate directory for several reasons that I
can think of. First of all, I just think it's cleaner, makes it easier
to know which DLLs/SOs are plugins, and it's easier to
add/remove/upgrade plugins. Also you avoid the extra time it takes to
check all the shared libraries that aren't plugins, which can easily
be in the hundreds. And, if an application reports plugins that didn't
load correctly, this could produce lots of false alarms. Then, at
least on Windows, using LoadLibrary and GetProcAddress to check for
symbols will cause DllMain to be run which could execute slow or
dangerous code (though there seems to be a way to get around
LoadLibrary to check for the presence of symbols).