DLL memory space - simple question (I hope)

[CogInMachine]

Just about to embark on my first DLL based project and was wondering whether the following pseudocode is valid.....

LoadLibrary (moduleA)
GetProcAddress(moduleAmisc)
LoadLibrary (moduleB)
GetProcAddress(moduleBmisc)
LoadLibrary (moduleC)
GetProcAddress(moduleCmisc)
moduleAmisc(moduleBmisc)
moduleBmisc(moduleCmisc)

i.e. can I pass the proc addresses between loaded DLL's. The reason I ask is the remark in MSDN for GetProcAddress talks about module handles not being inheritable. I'm hoping that really just means the handle and not the actual function pointer.

Can someone just give me a nod or shake before I embark on completely the wrong design.

Thanks in advance.

[jim mcnamara]

As long as you are dealing with dllExport type functions, it will work - a 'standard' dll that exports functions like

HRESULT * myfunc(char *t);

If you go into the dependancy walker, you'll find nearly every dll in the Windows core code invoking each other.

When you derive classes, it doesn't work. I wish it would.

[parksie]

HRESULT * myfunc(char *t);

You what? As long as they're __stdcall/WINAPI/CALLBACK they can be invoked. The problem with classes isn't actually much of a problem other than it would take a lot of effort to extract the mangled function names and use them. If you put the class into a DLL and use the import library then it works with VC++ - not sure how Borland does this, but for VC use "__declspec(dllexport)" as a modifier on your class definition. It works for deriving classes as well, as long as the parent class is also in the SAME DLL.