http://bugs.winehq.org/show_bug.cgi?id=7892
------- Additional Comments From focht@gmx.net 2007-03-05 04:34 ------- Hello,
good to see some progress on the wintrust issue :) Just a few annotiations to your inital provider loader impl (saw a patch on mailing list)
You load providers but leak the modules (handles) stating "no way to unload providers". That may be api-wise true but as good developer there is always another way.
There exist scenarios where each provider function on specific action guid can be implemented by a separate provider and where all provider functions are implemented by one provider (e.g. wintrust).
Manage the data in a structure which holds action guid ( = key), provider function pointers and provider dll handles ("max" case = all stuff implemented by same provider). Make a linked list with this, search criteria is the action guid. Use some lock to guard list (e.g. critical section) and prevent race issues.
On first time WintrustLoadFunctionPointers() you just build up the managed list "cache" from registry. Create new entries and fill the data, action guid, module handles (LoadLibrary), function pointers (GetProcAddress). Beware of the "wintrust does it all by itself" case (compare name "wintrust.dll"). In that case just store the HINSTANCE supplied by wintrust DllMain and function pointers to internal handlers.
On subsequent WintrustLoadFunctionPointers() calls, you just search the list for action guid and return the list entry data, e.g. assign the function pointers to CRYPT_PROVIDER_FUNCTIONS struct.
For a good design the data structures must be freed. Appropriate place would be DllMain( DLL_PROCESS_DETACH)
Regards