i have a question about how to arrange linkage between a "framework"
executable and an extensible set of "applet"s in DLLs that plug into the
executable. whilst this is a cross-platform application, i think it can
be discussed in the context of windows as a starting (and, perhaps,
ending) point. please accept my apologies if i've posted to the wrong
group, and if you could redirect me i'd much appreciate it.

the main exe is an application for managing interactions between
"applets" which live in the dlls. the main exe offers communications
between the applets, and also certain services that the applets can make
use of. the question is, how to offer these services to the dlls. they
can be offered in at least three ways that i know of, as follows. (i)
offer them as exports from service.dll, which ships with the executable.
service.lib and service.h are offered so that applets can be built
against the service DLL. (ii) offer a dummy service.dll which holds only
stubs for these service functions, and at startup arrange global
variables in service.dll so that these stubs call up into the executable
(again, with service.h and service.lib). (iii) offer function pointers
as global variables in service.dll, and at startup initialise them to
point at functions that are, in fact, exported from the exe (again, with
service.h and service.lib).

the services offered require integration across the applets, so it is
not possible to do (i), i.e. to compute them entirely within a service
dll. the other two solutions work, but both have inelegance and
inefficiency (additional call per function call in ii, or additional
dereference step in iii).

so i wondered if it is possible (iv) to offer the API as just a
service.h header file (declarations), and have the dlls linked at
run-time by the loader to these functions (definitions) that are
actually exported *from the executable* (no service.lib). a service DLL
is unnecessary, reducing the complexity of the solution, but the main
point is that the functions in question are called directly, rather than
through indirection or stubs.

that is, something like:

DLL <====> EXE <====> DLL

where both the exe can call the dll's exports, and vice versa.

the DLLs will be written in C or C++, depending on the taste of the
client. the exe is written in C++. all exports would be with C linkage,

i suppose that if (iv) is not possible, i'm also interested in which of
(ii) or (iii) is usually used (or something else?) and why.

thanks in advance