从应用程序公开DLL的API

Question

I am developing a plugin system for an application. The idea is to load some functions from plugins (loaded as DLLs) and use those functions in our scripting language hosted in app. I have to expose an API for the DLLs for them to interact with the app. The API may change overtime and the older DLLs should not be invalidated. Please give me some leads to read up on or please suggest ideas. Thanks.

Duminda

Answer 1

A simple Solution for exposing your API to the plugins is to have another "core"-Library exposing the API and to link your plugins against it. This would be quite natural to the plugin developers.

About API-Changes: The public API must not be changed, but can only be extended, eg added to. There is no way to change an API without breaking clients.

Here is a Link about evolving APIs without breaking Clients. It is Java but most does also apply to C++. http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs

Be sure to also change the API in a binary compatible way. C is easier in this regards than C++, so think about using C as your public API. In C++ the PIMPL-Idiom helps, but one still cannot add new virtual methods.

Answer 2

The 'industry standard' way is to make use of SWIG (Simplified Wrapper and interface Generator) which takes your C/C++ code and creates 'high-level' wrapper classes so your script languages can access your C/C++ code very easily.

SWIG is also free, for commercial aps too.

SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code.

Answer 3

Here are some ideas:

• Make the API fully compatible with C. No classes, no STL types, all functions declared extern "C" .
• For versioning, embed the API version number in the function and struct names. Once a version has been released, the function signatures and type definitions can not be changed without the risk of breaking backward compatibility.
• For convenience, you could provide a set of macros that map a function-name-without-version-number to a versioned function name. When the macros are updated for a new version, this will not break compatibility with older versions, but it will make the client code easier to read.

Answer 4

COM fits perfectly for what you require. It is language independent and the dlls can be loaded by your application at runtime. Implementing ActiveX for your components makesthem sutatible for scripting too.
http://msdn.microsoft.com/en-us/library/ee663262(v=VS.85).aspx