If you load a library with the
LOAD_ 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_,
LOAD_,
or
LOAD_
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.