Mail Archives: djgpp/1996/05/19/17:47:07
On 19/5/96 12:07 pm, <Sengan DOT Short AT durham DOT ac DOT uk> did thus say >>>
> Since there is much talk of dynamic linking, and some people are already
working
> on it, I'd like to make a suggestion: It would be nice if the linking supported
> choices. What I mean by this is that particular implementations of the
functions
> to be linked in could be chosen dynamically.
This is inherently part of the whole idea behind dynamic linking. This will be
done by the requesting module also stating which module it would like the
funcitons to come from (when possible that is).
> The motivation for this is to allow the central program to support different
> implementations of functions, depending either on user choice or hardware
> configuration. For instance, in a game, 3 levels of graphic detail could be
> supported by 3 different implementations of the key functions: no/cheating/true
> texture mapping; or no/gouraud/phong lighting. Similarly, key routines may be
> optimized for 386/486SLC/486DX/586/K5/686/PPro... differently because of
> different cache size; or for VGA/...accelator boards. Putting all of these into
> the executable results in bloating it. Ok there is virtual memory, but it may
> be preferable to avoid using it to gain speed.
My goals, but in more detail.
> Clearly the simplest way of implementing this would be to allow choice of
> library archive for the program next to be executed on the command line.
> As long as the dynamic linker only loaded to memory the functions that were
> actually to be used in the program (rather than others lying in the library
> for other programs, say) this would already be very useful. A game could then
> include a small executable that determined the choice of hardware/detail/etc
> before executing the main game.
I believe this is what Eric and I are working towars
> However what I was thinking, would be to allow dynamic relinking during the
> game: the main executable would be responsible for declaring which functions
[nifty uses snipped]
Yes, this is part of MY reasons for implementing DLLs.
>
> By using name mangling, different implementations of the same functions could
> be put into the same library avoiding many different libraries. Clearly this
That's one way, and I think it's be implicit in the way DLLs will be implemented,
but the calling s/w will hoppefully ba able to specifiy the module name for the
functions as well.
> Clearly, this would be some work, but I think the additional flexibility would
> prove very useful. I would like to participate... but unfortunately have a
> thesis to finish :-( !
It is some work, but not realy that difficult (yet). Good luck (or whatever) on
your thesis:
> Thanks for your time,
>
> Sengan
Bill
- Raw text -