Re: OOC Package Tool: Repositories

[Michael van Acken <acken@vanacken.do.uunet.de>]

> Date: Mon, 12 Apr 1999 16:20:48
> From: Stewart Greenhill <greenhil@murdoch.edu.au>
> 
> At 05:55 PM 11/4/99 -0400, Michael Griebling wrote:
> >Michael van Acken wrote:
> >> Any help is appreciated.  For starters you could do a survey which
> >> features we can use to implement dynamic loading under various
> >> systems.  We have ELF dlopen(), HP-UX shl_load(), GNU DLD, and
> >> libtool.  Should we use the low-level interfaces, or could we use
> >> DLD/libtool as an abstraction layer?
> >
> >I'm not sure what DLD is but I've had nothing but problems with libtool
> >under BeOS.  Whatever path we choose, I'd like it to also work under
> >BeOS.  I'll check whether the low-level stuff you talk about is available
> >under this OS.
> 
> I'd be interested to know what DLD does and how portable it is.
> 
> We probably need a simple abstraction layer that handles dynamic loading
> and unloading. This could be built on top of DLD (for Unix systems), but it
> needs to be implementable using whatever low-level OS facilities are
> available.

I couldn't get the current libtool-1.2f sources, but it looks like it
offers exactly such an abstraction layer.  It will certainly work for
ELF targets, and it might even include Win32 support.  Can anyone
confirm/deny this?

> For what its worth, here's how dynamic loading works under Win32...
> 
> Each loadable module consists of:
> 1) A number of exported functions
> 2) A number of resources. These are identified by name, or integer ID.
> Resources include things like dialogs, bitmaps, font resource, string
> tables, etc.
> 3) An optional function DllEntryPoint.
> 
> [... lots of useful details deleted]

The information you provided is probably sufficient to use a DLL, but
how can oo2c actually build one?  Scanning the libtool news page, it
looks like it is not trivial to do this under Windows.

> Can anyone comment on how this compares with other operating systems? Is
> anything else required? 
> 
> Presumably, it makes a difference if the loaded module is Oberon-2 rather
> than just a generic collection of "C" procedures. Functions that rely on
> type descriptors or other run-time structures (eg. Types), need these
> structures to be merged upon loading. If dynamically loading Oberon-2
> modules, does the dynamic loader need the symbol files to check interface
> compatibility (versions, signatures, etc), or is this information encoded
> in the library object file? Could this be an opportunity to incorporate
> some more sophisticated meta-programming into OOC? Given that elements of a
> package can be reliably located at run-time, it would be possible to
> include run-time meta-data files within a package to support debuggers or
> heap browsers.

The Oberon-style of dynamic loading only provides dynamic access to a
single kind of resource: parameterless procedures that are exported by
the loaded module.  This kind of information is easily added, e.g. by
hardcoding the list of such procedures into each module.

To ensure interface entegrity between modules, the symbol file
fingerprints can be hardcoded into the modules.  That's exactly what
is being done during compilation, and it will serve equally well
during run-time.

To get the full range of meta-programming it makes sense to slurp the
symbol file into the program during run-time.  This way the whole
exported interface of a module can be made accessible to the program
without sacrificing type safety.  This would even work with oo2c.
After array descriptors have been added to the run-time environment,
all program data (excluding the procedure stack) can be accessed
through a `Ref'-like library module.

Now, is anyone here motivated enough to make this happen?

-- mva