The LoadLibrary call comes from the implementation of DelayLoad ;-).
------------x8----------- http://www.microsoft.com/MSJ/1298/win32/win321298.htm
When the application runs, a call to a delay-loaded function actually calls the __delayLoadHelper function instead. This function references the special table I mentioned previously, and knows to call LoadLibrary followed by GetProcAddress. Once the address of the delay-loaded function is obtained, __delayLoadHelper fixes up calls to this function so that future calls go directly to the delay-loaded function. Note that other functions in the same DLL will still have to be fixed up the first time you call them. Also, you can specify the /DelayLoad linker switch multiple times, once for every DLL that you want to delay-load. ------------x8-----------
juergen
Jon Griffiths jon_p_griffiths@yahoo.com schrieb:
Hi,
The following (shortened) trace from native SHLWAPI v6 shows that StrRetToBufA is implemented using LoadLibrary/GetProcAddress to call CoTaskMemFree, even though ole32 is imported by this version.
08073b00:CALL xpshlwapi.790: StrRetToBufA(<unknown, check return>08073b00 08073b00:Call kernel32.LoadLibraryA(70bf2c30 "ole32.dll") ret=70c29f2a 08073b00:Ret kernel32.LoadLibraryA() retval=40a99000 ret=70c29f2a 08073b00:Call kernel32.GetProcAddress(40a99000,70c2a412 "CoTaskMemFree") ret=70c2a027 08073b00:Call ole32.CoTaskMemFree(403979e0) ret=70bfa1e2 08073b00:Ret ole32.CoTaskMemFree() retval=00000001 ret=70bfa1e2 08073b00:RET xpshlwapi.790: StrRetToBufA(405c6c3c,00000000,405c6d4c,00000100) retval = 00000000 ret=4001d283
If you still want to link directly in this case, ignore the patch "SHLWAPI ole32" and apply the one below instead. This one just removes winreg.h from shlwapi_main.c.
Cheers, Jon