Al,
I've been doing some serious research in the area of
shared libraries and dynamically linked code/data segments.
About a week ago I presented an idea for MicroWindows/NanoGui
applications that would allow "applications" to be written for
these graphical systems that could be linked and distributed
separately and call the server without requiring the overhead
of local unix sockets etc when making api calls.
The cross-elf package is an ingenious piece of code
that quickly allows linux, DOS and windows applications to
load 32-bit relocatable ELF modules into the application's
memory space, and allow dynamic linking to the mother
application, as well as any other system shared libraries.
I have finished a design that would allow identical
codefiles for linux, windows and DOS (protected mode)
and run identical binary nanoGUI and/or microwindows
applications, all created one time using the gcc compiler
on linux.
The problem that I've been dealing with lately,
is that of course, we must have ELKS support for this
new scheme, and ELKS doesn't support 32-bit binaries.
So, I've been investigating the ELKS 16 bit relocatable
formats, and have come up with the following idea, which
would allow user mode linking (the same as the ELF
format is implemented - they're not actually loaded by the
kernel) of dynamic libraries. In fact, properly done,
ELKS could have loadable kernel modules and
loadable user mode shared libraries that have the
same format.
Basically, the idea is that we use the Introl
object file format as the relocatable format for shared
libraries. This format is output directly by as86, and
read by ld86. It handles 16 and 32 bit relocations,
and completely specifies import and export symbols,
required for dynamic linking. Data imports/exports
are also handled. I will be writing an ELKS .o file
loader that will be part of the microwindows
subsystem loader, and I was thinking that this could
be used to implement full blown shared libraries
for any ELKS executables. An a.out with
shared libraries would just link in a piece of libc
code that calls this loader I will write and dynamically
links the symbols that are required. The libc
code would execute on startup and could be dragged
in with a single symbol, specified by a new linker
switch.
I won't bore everyone with additional details, but
I've thought this through in quite some detail, and have
tested various portions of this concept on Linux and windows.
How does this fit with your ideas of DLL's on ELKS?
Greg
