working together on stdole.tlb and a end to dcom9x

[Jacek Caban]

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 865 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20040831/82804112/main.c