unicows update and PE memory format

[Shachar Shemesh]

Alexandre Julliard wrote:

>Shachar Shemesh <wine-devel at shemesh.biz> writes:
>
>  
>
>>It seems that I won't be able to use the forwarding inside the spec
>>file. I'm not sure exactly why that is, but I think the unicows.lib
>>link time library tries to load stuff by doing "GetModuleHandle", and
>>then fetching relative values from that place. Is there a plausable
>>assumption about PE memory layout? Is this something that Win32
>>properly defines? Do we have such a format for winelib dlls?
>>    
>>
>
>Yes, builtin dlls have a PE header, so this kind of thing is supposed
>to work. Could you please give us more details on what happens here?
>  
>
I'm a bit sketchy on details myself.

Basically, what I've done is to download the SDK that includes 
unicows.lib, and compile my own (very simple) program, and then try to 
figure out why that (very simple) program doesn't work.

<rant>
Microsoft's environment for their own developers seems to be in constant 
deterioration. It is unbelievable what they expect the developers that 
give them their power to go through. I can't believe I did that for a 
living for over four years!

Linking with unicows.lib prevents Visual Studio 6 from linking your 
program in Debug mode. That's right - you had better not have bugs in 
your programs. If you must have bugs (you whiny little thing), make sure 
these are bugs that are reproduceable on an NT variant, and you can 
simply compile the debug version without unicows. All of that for an 
infrastructure that is so buggy and unstable that their loader refuses 
to load unicows.dll unless it's located in the same directory as the 
program (i.e. - not shared with other applications), so that upgrading 
another program's unicows.dll will not break this one. Amazing!
</rant>

<recap>
To recap my previous whining posts on this list - I tried the spec 
forwarding to implement unicows.dll. That simply didn't work. As the 
forwarding mechanism doesn't have any debug outputs (in fact - I have 
not even been able to FIND it), I was not able to tell anything about 
the situation other than to say that the functions that were supposed to 
be called, were not.

I then tried to implement explictly forwarding functions. These are 
simple functiont that (print a trace and) call the original funciton in 
the original DLL. This, suprisingly, DID work. However, this failed for 
GetProcAddress. It appears that the spec mechanism needs the original 
GetProcAddress, and trying to implement another function with that name 
creates link errors.
</recap>

Taking the lead from you guys, I tried to find out why forwarding did 
not work. To that end I created a unicows.dll.so file that tries to 
forward just DrawTextW, GetCPInfo, GetEnvironmentStringsW, 
GetStringTypeW, LCMapStringW and LoadStringW. By stubbing out 
everything, I could ascertain that these are all that are required for 
my test program.

Not only would my program not run, but I have found out that, somehow, 
unicows.lib failes to get the proper pointers for the functions. This 
does not happen when these very same functions are either stubbed or 
implemented in unicows.dll.so. I am now in the process of trying to 
figure out why and how.

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. At point I am lost. I don't know 
what GetModuleHandle returns on Windows, and I don't know whether we 
return anything that is, in any way, meaningful outside it's use as a 
pure handle.

If anyone can help me shed more light on this, I would be most grateful.

                Shachar

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