On January 11, 2005 01:59 am, Paul Vriens wrote:
Hi,
I was looking through some MSDN doc:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/cm f_a2c_5iyg.asp
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 doc).
(Evolving thoughts)
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.
Cheers,
Paul.