How does getModuleHandle () work?

Question

I read <windows via c / C ++>, it describes the GetModuleHandle () API, as shown below:

When you call this function, you pass a null-terminated string that indicates the name of the executable or DLL file loaded into the address space of the calling process. If the system finds the specified executable or DLL name , GetModuleHandle returns the base address to which the executable or DLL file is loaded.

I wonder where the system is looking for a file name ? When I loaded some file into the process address space, is there any centralized table for storing the mapping of all the names of the downloaded files and their download addresses? If we do a string match search, is that a little low efficiency?

Thanks so much for your insigts.

Answer 1

The loaded module information is maintained as a linked list in the "PEB" process in a structure named PEB_LDR_DATA . If you get a PEB pointer, you can go through this list and get information like DLL name, base address, entry point, size, etc. Check out these pages:
http://msdn.microsoft.com/en-us/library/aa813708.aspx
http://www.codeproject.com/KB/threads/CmdLine.aspx

Answer 2

It looks in the internal data structure of the bootloader (the name of the Windows dynamic linker file).

GetModuleHandle only works for DLLs loaded into the current process. Whenever the loader loads the DLL into the process, it certainly supports a data structure that includes the module name. No need to visit the file system.

LdrInitializeThunk runs in user space to start the pull process in the DLL.

Answer 3

I need to confirm (see swatkat answer) that in my information, the implementation of GetModuleHandle() does indeed scan Wine and ReactOS (and this ). You will see the implementation of GetModuleHandle() . The developers of Wine and ReactOS parsed the Windows code and implemented their own code based on the results of the disassembly. Thus, the code does in most cases the same as the Windows code.

If you want, you can implement your own implementation of the GetModuleHandle() base only VirtualAllocEx() . See my old answer for more details. (If you still do not know that the handle returned by the GetModuleHandle() function is the address of the corresponding module in memory, so you just need to somehow find the dll in the memory of the current process).