Rolf Kalbermatter wrote:
Now here's the puzzle - GetProcAddress is never called. Neither are these functions imported from the DLL in the PE header. In fact, unicows.dll does not even appear in the PE header (which makes sense - on NT you don't even want to install it). This means that unicows.lib manages to call GetProcAddress, without actually calling GetProcAddress.
Some tracing leads me to suspect (I have not done enough research to determine yet) that it accesses the PE header of kernel32 directly. It appears that unicows.dll enountered the exact same problem we have vis a vis GetProcAddress, and have happily hacked their way around it using direct memory access. What I see them do is call "GetModuleHandle" on "kernel32.dll", and then use the resulting handle as a struct/array pointer, and access offsets into it.
This is not exactly very nice but it is also not to surprising. The PE header is actually documented on MSDN including the import and export tables. GetModuleHandle actually also just returns the HMODULE which at least for Win32 is the same as the HINSTANCE returned by LoadLibrary. The difference is if I'm not mistaken, that GetModuleHandle will usually not try to load the module if it isn't already loaded, but for kernel32 you can safely assume that a process has it already loaded implicitedly or even explicitedly.
The problem is not that I cannot call GetProcAddress. The problem is that I cannot even define such a function. The moment I define a function called "GetProcAddress", I get link errors due to conflicts in the spec.c file.