Stdole32.tlb (was: Installshield 6 crash: ole trouble)

Robert Shearman R.J.Shearman at warwick.ac.uk
Tue Jan 21 20:22:21 CST 2003


> -----Original Message-----
> From: Ove Kaaven [mailto:ovehk at ping.uio.no]
> Sent: 22 January 2003 01:20
> To: Robert Shearman
> Cc: wine-devel at 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





More information about the wine-devel mailing list