Re: [AD] Allegro plug-in system (was: Is there a licensing reason why PNG isn't built-in to Allegro?)

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 3/25/06, Victor <vwss1984@xxxxxxxxxx> wrote:
The DLL hell is so bad mainly because the DLLs may get out of sync
easily, breaking API and ABI compatibility. Sometimes programmers don't
see that and the programs run strangelly, bugged, crashing randomly, or
misteriously won't compile giving away spurious errors deep inside
libraries. Worse, is possible to create programs which relies in some
bugs introduced by the DLL hell. This is even worser to novices.


if they are out of sync, they just won't load. At  least with a proper system, like allegro's unix plugins (or an enhanced version there of).

As an example. Imagine if someone is building a game with Allegro-core
DLL 4.3.5, however using AllegroBMP DLL 4.3.3 and AllegroWAV DLL 4.3.6,
things will not work. If the user recompile each DLL, but for some
reason forget to recompile one or recompile to a different version, we
will get a DLL hell.

Only if they were stupid enough to do each one seperately, which in those specific cases, would have to be included in the main distro.
 

Victor Williams Stafusa da Silva

--- Elias Pschernig <elias@xxxxxxxxxx> wrote:

> On Sat, 2006-03-25 at 19:43 -0300, Victor wrote:
> > So we should get a plug-in system which comes with the standard
> > plug-ins plugged on by default, so newbies won't need to struggle
> on
> > how plug everything together. The experienced users could turn them
> > on/off easily.
> >
> > About the DLL hell, we should think a way to workaround this. I
> have
> > seven ideas:
> >
>
> If "DLL hell" is so bad, why do we provide modules under unix even
> now?

To keep down on the ABI/lib breakage in unix, with the shared objects, allegro can just load various drivers that happen to exist, and add them to the list. Otherwise allegro would always link to all supported drivers, like dga, esd, alsa, oss, artsd, etc.


> I think this always should stay as option.
>
> The option to build everysthing static also should stay, I like it if
> you can create a single huge .exe :)
>
> Building just one DLL probably isn't hard either, just need a
> plugin-aware mechanism in the build process.

Thats a good way as well,  provide an api to allow plugins to register them selves, or have the user register the ones they use, and then they can all be static linked, or the user can even make his own plugin system, by loading his own dlls or sos, and they link to and register the addons. (this is probably the way I'd do it)

> --
> Elias Pschernig



_______________________________________________________
Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça.
http://br.messenger.yahoo.com/


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
--
https://lists.sourceforge.net/lists/listinfo/alleg-developers



--
Thomas Fjellstrom
http://www.strangesoft.net
tfjellstrom@xxxxxxxxxx

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/