From: Sengan DOT Short AT durham DOT ac DOT uk
Message-Id: <28123.9605190007@bylands.dur.ac.uk>
Subject: Re: ELF and dynamic linking
To: djgpp AT delorie DOT com
Date: Sun, 19 May 1996 01:07:19 +0100 (BST)
In-Reply-To: <4nje94$o3@news.manawatu.gen.nz> from "Malcolm Taylor" at May 18, 96 01:53:36 am
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.

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.

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.

However what I was thinking, would be to allow dynamic relinking during the
game: the main executable would be responsible for declaring which functions
it needed before calling any of them. I assume the linked functions would
simply be put onto the heap (cs=ds under djgpp), so the space could be
reclaimed, and as long as the structures used for dynamic linking were
maintained, I see no reason why it would not be possible to relink. This would
allow the user to change his mind during the program. S/He might wish to play
sections in low detail, because jerky animation makes him/her sea-sick, but
change to high detail to look around, and so on.

By using name mangling, different implementations of the same functions could
be put into the same library avoiding many different libraries. Clearly this
would be of particular interest to users of C++, who could use the class system
to hide away all these implementation details. However even C users would
benefit, as they could choose the functions of their choice by the appropriate
use of structures containing pointers to the functions' implementations and
their names for loading.

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 :-( !

Thanks for your time,

Sengan