Stdole32.tlb (was: Installshield 6 crash: ole trouble)
Date: Tue, 21 Jan 2003 16:49:19 +0100 From: Marcus Meissner <mm(a)lst.de> To: Sylvain Petreolle <spetreolle(a)yahoo.fr> Cc: Mike Hearn <m.hearn(a)signal.qinetiq.com>, Dan Kegel <dank(a)kegel.com>, Bobby Bingham <uhmmmm(a)ameritech.net>, wine-devel(a)winehq.com Subject: Re: Installshield 6 crash: ole trouble
On Tue, Jan 21, 2003 at 04:26:28PM +0100, Sylvain Petreolle wrote:
what are the missing functions that live in stdole2.tlb ? is someone trying to implement it ?
The TLB is a typelib file, which is compiled from a .IDL file.
Attached (now) is the IDL file (really an ODL file) used to create stdole32.tlb Where should I put such a file? Perhaps a new dlls/stdole directory?
So widl needs to generate it at one point.
Yes, for the moment I have used MS mktyplib Rob
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? And what's wrong with importing lots of structures, if unused typedefs aren't stored in the type library? 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.
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.
-----Original Message----- From: Ove Kaaven [mailto:ovehk(a)ping.uio.no] Sent: 22 January 2003 01:20 To: Robert Shearman Cc: wine-devel(a)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
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.
Huh? How that?
Is there any point in cluttering our typelib?
In my opinion our typelib should at least contain all of the stdole2/32.tlb stuff. If there are some more entries, it does not really matter I guess.
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.
Go ahead with what you consider best. My acceptance criteria would be basically 'InstallShield v6 still works' ;) Ciao, Marcus
participants (3)
-
Marcus Meissner -
Ove Kaaven -
Robert Shearman