[Scummvm-devel] Release plans, once again

[Marcus Comstedt]

"Kevin Harris" <gopickyournose at hotmail.com> writes:

> Well, If you were to make a wrapper around the library interface, you
> could implement them to whatever degree of messiness you like.  All
> that needs to be exposed to the rest of the program is an interface
> for retrieving symbols (type informaton about those symbols would be a
> plus) and some method of loading (and possibly unloading) modules.

No, relocations between modules would have to work too.  Which is
precisely what I don't have to worry about with the current approach.
Each plugin is statically linked against the main binary, and only
needs internal relocation (due to the fact that the load address is
not known beforehand).


>>The downside of this is that if there are object which really are
>>ununsed, they would get included anyway.  Also, for memory efficiency
>>reasons, it would be better if an object which is used by some engines
>>and not by others (and not by the common code) was linked with those
>>plugins, to prevent it from being loaded in memory when using one of
>>the other plugins.
>
> If each engine was completely self-contained, and it could be
> guaranteed that no two engines can be loaded at the same time, it can
> still work.

You don't need the guarantee that two engines can't be loaded at the
same time; if they don't need to share global (static) data there is
no problem with having multiple copies of stuff loaded (apart from the
fact that is uses more memory of course, but that's just until the
other modules get unloaded).


  // Marcus