crypt32: implement CryptSIPLoad (try 5)

Juan Lang juan_lang at yahoo.com
Fri Jun 1 09:47:46 CDT 2007


> I think it's worth figuring out why native does it like this.

Believe me, I've been trying to.  I'm only inferring that it should be
loaded because using native wintrust calls CryptSIPLoad, and my
implementation makes it continue on to call other functions that seem
reasonable in that context.

I don't know what tests I can write to show that I should not pass the
DLL's function pointers directly back to the caller.  That might make
sense if crypt32 were to try to unload unused function pointers
periodically, since the API doesn't provide an unload function - but that
seems overly complicated, and I unload them at DLL unload time instead.

If you have suggestions on tests I can write, I'm all ears.

> Also the dll loading part of the patch is quite confusing, hopefully
> doing it closer to the native way would help make it clearer.

The complication comes from the fact that the registry allows one to have
a separate DLL for each function in a SIP, but CryptAddSIPProvider does
not.  I therefore fail if the DLL names are different.  This allows me to
use an HMODULE as the hSIP member of a SIP_DISPATCH_INFO, rather than
invent some more complicated scheme.

I can add more comments to try to explain that if you like.
--Juan


 
____________________________________________________________________________________
Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front



More information about the wine-devel mailing list