[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On April 12, 2010, Matthew Leverton wrote:
> On Mon, Apr 12, 2010 at 1:04 AM, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>
wrote:
> > flac would be static linked into allegro_acodec-FLAC.dll in most cases.
> > instant surety that it would work fine.
>
> We already have allegro_flac.dll that people can statically link flac
> with. allegro_acodec-FLAC is the same thing as what we already have,
> just with a longer name. It doesn't give us anything useful, in my
> opinion.
Except now allegro/acodec is automatically loading the codecs and can
gracefully fail. Rather than a startup error from windows saying some dll
was not found. And noone has to link to any of the individual codec support
libs, or the codecs themselves.
> > In case that dynamic linking the
> > dependency into the loadable modules is supported, dlopen/LoadLibrary
> > will fail, and the format support won't be added.
>
> Dynamic linking always has the potential to fail regardless if dlopen
> or a traditional compile time link is used.
But as I said above, it fails horribly at start up if you linked directly to
the lib and its not compatible.
> e.g., alleg42.dll files aren't even guaranteed to be compatible across
> versions or compilers. I cannot image that using dlopen would be any
> worse in real situations. I'm pretty sure SDL uses it to load audio
> formats, and it's basically infinitely more popular than Allegro. ;)
I dunno. I suppose one could consider an implementation that calls dlsym on
a large number of functions in say libFLAC.dll to be functionally equivalent
to another that just dlsym's one function that initializes the new
codec/image support itself. But somehow I find the plugin based setup far
cleaner.
what I'm assuming you propose:
acodec.dll:
int init_acodec() { init_flac(); init_blah(); ... }
int init_flac() {
dlopen("libFLAC.so");
// load a crap load of flac functions into function pointers here
}
// and do the same for other format as well
what I'm proposing:
acodec.dll:
int init_acodec() {
foreach(plugin in plugin_dir) {
dlopen(plugin);
plugin_init = dlsym("init_plugin");
if(plugin_init)
plugin_init(...);
}
}
And of course either method could be expanded to support loading the libs at
first use, to cut down on memory or whatever the need is (it probably isn't
worth the effort imo).
All you need to do to support more formats now is to stick a few dlls in the
plugin dir and call it a day. Some safety could be added to check the
plugin's ABI version against allegros, and fail a load if they don't match.
> --
> Matthew Leverton
>
> -------------------------------------------------------------------------
> ----- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx