Question

I’m working on a program with a plugin-based architecture. All the plugins are DLLs, and some of them can have dependencies on other plugin DLLs. I’d like to be able to do the following:

• At program startup time, scan the plugins folder.
• For each plugin found, check if that plugin is already loaded. (Which it could be, if a previously-loaded plugin caused it to be loaded as a dependency).
• If not, load it.

The first and third steps are trivial, but how do I do the second? Is there a winapi call that, given a filename of a DLL, will tell me if that DLL is currently loaded into the current process? (Or perhaps one that takes a filename and a process handle?)

Please, no answers saying “just load it anyway.” I know that will work. I’m trying to avoid that.

Answer 1

GetModuleHandle API gives you HMODULE for the loaded DLL, or otherwise NULL if it is not loaded. Note that you can omit path, if desired. You can also get HMODULE for a name without path, and then GetModuleFileName using this handle in order to obtain full path to compare to what you expect.

If lpModuleName does not include a path and there is more than one
loaded module with the same base name and extension, you cannot
predict which module handle will be returned. To work around this
problem, you could specify a path, use side-by-side assemblies, or use
GetModuleHandleEx to specify a memory location rather than a DLL name.

The GetModuleHandle function returns a handle to a mapped module
without incrementing its reference count. However, if this handle is
passed to the FreeLibrary function, the reference count of the mapped
module will be decremented. Therefore, do not pass a handle returned
by GetModuleHandle to the FreeLibrary function. Doing so can cause a
DLL module to be unmapped prematurely.

Enumerating loaded libraries in the process with EnumProcessModules is also possible, but might be a bit of an overkill for the task you described. You might be good with these plain and simple functions without PSAPI.