Shachar Shemesh <[EMAIL PROTECTED]> writes:I'm a bit sketchy on details myself.
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?
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/
