DynObj - Dynamic Binary Runtime Plugin Objects Hosted by:
 SourceForge.net Logo

DynObj - Overview

Features of the DynObj Library

It makes sense to think of DynObj as a type information system that is shared between libraries/executables compiled by different (possibly different language) compilers:
  1. Interface classes are shared formally.
  2. The binary layout of a compound object is exposed in a well defined way.
  3. Intefaces and class hierarchies can be used intuitively and directly across plugin boundaries.
  4. All interface classes can be shared, also those that don't derive from a single default root interface (such as IUnknown in COM).
  5. A language neutral representation of type information is used.
Point (4) implies that DynObj can handle multiple types of object ownership (i.e. ref counting is not enforced).

The last point means that DynObj plugin libraries can be implemented in compiled languages other than C++ (and also used from other languages).

Similar libraries

There are other approaches that does similar things (xpCOM, COM, and CORBA). These are some differences:
  • The DynObj library is based on a shared type system, it does not rely on a member function QueryInterface, to retrieve interfaces. The DynObj type system does this work silently.
  • A wider range of types is handled (since a root base interface is not enforced).
  • It allows for different object ownership models (strong/shared/weak).
  • DynObj does not rely on an IDL layer. Interface definitions are are ordinary classes and not weighted down by a heavy use of macros.
The DynObj library is more lightweight and not dependant on a large code base or OS specific.

Other libraries have features such as out-of-process execution, distributed objects and much more, areas which DynObj does not touch.