Another way is the addref the type library when the ITypeInfo wherever a ITypeInfo interface is initially created (like in GetTypeInfoOfGuid) but I think this is more dangerous, since then you have to have some way for this refcount to go away, and ITypeInfo_Release() doesn't know who created it, just that it was created. If you are careful enough to always put an addref on the library when you create a new ITypeInfo pointer (GetTypeInfoOfGuid, GetTypeInfo, IDispatch::GetTypeInfo, etc.) but this seems like a unwieldy task to guarantee that the code is right in all of these places. It's much easier to make the ITypeInfo_AddRef() and ITypeInfo_Release() call ITypeLib_AddRef() and ITypeLib_Release() on the containing ITypeLib implementation when appropriate.
Yes, this is true. I hadn't considered that, it would be better to put the TypeLib addref in the TypeInfo addref. This feels a bit odd though, it would lead to the TypeLib having a reference count that was "too high" (though I suppose it doesn't really matter) if the receiver did their own AddRef on the TypeInfo, as the refs would propogate up. Still, the actual value of the refcount doesn't matter.
As far as C++ stuff vs. C stuff, in essence the pointer to the data structure (including the VMT) is simply a C++ style class without the C++, and with some special requirements... You can just replace my p->method() with OBJECT_method(p) if you like to make it look like what I've seen from wine. I'm still pretty new to the wine source, so it may not be like this everywhere, I just don't have the time to look.
True, what I meant was that there is no object constructor, unless you count the code where the struct is allocated and appended to the end of the linked list.
thanks -mike