If you load a library with the LOAD_LIBRARY_AS_DATAFILE
flag, then it isn’t really loaded in any normal sense. In fact, it’s kept completely off the books.
If you load a library with the LOAD_LIBRARY_AS_DATAFILE
, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE
, or LOAD_LIBRARY_AS_IMAGE_RESOURCE
flag (or any similar flag added in the future), then the library gets mapped into the process address space, but it is not a true module. Functions like GetModuleHandle
, GetModuleFileName
, EnumProcessModules
and CreateToolhelp32Snapshot
will not see the library, because it was never entered into the database of loaded modules.
These “load library as…” flags don’t actually load the library in any meaningful sense. They just take the file and map it into memory manually without updating any module tracking databases. This functionality was overloaded into the LoadLibraryEx
function, which in retrospect was probably not a good idea, because people expect LoadLibraryEx
to create true modules, but these flags create pseudo-modules, a term I made up just now.
It would have been less confusing in retrospect if the “load library as…” functionality were split into another function like LoadFileAsPseudoModule
. Okay, that’s a pretty awful name, but that’s not the point. The point is to put the functionality in some function that doesn’t have the word library in its name.
Okay, so now that we see that these pseudo-modules aren’t true modules, and they don’t participate in any reindeer module games. So what use are they?
Basically, the only thing you can do with a pseudo-module is access its resources with functions like FindResource
, LoadResource
, and EnumResourceTypes
. Note that this indirectly includes functions like LoadString
, and FormatMessage
which access resources behind the scenes.
So maybe a better name for the function would have been LoadFileForResources
, since that’s all the pseudo-module is good for.
0 comments