unicows update and PE memory format
wine-devel at shemesh.biz
Tue Nov 25 13:26:42 CST 2003
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.
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
More information about the wine-devel