Re: OOC Package Tool: Repositories

[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.

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.

Each process keeps a count of how many references it has to a dynamic
library. Libraries are identified by name (the name of the object file
containing the library) or by handles (a HMODULE or HINSTANCE). 

PROCEDURE LoadLibrary (lpszLibFile : LPCTSTR) : HINSTANCE;

LoadLibrary attempts to load a library given a file name. If the library is
not resident in memory, it is mapped into the process address space (it may
already have been loaded by another process). If this is the first
reference to the library for the current process, the system calls the
library's DllEntryPoint with parameter DLL_PROCESS_ATTACH. This allows the
library to do any per-process initialisation. If successful, it returns a
handle to the loaded library. There is a rather elaborate system for
locating libraries if the path is not specified. This includes searching
the current directory, the directory from which the application was
started, system directories, the current PATH, etc. Presumably, the package
management system would implement its own scheme to locate object files
within repositories.

PROCEDURE FreeLibrary (hLibModule : HINSTANCE) : BOOLEAN;

Removes a reference to the library. If this is the last reference for the
current process, the system calls the library's DllEntryPoint with
parameter DLL_PROCESS_DETACH. This allows the library to do any per-process
clean-up operations.

PROCEDURE GetProcAddress (hModule : HMODULE; lpszProc :LPCSTR) : FARPROC;

Returns a pointer to a named exported function within the given module.

There are also a variety of miscellaneous functions. GetModuleHandle and
GetModuleFileName can be used to map between module names and handles.

FindResource returns a handle which can be used by LoadResource to read a
resource from a library. This functionality is fairly specific to Windows
and would probably not be generally useful. Anyway, this can always be
implemented using the regular functions if required. That is, if a module
wants to export resources it defines exported functions such as
FindResource or LoadResource to do the same job.

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.

- Stewart