Ways to provide a framework for DLLs to depend on each other and expose functionality?

Question

Essentially, how to write a plugin system, where each plugin is a DLL. (Or is there a better way of a plugin system where each plugin is written natively?)

Suppose that each DLL offers some functionality available to other plugins. If plugin A does provides FuncA and plugin B wants FuncA, how should dependency be managed? How should plugins be identified (GUIDS?) How should be DLLs loaded? How should the function be called?

I'm not familiar with DLLs, and I am asking on the scope of Windows API calls that would enable a sane way to achieve this.

Answer 1

Have your DLL export a function returning meta information about the plugin itself, i.e. version, dependencies, exported features etc. When walking over a plugin directory, dynamically load the DLLs in that directory via LoadLibrary and check if they export a symbol that matches your query function (via GetProcAddress). If so, load the DLL, try to query the plugin and get some meaningful information out of it.

Be sure to employ some kind of version management for your plugin system, to accommodate for API changes. Windows itself does it by passing version information (sometimes in the form of struct sizes) to certain functions.

As for dependencies, build a dependency graph. If you detect a circular dependency (for example using Floyd's algorithm), ask the user what to do, i.e. what plugin to disable. If there are no cycles in your graph, you can traverse the (directed) graph to determine a load order for plugins.

Edit, as per your question in the comment:

How would DLL1 call a function that it expects in DLL2? I'm guessing the plugin framework would need to provide something like GetPluginFuncAddr(plugin_ID, func_ID) [...]

Yes, you could expose a function like this, or provide access to some sort of globally accessible registry. Again, I would advise to include versioning, so plugins can optionally ask for a specific version of a function that is known to work, allowing updates without breaking existing plugins.

how should plugins and functions be identified? Strings vs GUIDs, or is this a trivial thing since a plugin should just provide headers?

See, if you are developing a plugin using features/functions of another plugin, you probably don't want to do the plugin loading, version/compatiblity checking and error handling each time you write a plugin, instead, you'd probably expect to link against a stub that does the boilerplate stuff for you. As for how you implement plugin and function identification really is up to you. GUIDs sure are not a bad idea when it comes to identifying a plugin (together with a user-friendly, human readable name and description), apart from that, you can offer a list/tree of different feature versions, i.e.

UsefulPlugin@{1e2f253e-a3b2-4617-90f2-f323577ffddf}
|
\__ FunctionA
| |
| \_ v1.1
| |
| \_ v1.3
|
\__ FunctionB
  |
  \_ v1.0

...which clients can query for needed information. If you want, you can even offer a reflection-kind of information, providing information about parameters, return values and the like of your function.