Issues in typelib.c with installshield 7
Hi, today I've been trying to get an Installshield 7 installer going. I think I've seen reports from other people about having problems as well. The problems I've been having stem from the implementation of ITypeLib/ITypeInfo/etc in oleaut32. The first problem is as follows: Installshield has a TLB which contains a type hiererachy as follows: IDispatch : ISomething : : ISomething2 An instance of ISomething2 is created. Installshield attempts to look up a method which is only defined in ISomething. The lookup fails. This is because ISomething and ISomething2 inherit from IDispatch, and are marked as TKIND_DISPATCH in the typelib. However in the code, an upwards traversal of the type hierarchy is only done for the TKIND_INTERFACE. I've experimented with modifying the code so that it also does an upward traversal for TKIND_DISPATCH as well (as they are still interfaces which can inherit). It now finds the methods/values properly. (It still doesn't work as there are then reference count problems, but I'm looking into that.) However, can anyone confirm if my experimental modification is the correct behaviour? e.g. in ITypeInfo_fnGetIDsOfNames, I have changed it to if(This->TypeAttr.cImplTypes && (This->TypeAttr.typekind==TKIND_INTERFACE || This->TypeAttr.typekind==TKIND_DISPATCH)) {
On Sun, Dec 07, 2003 at 03:37:17PM +0000, Andrew de Quincey wrote:
Hi, today I've been trying to get an Installshield 7 installer going. I think I've seen reports from other people about having problems as well.
The problems I've been having stem from the implementation of ITypeLib/ITypeInfo/etc in oleaut32. The first problem is as follows:
Installshield has a TLB which contains a type hiererachy as follows: IDispatch : ISomething : : ISomething2
An instance of ISomething2 is created. Installshield attempts to look up a method which is only defined in ISomething. The lookup fails. This is because ISomething and ISomething2 inherit from IDispatch, and are marked as TKIND_DISPATCH in the typelib. However in the code, an upwards traversal of the type hierarchy is only done for the TKIND_INTERFACE.
I've experimented with modifying the code so that it also does an upward traversal for TKIND_DISPATCH as well (as they are still interfaces which can inherit). It now finds the methods/values properly. (It still doesn't work as there are then reference count problems, but I'm looking into that.)
However, can anyone confirm if my experimental modification is the correct behaviour?
e.g. in ITypeInfo_fnGetIDsOfNames, I have changed it to if(This->TypeAttr.cImplTypes && (This->TypeAttr.typekind==TKIND_INTERFACE || This->TypeAttr.typekind==TKIND_DISPATCH)) {
Do you have a sample installer for download? Ciao, Marcus
e.g. in ITypeInfo_fnGetIDsOfNames, I have changed it to if(This->TypeAttr.cImplTypes && (This->TypeAttr.typekind==TKIND_INTERFACE || This->TypeAttr.typekind==TKIND_DISPATCH)) {
Do you have a sample installer for download?
Bah, I can't find one thats (a) available easily (b) free, and (c) has the same problem. However, I AM writing you a sample winelib program which demonstrates the problem using the installshield typelib... I'll send it to you in a moment.
On Mon, Dec 08, 2003 at 10:39:54AM +0000, Andrew de Quincey wrote:
e.g. in ITypeInfo_fnGetIDsOfNames, I have changed it to if(This->TypeAttr.cImplTypes && (This->TypeAttr.typekind==TKIND_INTERFACE || This->TypeAttr.typekind==TKIND_DISPATCH)) {
Do you have a sample installer for download?
Bah, I can't find one thats (a) available easily (b) free, and (c) has the same problem.
However, I AM writing you a sample winelib program which demonstrates the problem using the installshield typelib... I'll send it to you in a moment.
I think the change is good. Please submit. :) Ciao, Marcus
On Monday 08 December 2003 21:22, Marcus Meissner wrote:
On Mon, Dec 08, 2003 at 10:39:54AM +0000, Andrew de Quincey wrote:
e.g. in ITypeInfo_fnGetIDsOfNames, I have changed it to if(This->TypeAttr.cImplTypes && (This->TypeAttr.typekind==TKIND_INTERFACE || This->TypeAttr.typekind==TKIND_DISPATCH)) {
Do you have a sample installer for download?
Bah, I can't find one thats (a) available easily (b) free, and (c) has the same problem.
However, I AM writing you a sample winelib program which demonstrates the problem using the installshield typelib... I'll send it to you in a moment.
I think the change is good. Please submit. :)
Cool, glad you agree :) Next up is some reference count problem; the ITypeLib interface seems to get destroyed too early.
On Tue, 09 Dec 2003 18:22:04 +0000, Andrew de Quincey wrote:
Next up is some reference count problem; the ITypeLib interface seems to get destroyed too early.
Hmmm. I seem to recall posting a patch that fixed a similar issue (but in the wrong way) a few months ago. I think TypeInfo was not reffing its containing TypeLib or something like that. I don't remember if it was fixed by somebody else or not.... sorry I can't be more help, but that might be somewhere to start looking.
On Tuesday 09 December 2003 20:02, Mike Hearn wrote:
On Tue, 09 Dec 2003 18:22:04 +0000, Andrew de Quincey wrote:
Next up is some reference count problem; the ITypeLib interface seems to get destroyed too early.
Hmmm. I seem to recall posting a patch that fixed a similar issue (but in the wrong way) a few months ago. I think TypeInfo was not reffing its containing TypeLib or something like that. I don't remember if it was fixed by somebody else or not.... sorry I can't be more help, but that might be somewhere to start looking.
Yeah, I've played with it under windows... an ITypeInfo is supposed to AddRef() the ITypeLib ONCE when its retrieved using things like ITypeLib.FindName(). (when you release it, you do it just once as well, when the original refcount at which it was AddRef()ed is reached). This ain't happening. Yet. I've also found a number of other bugs in that file; specifically theres a lot of confusion between BSTR and OLESTR going on, which really really knackers things. Easy to do though: they've just confused the hell out of me!! So a BSTR is the same type as an OLESTR to the C compiler, EXCEPT it has a fancy hidden DWORD before the actual buffer giving the number of bytes used! Thats not at all confusing is it?
On Wed, 2003-12-10 at 00:12, Andrew de Quincey wrote:
Yeah, I've played with it under windows... an ITypeInfo is supposed to AddRef() the ITypeLib ONCE when its retrieved using things like ITypeLib.FindName(). (when you release it, you do it just once as well, when the original refcount at which it was AddRef()ed is reached). This ain't happening. Yet.
I don't remember exactly what I did, but I remember it being classed as "wrong" somehow... I expect it was reffing things too many times.
I've also found a number of other bugs in that file; specifically theres a lot of confusion between BSTR and OLESTR going on, which really really knackers things. Easy to do though: they've just confused the hell out of me!! So a BSTR is the same type as an OLESTR to the C compiler, EXCEPT it has a fancy hidden DWORD before the actual buffer giving the number of bytes used! Thats not at all confusing is it?
Indeed. BSTR is quite possibly the most moronic string type I've ever seen. For the interested lurkers amongst us, here is a useful guide to BSTR semantics I stumbled across some time ago. They use it internally in Redmond: http://blogs.gotdotnet.com/ericli/PermaLink.aspx/853ae05f-7610-4531-ab1b-070... It's good to have another person who understands OLE on board! I spent months getting to grips with the darn thing, and now I don't have any spare time to work on it :(
participants (3)
-
Andrew de Quincey -
Marcus Meissner -
Mike Hearn