-----Original Message----- From: Ove Kaaven [mailto:ovehk@ping.uio.no] Sent: 22 January 2003 01:20 To: Robert Shearman Cc: wine-devel@winehq.com Subject: Re: Stdole32.tlb (was: Installshield 6 crash: ole trouble)
On Tue, 21 Jan 2003, Robert Shearman wrote:
Attached (now) is the IDL file (really an ODL file) used to create stdole32.tlb
Why do it this way? There are surely going to be more types than that in the stdole32 file, or?
No, that's it. There are a few more in stdole2.tlb, but only a couple that are in idl files
And what's wrong with importing lots of structures, if unused typedefs aren't stored in the type library?
The main problem is that the typelibs import all kinds of stuff. Stdole2.tlb imports declarations from guiddef.h, oaidl.idl, unknwn.idl, ocidl.idl, olectl.h, plus some functions and interfaces that are not in any other file. Also, the IFont interface has been slightly modified in the type lib which might break an app if it were to use our ocidl.idl version of it. Is there any point in cluttering our typelib?
If the problem is that mktyplib is inflexible, use midl instead. Then you can just import oaidl.idl and be done with it, almost no future maintenance needed.
If you change anything in a type library you are supposed change the version number (which is what Microsoft has done transitioning from stdole32.tlb->stdole2.tlb). In short, I'd rather not take the risk when this way seems so straightforward. If or when Microsoft release version 3 of the standard type library, it will have to be examined for new material (like version 2 has) that is not in any .idl file anyway. At least this would put up a definite error that it needs attention rather than waiting for a corner case for an error to occur. It's not that mktyplib is inflexible, it's that it does the job with the minimum amount of fuss. In fact midl is more inflexible in that you cannot turn off its inclusion of oaidl.idl
Where should I put such a file?
I'd go for dlls/oleaut32. Standard ole32 has no need for typelibs, they're a feature of oleaut32.
I'll wait a bit longer for opinions from a few more people, although your logic about type libs being an oleaut32 feature seems right to me.
Rob