Juan Lang wrote:
>
> --- Robert Shearman <[EMAIL PROTECTED]>
> 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
