c - How do I correctly use CoInitialize() and CoInitializeSecurity() as if I didn't call the latter so I can use IGlobalOptions? -

my ui provided in dll calls coinitialize() can use common item dialog, shell open folder dialog. , other new vista-only stuff may require com (i don't know of/don't use others yet). dll provide ui automation interface custom control (my table control questions past, i've decided move ui automation).

i don't want com's "helpful" exception handling; want exceptions in dll bubble through dll can debugged. however, the documentation iglobaloptions says need call coinitializesecurity() beforehand.

i have 2 questions:

1. do call coinitializesecurity() instead of or in addition coinitialize()? if in addition to, call before or after?

2. what invocation if wanted com act if didn't call coinitializesecurity() @ all? after reading msdn know of parameters should be, i'm not sure of them.

   coinitializesecurity(     null,     -1,    // or default 0 instead?     /* can null? (the error returns table on msdn implies can...) if not, should specify? */,     null,     rpc_c_authn_level_default,     /* should be? msdn says rpc_c_imp_level_default isn't allowed */,     /* can null? if not, should specify? */,     /* should be? msdn says eoac_default isn't allowed */,     null); 

   or wrong both security-wise , defaults-wise , there's better option?

or should not bother doing of since dll?

thanks.

ps: i'm assuming library doesn't contain actual main() code.

my ui provided in dll calls coinitialize()...

i hope you're doing in own thread, otherwise you're asking trouble.

1. do call coinitializesecurity()...

don't in library, it's process-wide call, might done application or when cross-apartment marshaling happens first time.

2. what invocation be...

i'd this it, if no registry information found. quote:

coinitializesecurity(null, -1, null, null,      rpc_c_authn_level_default, rpc_c_imp_level_impersonate,      null, eoac_none, null); 

or wrong both security-wise , defaults-wise , there's better option?

there better options.

one return constructed hresult , store actual error description in 1 of dll's globals, perhaps using thread-local storage.

if you're using atl, may use such hresult , end using same information you'd feed ccomcoclass::error method, objects use template inheritance.

or use atl's error handling, might enough since can breakpoint own code anyway.

or should not bother doing of since dll?

it depends on thread ownership. if own thread happens, it's ok; if not, it's wrong.

but consider alternatives ones suggested.