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

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

essentially, how write plugin system, each plugin dll. (or there improve way of plugin scheme each plugin written natively?)

suppose each dll offers functionality available to other plugins. if plugin provides funca , plugin b wants funca, how should dependency managed? how should plugins identified (guids?) how should dlls loaded? how should function called?

i'm not familiar dlls, , asking on scope of windows api calls enable sane way accomplish this.

have dll export function returning meta info plugin itself, i.e. version, dependencies, exported features etc. when walking on plugin directory, dynamically load dlls in directory via loadlibrary , check if export symbol matches query function (via getprocaddress). if so, load dll, seek query plugin , meaningful info out of it.

be sure employ kind of version management plugin system, accommodate api changes. windows passing version info (sometimes in form of struct sizes) functions.

as dependencies, build dependency graph. if observe circular dependency (for illustration using floyd's algorithm), inquire user do, i.e. plugin disable. if there no cycles in graph, can traverse (directed) graph determine load order plugins.

edit, per question in comment:

how dll1 phone call function expects in dll2? i'm guessing plugin framework need provide getpluginfuncaddr(plugin_id, func_id) [...]

yes, expose function this, or provide access sort of globally accessible registry. again, advise include versioning, plugins can optionally inquire specific version of function known work, allowing updates without breaking existing plugins.

how should plugins , functions identified? strings vs guids, or trivial thing since plugin should provide headers?

see, if developing plugin using features/functions of plugin, don't want plugin loading, version/compatiblity checking , error handling each time write plugin, instead, you'd expect link against stub boilerplate stuff you. how implement plugin , function identification you. guids sure not bad thought when comes identifying plugin (together user-friendly, human readable name , description), apart that, can offer 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 needed information. if want, can offer reflection-kind of information, providing info parameters, homecoming values , of function.

windows api winapi dll plugins