@Buddy said in Inversion of Control with plugins?:
@Tsaukpaetra said in Inversion of Control with plugins?:
So, in this case, you're to include a header file that includes a struct that holds pointers to functions, which the loading executable (in this case HexChat) provides the plugin by calling a specific function in the plugin and providing it that handle to the struct.
I'm interested to know how you parsed the original post to mean something other than that:
@Tsaukpaetra program A has plugin compatibility. so any DLLs in a particular folder, including DLL B, get loaded at runtime and a particular exported symbol is called. This is an inverse of how DLLs are supposed to work; the program provides the library functions to the DLL instead of the other way around. This is fine on non-Windows systems, because externally-defined functions can be referenced even if you don't specify the DLL name as long as the function exists at runtime. Windows however does not have an 'amorphous blob' model of functions, and requires that you say what DLL each function comes from. This means that this plugin compatibility model is impossible in Windows.
Unless of course you pass a struct to that particular exported symbol containing all your library function pointers. Which is the solution I'm currently running with.
Was it the ranty interjection that threw you? If we cut that out we get
@Tsaukpaetra program A has plugin compatibility. so any DLLs in a particular folder, including DLL B, get loaded at runtime and a particular exported symbol is called.
you pass a struct to that particular exported symbol containing all your library function pointers. Which is the solution I'm currently running with.
which to me seems to be saying the same thing as your summary above.
I don't understand the question?
