DLL address space and plugins

[Chris]

Hi,

first of all: sorry if this is not a pure C++ question, it is somewhat
OS-specific but I think it fits here best.

I have a base system with capabilities for loading plugings. Plugins
comply to a given interface and can be loaded using LoadLibrary/
dlopen. To access the plugin-object itself I use a function in every
plugin that has a predefined name using:

extern "C" __declspec(dllexport) ModuleInterface* createModule
(unsigned long id)
{
return new SpecialPlugin ();
}

This way I call GetProcAddress/dlsym to get the function pointer and
execute it to get the plugin-object in my base system.

This all works fine but I have two problems:

1. the plugin-object is created in the address-space of the DLL and
thus it can not natively use the objects (singletons) in the base
system
2. some functionality that the plugins use is in the base system.
Naturally I get linker errors if I do not compile this functionality
into each and every plugin _and_ the base system. (some of this
functionality is made up of singletons which then (see problem 1) get
instanceiated in each plugin, too)

Any suggestions on how to solve the problems or change the design to
something better are welcome!

Thanks,
Chris

[Gianni Mariani]

Chris wrote:
....

This way I call GetProcAddress/dlsym to get the function pointer and
execute it to get the plugin-object in my base system.

Or, you can use a factory registry pattern thing like the one in Austria
C++. If you use this methodology, you don't need to worry about the
dlsym call.

>
This all works fine but I have two problems:

1. the plugin-object is created in the address-space of the DLL and
thus it can not natively use the objects (singletons) in the base
system

You can export the appropriate singletons.

2. some functionality that the plugins use is in the base system.
Naturally I get linker errors if I do not compile this functionality
into each and every plugin _and_ the base system. (some of this
functionality is made up of singletons which then (see problem 1) get
instanceiated in each plugin, too)

You can export the appropriate symbols from your "base" system.

>
Any suggestions on how to solve the problems or change the design to
something better are welcome!

I think you can solve this problem with platform specific stuff.
Austria C++ does create a DLL that does export a number of symbols and
uses a few macros to help with that.

[Robbie Hatley]

"Chris" wrote:

... DLL ... plugins ... LoadLibrary ... GetProcAddress ...

Those are not C++ concepts. This group is for discussing
the C++ language, and it's usage. Those sound like Microsoft
things. Ask your question in a Microsoft Windows group, such as
one of these:

comp.os.ms-windows.programmer.win32
microsoft.public.win32.programmer

(Or a group that specializes in whichever API you're using,
such as microsoft.public.dotnet.* for dotnet, etc.)

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
triple-dubya dott tustinfreezone dott org

[Gianni Mariani]

Robbie Hatley wrote:

"Chris" wrote:

>... DLL ... plugins ... LoadLibrary ... GetProcAddress ...

Those are not C++ concepts.

C++ does introduce a unique set of issues because of name mangling and
it's important to highlight C++ specific ways of dealing with them.

The OP does have other platform specific issues thought which are best
answered as you suggested.

[Victor Bazarov]

Gianni Mariani wrote:

Robbie Hatley wrote:

>"Chris" wrote:

>>... DLL ... plugins ... LoadLibrary ... GetProcAddress ...

Those are not C++ concepts.

C++ does introduce a unique set of issues because of name mangling and
it's important to highlight C++ specific ways of dealing with them.

The problem with answering those questions here is that the issues you've
pointed out only exist with development done using different complilers,
which is not really covered by the Standard (at least yet). The current
state of affairs is that the compatibility exists only with the source
code, and is not guaranteed at the binary level.

Of course, just mentioning those issues and where they come from may be
viewed as within ?++ realm, and therefore on topic here...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Chris]

Of course, just mentioning those issues and where they come from may be

viewed as within ?++ realm, and therefore on topic here...

Hi,

to make sure people are not confused: my question is not platform
specific. Nearly any platform can load libraries, invoke function
calls on those, etc. Let it be Windows with LoadLibrary or Linux with
dlopen, I don't care. My question is more a design problem I encounter
on how to design a plugin system.

Generally: I have a base-system and plugins. The base-system loads
plugings. The plugins need some functionality that lies in the base-
system. Can it be done this way? Any cleaner ideas?
How is this done in other projects that allow addons/plugins?
Obviously the addons in Mozilla Thunderbird access the base-system,
too. So there is a circluar access.

By the way, I found a document on open-std.org that describes ideas
about a plugin system in the C++ language coming from the "Modules &
Libraries" subgroup which works in the "C++ Modules" working group.

Regards,
Chris

[Gianni Mariani]

Chris wrote:
....

By the way, I found a document on open-std.org that describes ideas
about a plugin system in the C++ language coming from the "Modules &
Libraries" subgroup which works in the "C++ Modules" working group.

What - my Austria C++ generic factory thing not good enough for ya ? :-)

The issue you do have is system specific however. It's not plugins,
it's accessing symbols from a "base system". Put the "base system" in a
DLL/DSO and link your plug-ins with the "base system" DLL. In Windows,
you need to explicitly export symbols. On *nix you don't as the default
is to not export them. However it's probably better if you opt to
explicitly export symbols on *nix in the future as well but you can
consider that an optimization.

[James Kanze]

On Jun 12, 3:35 pm, Chris <[e-mail]:

Of course, just mentioning those issues and where they come
from may be viewed as within ?++ realm, and therefore on
topic here...

to make sure people are not confused: my question is not platform
specific. Nearly any platform can load libraries, invoke function
calls on those, etc. Let it be Windows with LoadLibrary or Linux with
dlopen, I don't care. My question is more a design problem I encounter
on how to design a plugin system.

Generally: I have a base-system and plugins. The base-system loads
plugings. The plugins need some functionality that lies in the base-
system. Can it be done this way? Any cleaner ideas?
How is this done in other projects that allow addons/plugins?
Obviously the addons in Mozilla Thunderbird access the base-system,
too. So there is a circluar access.

There are ways under Windows, and ways under Unix, but they are
completely different. You'll have to ask in the appropriate
group for each system you're interested in.

By the way, I found a document on open-std.org that describes
ideas about a plugin system in the C++ language coming from
the "Modules & Libraries" subgroup which works in the "C++
Modules" working group.

There has been on-going work on a module system in C++, which
would also support plug-ins. For the moment, I think, it is
just that: on-going work, and I don't think it will make it into
the next version of the standard. There are also people
concerned with dynamic loading in particular, and they may have
a stop-gap measure for that, which might make it into the next
standard.

--
James Kanze (GABI Software, from CAI) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]