Calling functions in an executable or accessing its global variables from a DLL
-
I was wondering if anyone knew of a straight forward way of calling (non-exported) functions in an executable from a DLL. We are building a, for lack of a better name, private plug-in system that will grant the plug-in access to all of a processes internals, without having to export the hundreds of methods and classes we have.
cheers, -B
-
I was wondering if anyone knew of a straight forward way of calling (non-exported) functions in an executable from a DLL. We are building a, for lack of a better name, private plug-in system that will grant the plug-in access to all of a processes internals, without having to export the hundreds of methods and classes we have.
cheers, -B
oohhh .. thats a hard one. Unless your executable exposes some sort of API I think you'd have to resort to using injection/hooking from the dll (which I presume is in another process) to access the functions in the executable, even then ... Usually as Im sure you're painfully aware, a plugin system involves the executable 'discovering' its plugins, then possibly calling something within the plugin to say 'what do you expose/do', or has a narrowly defined interface, not the other way around .. If it were me (and Ive been here before, and are about to venture in this space again), I would would have the exe expose its functions through an IPC or TCP/IP interface, presenting commands to a command interpreter built into the exe, but its hard to do that unless you build it from the ground up. My next app is going to have an inbuild mini-webserver in it for both input/output and control .. Maybe you can research injection/hooking, the microsoft library 'detours' for example to see if that can help ... the danger with these (well, one of the dangers), is that the usage is tightly bound to your internals/classes ... sorry, good luck [edit] .. if it were just a matter of exposing global variables for instance, I'd be using a shared memory implementation [/edit] 'g'
-
oohhh .. thats a hard one. Unless your executable exposes some sort of API I think you'd have to resort to using injection/hooking from the dll (which I presume is in another process) to access the functions in the executable, even then ... Usually as Im sure you're painfully aware, a plugin system involves the executable 'discovering' its plugins, then possibly calling something within the plugin to say 'what do you expose/do', or has a narrowly defined interface, not the other way around .. If it were me (and Ive been here before, and are about to venture in this space again), I would would have the exe expose its functions through an IPC or TCP/IP interface, presenting commands to a command interpreter built into the exe, but its hard to do that unless you build it from the ground up. My next app is going to have an inbuild mini-webserver in it for both input/output and control .. Maybe you can research injection/hooking, the microsoft library 'detours' for example to see if that can help ... the danger with these (well, one of the dangers), is that the usage is tightly bound to your internals/classes ... sorry, good luck [edit] .. if it were just a matter of exposing global variables for instance, I'd be using a shared memory implementation [/edit] 'g'
Thanks, I figured it'd be a tough one... just thought I'd ask :) One option I was already looking at was generating a map of all the function addresses and giving plug-in builders a stub to link with that would find the location of the function in the loaded executable, properly construct the stack for its calling convention, and then call it. Very harry. As for the API idea: we were planning on exporting a simple and well defined API for public plug-ins, but we would like to have private plug-ins have first-class access to all the symbols in the running process, which is the problem area. As for shared memory, I'd love to do that too, but it would require some time to track down all the globals we export, and I'm not sure I'm up to spending the next few days (years?) tolling though 20+ years of code to find all the interdependencies. So, although it's a great suggestion, I think this part needs to be automated, to be done at build time, such that any new globals will automatically be exported/shared. Also, I've little faith that the Linux/UNIX developers would appreciate me making them add extra dressing to their globals (and even if they loved the idea, if someone forgets once just before a release, then our users are out of luck if they want to access that object). I think we'll just scrap the idea of "private" plug-ins for now, and just define a basic public API. We already support SOAP, among other network based communications channels, so we may just expand the SOAP interface to allow for a greater range of hackery. Thanks for the input.
cheers, -B