ole32: questions about the COINIT flags
billmedland at mercuryspeed.com
Tue Jan 11 08:33:45 CST 2005
On January 11, 2005 01:59 am, Paul Vriens wrote:
> I was looking through some MSDN doc:
> there it's stated that:
> If neither concurrency model is specified by the dwCoInit parameter, the
> default is COINIT_MULTITHREADED.
> Does this mean we should change the way we interpret these flags (in
> compobj.c for example) because COINIT_MULTITHREADED equals 0 (which is a
> bit strange value for a flag)?
> The native QUARTZ.DDL calls CoInitializeEx with a COINIT of 4 which
> effectively has the COINIT_DISABLE_OLE1DDE and the COINIT_MULTITHREADED
> flags set.
> Shouldn't we have a check for COINIT_APARTMENTTHREADED and if this flag
> is not set we have to assume COINIT_MULTITHREADED? Especially because
> both these flags cannot be set at the same time (see mentioned MSDN
I've noticed Microsoft do this with several of their bitsets. What it, of
course, means is that COINIT_MULTITHREADED is actually "the lack of anything
conflicting". Currently that means "not COINIT_APARTMENTTHREADED". However
in the future they could add another "threading" flag and it would have to be
"not COINIT_APARTMENTTHREADED and not COINIT_SOMENEWTHREADED"
So then it comes down to semantics.
I did wonder about whether to specify it as "not apartment threaded" but the
structure of the test is consistant even though it is not optimal.
Basically it all has to become so complicated because of Microsoft's decision
to give a name to a lack of flag. I was about to say "ill-considered" but it
isn't. It is specified for users of the API rather than for people rewriting
Windows. It allows the users to specify the threading model explicitly in
the code, even though doing so does not actually do anything.
In restrospect I think you are probably right that in the code we ought to do
that translation and add a comment. Then we can simply continue with a
standard bit test.
mailto:billmedland at mercuryspeed.com
More information about the wine-devel