You're pretty much right. I tried to create *very* simple HelloWorld-type type library with it and and it reported me bunch of "stub!" messages and crashed. I also found a bug in implementation of ITypeLib2_fnGetTypeInfoOfGuid (in fact both implementations, the one in typelib.c and the second in typelib2.c). It should reference the typelib it's called on. This ensures that later call ITypeInfo_GetContainingTypeLib will not return bogus pointer if the original caller already released the TypeLib. See the attached test. If any COM hacker around can fix it, it would be nice.
It's not a bug. It's a difference between Wine's and native Windows implementation. When you run the attached test with the builtin version, you'll get: ref = 2 ref = 3 ITypeLib has a reference to the linked list of ITypeInfo. Functions GetTypeInfo and GetTypeInfoOfGuid search this list, call ITypeInfo::AddRef and returns the reference to ITypeInfo. ITypeInfo is destroyed when ITypeLib is destroyed (it means that each other ITypeInfos are destroyed too). Running this test with native Windows dll, results are: ref = 1 ref = 2 While Wine creates ITypeInfo interfaces when creating ITypeLib, native Windows probably create ITypeInfo "on call" when GetTypeInfoOfGuid is called for the first time. ITypeInfo can be deleted in this way while ITypeLib exists, while, in Wine, ITypeInfo has to be deleted together with ITypeLib.
I don't thik it Wine's bug. Applications don't depend on this stuff and Wine's ref handling is correct.
Jacek