A library loaded via LOAD_LIBRARY_AS_DATAFILE (or similar flags) doesn't get to play in any reindeer module games
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_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
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
EnumResourceTypes. Note that this indirectly includes functions like
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.