Juan Lang wrote:
--- Robert Shearman R.J.Shearman@warwick.ac.uk wrote:
CryptGetOIDFunctionAddress is kind of like GetProcAddress and so all of the real work is done by CertDllOpenStoreProv which is provided by the certificate provider.
<snip> > CertOpenStore is just a wrapper for > CryptGetOIDFunctionAddress("CertDllOpenStoreProv" > ...) and the real work is > done elsewhere.
I couldn't find any evidence that this is the case for the built-in providers (file, reg, in-memory, collection) on my Win2k system. When I search through the registry, the only CertDllOpenStoreProv entry I find is for an LDAP provider.
Unless you know which DLLs implement the built-in providers, I'm still assuming crypt32 implements them itself.
Yes, I assume that is the case since it doesn't appear to load any other DLLs when using the built-in providers mentioned.
As far as why I'd want to do it this way, I'm assuming the most common usage is of the system provider, which is really just a reg provider with the root key predefined. That's where I'd like to start.
Ok, but build a nice expandable framework and implementing the others should be relatively easy and could be taken on by others.
Rob