Browse Prior Art Database

Compile Time Binding Of Dynamically Loaded Modules Disclosure Number: IPCOM000083508D
Original Publication Date: 2005-Mar-01
Included in the Prior Art Database: 2005-Mar-01
Document File: 2 page(s) / 50K

Publishing Venue



A method for compile time binding of dynamically loaded program modules (called components), allowing a dynamically loaded component to efficiently invoke interfaces provided by a different independently dynamically loaded component without a specialized loader. In this context the term "component" is intended to imply an integral part of a larger "subsystem" running in "kernel context", where "subsystem" is intended to imply a collection of programs (and possibly data) that supplies significant function to the operating system. "Kernel context" means that this collection of programs is running in a privileged state that is normally reserved for programs able to damage other parts of the operating system or other services executing on the operating system that are not in "kernel context". The forgoing description is necessary to distinguish the application area of this method. There are many existing methods and mechanisms for providing dynamic loading of individual program components.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Compile Time Binding Of Dynamically Loaded Modules

A method for compile time binding of dynamically loaded program modules (called components) is described, whereby interface definition files from independently compiled supplier components are included in the source for a user component at compile time. Together with language preprocessor macros, the instruction sequence for the invocation of supplier component services are generated at compile time.

    While the total amount of code involved in the eventual "subsystem" may be large, the use of modern computers and compilers makes it reasonable to maintain the subsystem in "source" rather than object form. That is, even though individual "components" are dynamically loaded and may not all be required for the subsystem to provide significant functionality, it is both feasible and convenient to recompile all components on a frequent basis so that the compile time nature of the dynamic binding is not a significant impediment to code development, test and deployment. Other mechanisms for providing "run time" binding of services involve a specialized loader that is able to understand something that closely resembles a "dynamic load library". The mechanism employed by this method requires only the ability to load a collection of already linked components and access their respective Component Control Areas (CCAs). The cost of cross component service invocation is comparable to that of other widely used dynamic load library mechanisms.

    To utilize this mechanism, each user component that wishes to invoke services from another supplier component must: 1. provide a pointer, in its own storage, to the CCA (Configuration Control Area) of the supplier component whose services it wishes to invoke

2. initialize that local pointer to the supplier component's CCA.

    This local CCA pointer is refered to as the reference CCA of the supplier component that is provided when the supplier component is loaded by the user component.

    The supplier componen...