PocketMatrix

I've got a DLL from which I wish to access routines residing in the process that loaded the DLL. So in other words, an application has a routine foo that I wish to be able to call from within a DLL that the application loaded. Note that I aready use pointers to functions to accomplish this. However I would like something more streamlined, like the ease of calling into DLLs normally.

It seems this should be possible because a DLL is loaded into the parent process' calling space. Also when statically linking DLLs a dummy LIB is used as a placeholder for the routines that are resolved dynamically when the application is loaded. It appears the only purpose in this is to keep the linker happy. Perhaps it would be possible to do something like that in reverse.

It should be possible to LoadLibrary and GetProcAddress the parent exe from the dll. However I'm right back at pointers-to-functions, so that is no better than my current solution.

One last thing is that I have full control over both the app and the dll, so I can make whatever modifications are needed to the application itself.

Any suggestions?

Thanks.

Dan East

You won't like it, but COM is probably the best solution. However I'm not familiar with COM/ActiveX on WinCE. Only the PC platform.

You can create your own COM system. Flipcode.com has had a few COTD submissions that have essentially done this.

COM is way overkill for this, and even if you did go through the headaches of us doing it this way it would still be calling through a function pointer. COM might be worthwhile if you're going to market your application as some reusable module as a COM server or something. Doesn't sound like Dan is doing that though.

Dan, I don't think what you want to do is possible, but if it were you'd need to use LIB to create an export file (.exp) for your .exe, that you would then use to link with when you built the DLL. I don't think you can use LIB on exes, so this might not even be worth investigating.

If you could isolate the code from the exe that would be called by the DLL, and then put that code into another DLL, then the two DLLs can call routines in each other. In order to build them though you'll have to use export files to resolve the circular references. This process is explained in the MSDN docs.

I don't know how much you can get away with in DllMain (there are strict restrictions on which APIs you can call in DllMain), but you might be able to call a few APIs to get the function address from the exe and initialize a function pointer residing in the DLL. The DLL would still have to call through a pointer, but your exe wouldn't have to do anything special - just load the DLL.

All of this is really too much trouble in my book unless you're trying to do this for some copy protection scheme. I'd just have the exe call a DLLInit() exported by the DLL, and pass over a table of function pointers to routines that the DLL will call back into.

Kzinti: Would you have to include your export file with the release? Not fully understanding what the .exp files contain that the .exes and .dlls don't. I'm guessing symbol to friendly name type info.

well using export files is almost identical to func pointers... at least in my opinion.

I don't know really... I am not the expert either.

Personly win32 and winCE and Win* sucks. you should check out the cool prelinking stuff you can do on linux

well I think that a few shared headers and or some cool macros might help too.

yes and more but that is off topic...

you can export from an exec (I am currently writing a program at my work that does just this)

you have be sure to specify correct target types and compile with the right compile flags.

Now i confess i have not yet tried this on the eVC++ compiler but if it is anywhere nere VC++ 7.0 or 6.0 then it should work (note it works for me on those 2 and will later try a comile with borland's 5.5 compiler).

and just so you know: you can also make a DLL act like and exec (a little more trickery involved).

I wouldn't be able to give an easy and short explanation to the procedure that I use to accomplish this but I recomend passing a structure to the dll and then calling either pointers of function objects (note that you could also have the function obj. passed by ref and have a member variable take care of pointers) hey you could even override entries in a v-table if you wanted with those pointers .

Quantum,
there is no question that you can call a function by comunicating a pointer from an exe to the dll at runtime.
The question is, incorporate a function in your dll declared extern (__declspec (dllimport) or such). Export (__declspec (dllexport) or such) that function from the exe and just link the .lib to your dll.
Again, all that works for eVC at compile/link time without any errors. But it will not run on the PPC, bad executable format.