Shared Libs

[ekl%beastie@SDF.LONESTAR.ORG]

OK, here is my idea for shared libs .. it's based on the AES/VDI trap.

Every program to use shared libs gets a special set of header files.
These header files #define every function to something like -
#define fopen(name,mode)	_dispatch(_lib_stdio,_FOPEN,name,mode)

The _dispatch function sets a reg, d1, to point to _lib_stdio, and
its second argument is an ordinal value, placed in another reg, d0.
The other args are passed on the stack.  The dispatch function is 
statically linked with your app.

Every module has its own structure, such as this :

	struct _lib_stdio {
		void *	basepage;   /* set by lib. start-up code */
		char *  filename;   /* fixed in header file */
		char *  module;     /* fixed in header file */
		void *	data_block; /* set at run-time */
	}

Each structure would have the 2nd and 3rd pointers filled out for you.

Once the _dispatch function sets up for the call, it executes a trap,
such as trap # 3 or something currently unused.  The trap executes code
that is responsible for finding the proper function using the information
from the structure and a set of hash tables.  If the function is not in
the hash tables, then it is loaded into shared address space from the
library file in "filename" - loading only module "module".  It then executes
the function described by the function number (0 for load - no function,
1 for execute first function, 2 for second function, 3 for 3rd, etc).
If the module contains non-constant data which cannot be shared then it
is loaded into a new block of memory and "data_block" is set to it (this
will be null if this app hasn't called the lib yet).  The function is
then executed and put into the hash table.

The loaded functions are kept in memory even after apps quit - however,
only the functions/modules actually used have to be loaded - and then
only if the app needs them at run-time.  When a second app needs the
same function its already loaded.  Modules may be unloaded, reloaded,
or even moved during run-time, and MiNT may unload the modules as memory
space becomes sparse.

No load or unload functions are needed (unless the programmer wants to
make use of function 0 to pre-load functions for faster execution time).  And
you should be able to make even stdio shareable without hacking up your
C code or compiler.

Well, anything I missed?   Is this a good way to go about implementing this?
Or should I go back to the drawing board?   I'm looking for someone that
has some constructive (or destructive) comments on this idea.  I think
using a trap like this would really help.

Also, a new AES/VDI could be implemented in much the same way, except use
trap #2 instead of #3, and no structure would be required since the library
names would be fixed, as well as module names.  A separate hash table would
be used - and all parameters would be passed through the usual trap mechanism.
The only difference being that the OS might not have all the AES/VDI functions
in memory!  Imagine if the file selector was just a .o in some .olb file on
disk that was loaded when you started GEM, and unloaded when you quit GEM!
Same goes for windows and such.

Thanks,
Evan Langlois
sdf.lonestar.org