How to achieve bidirectional load-time linking

Hi

Consider a host application that allows users to author plugins as dynamic libraries. The host needs to call the plugin to ask it to perform, and also provides an API which the plugin can call:

HOST ==> PLUGIN ==> API

If the functions in API are encapsulated, data-wise, no problem:

0) HOST is the executable, PLUGIN exports functions for HOST to call, and API is a dynamic library with exported functions for PLUGIN to call.

But what if the functions in API operate on data that is shared with HOST? In this case, some interaction must take place between HOST and API, and it's not clear to me what is the correct module/linking arrangement to use. Ideas so far...

1) Function Stubs: As 0, but API function exports are stubs that call implementations in HOST. API includes one function to connect the function pointers associated with the stubs at start-up. Inefficient, because one API call becomes two function calls and a pointer resolution.

2) Function Pointers: As 1, but the function pointers are exposed directly as exports from API, rather than being hidden behind function stubs. Less robust to misuse, but more efficient.

3) Main Stub: HOST and API reside in a single dynamic library, and main() in the executable is a stub that hands control over to it. Efficient, but not sure if it introduces problems when HOST is updated.

4) As 3, but HOST and API reside in separate libraries, whilst main() is still a stub handing control to the HOST library. Avoids problems on updating HOST?

5) Executable exports: Executable implements HOST and API, there is no library, and PLUGIN author gets only a header showing what API functions will be available at load-time. At load-time, the plugins are linked with functions exported from the executable. May be impossible on some or all platforms.

6) Struct Of Functions: API is offered as a .h header only (no binary library), and a struct of function pointers is passed to PLUGIN after loading; the same pointer approach as in (2), but without needing a dynamic library.

The various approaches have their pros and cons - I would much appreciate some input - how should I choose between these? Is there, ideally, a "standard solution"? I favour 5, or 3/4 if that is impossible due to system limitations. 6 seems like the best of the inefficient rest, but smacks of reinventing the wheel (where the wheel is the load-time linking process).

I have tried to keep this question language and OS non-specific. I realize that there may be issues with specific compilers/systems, but I feel there should be an underlying truth, nonetheless.

Thanks in advance, guys.
Ben Mitch
.

Relevant Pages

  • Re: How to achieve bidirectional load-time linking
    ... Consider a host application that allows users to author plugins as ... dynamic libraries. ... The host needs to call the plugin to ask it to ... If the functions in API are encapsulated, data-wise, no problem: ...
    (comp.lang.misc)
  • Re: Accessing XP Machine from a WinCE device through Network
    ... I called the WNetAddConnection3() API with the parameters set as below: ... long as you can ping devices on the private network from your device. ... So is there a possibility to allow access to the host without this Login ...
    (microsoft.public.windowsce.embedded)
  • Re: Sending HTTP request
    ... Using gethostbyname() API you'll be able to get the host address. ... With socketAPI you'll create a new socket descriptor. ... have headers files for C language (both struct definition and function ...
    (comp.sys.ibm.as400.misc)
  • Re: compile dll with calls to methods that dont exit yet
    ... etc) that your host provides. ... host exe and your plugin dll. ... replace any class references with the ... void DoSomethingHosty; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: plugins in a delphi program?
    ... First, you need to bind a plugin into your program, so its functions ... by a non-visual component on the host form. ... and all plugin components in the same ... These event handlers were four in number, ...
    (comp.lang.pascal.delphi.misc)