unicows update and PE memory format

[Shachar Shemesh]

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.

-- 
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/