[Scummvm-devel] Release plans, once again

[Kevin Harris]

>From: Marcus Comstedt <marcus at mc.pp.se>
>
>Uh, I'd prefer not to have to implement real shared libraries...
>It's messy++.

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.

I've done this before and even taken it to the point of providing a faked 
shared library mechanism.  Everything was really statically linked, but 
still used the library interface to access symbols from within the static 
executable; all translation was done based on external text files that 
provided mappings for the symbols that normally appeared in the libraries.   
This was for a platform where it wasn't possible to use exception handling 
in real shared libraries (AIX).

These library interface wrappers aren't bad, although they do cause a little 
overhead (a potential bottleneck).

> > (2) Make sure NONE of the shared libraries is linked against the
> > common library (IIRC there may be issues to resolve on OSX, since the
<snip>
>
>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.  
Runtime size would be spared (with a decent separation of  "non-common" 
libraries that are selectively linked to the engines), but overall size 
would increase since there would be duplicate object files used among those 
engines.

It would save memory if a form of relocatable (and completely removable) 
modules was implemented.  It would slow things down a little bit, however, 
depending on how it is implemented.  There would still be the memory 
overhead (and some address translation overhead) of maintaining most (or 
all) of the symbol references until the point is reached where it is decided 
that modules can no longer be repositioned and no further modules loaded.

Anyway I'm not expecting any of this to happen.  I know I'm currently too 
busy (and lazy) to implement it myself.  I guess I was just sounding my 
semi-anual "peep". :)

-Kevin-

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/