- Forum
- Windows Programming
- Have my DLL load another DLL that is loa
Have my DLL load another DLL that is loaded in the calling process
I have an interesting situation where I have an application X that dynamically loads any DLLs [A, B, C, ...] in a subfolder. Both X and the DLLs need to use the same DLL Y in the same folder as X. Y needs to be (preferably) statically linked to X and the other DLLs, but it has to be the same instance.
What is the best way to handle this? I control the sources of X and the DLLs it loads, but not Y.
What is the best way to handle this? I control the sources of X and the DLLs it loads, but not Y.
- CreateToolhelp32Snapshot(...): Use this to get a "Snap Shot" of the modules running in the target process by passing it TH32CS_SNAPMODULE and the Process ID of the target.
http://msdn.microsoft.com/en-us/library/ms682489(VS.85).aspx
- MODULEENTRY32: A structure that holds information about a module, module is another name for a DLL. http://msdn.microsoft.com/en-us/library/ms684225(VS.85).aspx
- Module32First(...): Grabs the first module loaded into the process designated in the snapshot. http://msdn.microsoft.com/en-us/library/ms682489(VS.85).aspx
- Module32Next(...): Use this in a loop for every other module. http://msdn.microsoft.com/en-us/library/ms684221(VS.85).aspx
The MODULEENTRY32 struct has a memeber named szExePath that will give you the directory of the DLL, pass this to LoadLibrary(...) [ http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx ] and you should be all set. All you would need is to know what DLL you are looking for, or alternativley you may be able to load them all.
http://msdn.microsoft.com/en-us/library/ms682489(VS.85).aspx
- MODULEENTRY32: A structure that holds information about a module, module is another name for a DLL. http://msdn.microsoft.com/en-us/library/ms684225(VS.85).aspx
- Module32First(...): Grabs the first module loaded into the process designated in the snapshot. http://msdn.microsoft.com/en-us/library/ms682489(VS.85).aspx
- Module32Next(...): Use this in a loop for every other module. http://msdn.microsoft.com/en-us/library/ms684221(VS.85).aspx
The MODULEENTRY32 struct has a memeber named szExePath that will give you the directory of the DLL, pass this to LoadLibrary(...) [ http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx ] and you should be all set. All you would need is to know what DLL you are looking for, or alternativley you may be able to load them all.
I would just use LoadLibrary (with FindfirstFile, etc) to load the files in your subfolder (A, B, C, ...). As Y is in the app directory, it should be found automatically. (Failing that, use SetCurrentDirectory to set the directory). A pretty standard approach for handling plug-ins and the like.
Andy
Andy
@Computergeek01: thanks! I'll look into those and try to figure out how to piece it in with this Library.
@andywestken: I am already doing that, I was more interested in getting A, B, C... to have toe same Y DLL instance as X. ;)
@andywestken: I am already doing that, I was more interested in getting A, B, C... to have toe same Y DLL instance as X. ;)
Sorry - my brain didn't register the "be the same instance"...
Can you provide A, B, C... with a callback and have the app talk to Y on their behalf. That way you don't have to bend any rules
If A, B, C... only need to call C-style functions exported by Y, you could provide the with an array of function pointers (inspired by Winsock SPI's NSPStartup routine's LPNSP_ROUTINE parameter)
Can you provide A, B, C... with a callback and have the app talk to Y on their behalf. That way you don't have to bend any rules
If A, B, C... only need to call C-style functions exported by Y, you could provide the with an array of function pointers (inspired by Winsock SPI's NSPStartup routine's LPNSP_ROUTINE parameter)
Topic archived. No new replies allowed.