Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered
On Sat, Jul 31, 2004 at 12:51:01PM +0200, Jeroen Janssen wrote:
This change will make sure that if a proxy/stub dll was already registered, it is not overwritten by the TypeLib Marshaller if we're not registering an ole automation interface. I think we (always?) want to use a 'real' available proxy/stub implementation when available, instead of simply 'overruling' to the typelib marshaller.
Did you verify that this patch does not break InstallShield? Ciao, Marcus
Marcus Meissner wrote:
On Sat, Jul 31, 2004 at 12:51:01PM +0200, Jeroen Janssen wrote:
This change will make sure that if a proxy/stub dll was already registered, it is not overwritten by the TypeLib Marshaller if we're not registering an ole automation interface. I think we (always?) want to use a 'real' available proxy/stub implementation when available, instead of simply 'overruling' to the typelib marshaller.
Did you verify that this patch does not break InstallShield?
Uhmm, actually no. I'm currently trying to run an other program that has it's own proxy/stub code that should be used instead of the TypeLib Marshaller (since the TypeLib Marshaller doesn't seem to be able to handle this specific TypeLib). As far as I see it I have two options (to run this outprocess client/server program): 1) use the available proxy/stub code (which is what I assume Windows does?) However since some of the rpcrt4 stub/proxy handling in wine is not finished yet, this probably won't work always (and it doesn't yet for me for this application). And indeed I don't really know if this also affects for example InstallShield behaviour. 2) use the typelib marshaller if a typelib is registered (even though a proxy/stub is available). This is the current wine codepath, but it also does not work for me since I get some VT_USERDEFINED errors. But that started me wondering why the 'real' proxy/stub code is not used. Since some of the rpcrt4 code path seems to work with marshalling, I came up with this patch. What do you (and Rob) think is the best path to follow for now (what has the best chance of being successfull at this moment)? It seems to me currently I have two (wine) codepaths that both have their problems in relation to the application I am trying to run, but I don't know which path is the easiest/hardest to fix/work on. (from discussions I read) I thought InstallShield used only (automation) interfaces with the TypeLib Marshaller. Can you maybe point me to a (frequently used) program that uses the InstallShield installer (that is know to work) so I can test it specificly? --- Jeroen
On Sat, 31 Jul 2004 14:13:22 +0200, Jeroen Janssen wrote:
Uhmm, actually no. I'm currently trying to run an other program that has it's own proxy/stub code that should be used instead of the TypeLib Marshaller (since the TypeLib Marshaller doesn't seem to be able to handle this specific TypeLib).
As far as I see it I have two options (to run this outprocess client/server program): 1) use the available proxy/stub code (which is what I assume Windows does?) However since some of the rpcrt4 stub/proxy handling in wine is not finished yet, this probably won't work always (and it doesn't yet for me for this application). And indeed I don't really know if this also affects for example InstallShield behaviour.
2) use the typelib marshaller if a typelib is registered (even though a proxy/stub is available). This is the current wine codepath, but it also does not work for me since I get some VT_USERDEFINED errors. But that started me wondering why the 'real' proxy/stub code is not used. Since some of the rpcrt4 code path seems to work with marshalling, I came up with this patch.
Well, you could use private hacks if you can find out what the user defined types are.
What do you (and Rob) think is the best path to follow for now (what has the best chance of being successfull at this moment)? It seems to me currently I have two (wine) codepaths that both have their problems in relation to the application I am trying to run, but I don't know which path is the easiest/hardest to fix/work on.
Fixing this problem is not trivial, it was only a matter of time before we found such an app. Basically we need to do what TransGaming did and flip our DCOM on top of RPC, however that will not be simple, our current code uses a totally custom protocol based on named pipes. I'm not fully sure what's involved: it may be easiest to simply remove the hack and fix what breaks with as many programs as possible.
(from discussions I read) I thought InstallShield used only (automation) interfaces with the TypeLib Marshaller.
No, we force all interfaces to go via it whether they want to or not.
Can you maybe point me to a (frequently used) program that uses the InstallShield installer (that is know to work) so I can test it specificly? ---
iTunes :) But really, installshield is hugely popular, there are many such apps: demos of Macromedia products tend to use them for instance.
As far as I see it I have two options (to run this outprocess client/server program): 1) use the available proxy/stub code (which is what I assume Windows does?) However since some of the rpcrt4 stub/proxy handling in wine is not finished yet, this probably won't work always (and it doesn't yet for me for this application). And indeed I don't really know if this also affects for example InstallShield behaviour.
2) use the typelib marshaller if a typelib is registered (even though a proxy/stub is available). This is the current wine codepath, but it also does not work for me since I get some VT_USERDEFINED errors. But that started me wondering why the 'real' proxy/stub code is not used. Since some of the rpcrt4 code path seems to work with marshalling, I came up with this patch.
What VT_USERDEFINED errors?
What do you (and Rob) think is the best path to follow for now (what has the best chance of being successfull at this moment)? It seems to me currently I have two (wine) codepaths that both have their problems in relation to the application I am trying to run, but I don't know which path is the easiest/hardest to fix/work on.
Instead of 1 || we could check the IID of the interface and only register those InstallShield needs.
(from discussions I read) I thought InstallShield used only (automation) interfaces with the TypeLib Marshaller.
And some non-automation, which however have typelibs.
Can you maybe point me to a (frequently used) program that uses the InstallShield installer (that is know to work) so I can test it specificly?
Umm. Dont know offhand. CIao, Marcus
Marcus Meissner wrote:
As far as I see it I have two options (to run this outprocess client/server program): 1) use the available proxy/stub code (which is what I assume Windows does?) However since some of the rpcrt4 stub/proxy handling in wine is not finished yet, this probably won't work always (and it doesn't yet for me for this application). And indeed I don't really know if this also affects for example InstallShield behaviour.
2) use the typelib marshaller if a typelib is registered (even though a proxy/stub is available). This is the current wine codepath, but it also does not work for me since I get some VT_USERDEFINED errors. But that started me wondering why the 'real' proxy/stub code is not used. Since some of the rpcrt4 code path seems to work with marshalling, I came up with this patch.
What VT_USERDEFINED errors?
Well, the last part of the server trace logging is: trace:ole:LoadTypeLibEx returns 00000000 trace:ole:LoadRegTypeLib (IID: {00020430-0000-0000-c000-000000000046}) load SUCCESS (0x42626760) trace:ole:ITypeLib2_fnAddRef (0x42626760)->ref was 1 trace:ole:ITypeLib2_fnGetTypeInfoOfGuid (0x42626760) guid: {3599b012-1f4b-11d4-9463-000629d00584}) trace:ole:ITypeLib2_fnGetTypeInfoOfGuid -- element not found trace:ole:ITypeLib2_fnRelease (0x42626760)->(1) trace:ole:ITypeInfo_fnGetRefTypeInfo (0x426252c8) hreftype 0x000d loaded FAILURE (0x42e07fd8) fixme:ole:deserialize_param Could not get typeinfo of hreftype d for VT_USERDEFINED. fixme:ole:TMStubImpl_Invoke Failed to deserialize param pObjectType, hres 8002802b trace:ole:_invoke Calling 0x672d3b80(40d55520,40320060,) fixme:ole:_xread Read only 0 of 4 bytes from 0xd0. fixme:ole:_StubReaderThread Failed with hres 80004005 And the last part of the client trace logs contains something similar: trace:ole:LoadTypeLibEx returns 00000000 trace:ole:LoadRegTypeLib (IID: {00020430-0000-0000-c000-000000000046}) load SUCCESS (0x40371928) trace:ole:ITypeLib2_fnAddRef (0x40371928)->ref was 1 trace:ole:ITypeLib2_fnGetTypeInfoOfGuid (0x40371928) guid: {3599b012-1f4b-11d4-9463-000629d00584}) trace:ole:ITypeLib2_fnGetTypeInfoOfGuid -- element not found trace:ole:ITypeLib2_fnRelease (0x40371928)->(1) trace:ole:ITypeInfo_fnGetRefTypeInfo (0x403702e0) hreftype 0x000d loaded FAILURE (0x403718d0) fixme:ole:serialize_param Could not get typeinfo of hreftype d for VT_USERDEFINED. fixme:ole:xCall Failed to serialize param, hres 8002802b trace:ole:PipeBuf_GetBuffer (0x4069fb60,{11ef83d1-553a-11d3-bb12-0004ac9658d6}), slightly wrong. trace:ole:PipeBuf_SendReceive () trace:ole:deserialize_param vt 26 at 0x4069fbe4 fixme:ole:deserialize_param Failed to load pointer cookie. fixme:ole:xCall Failed to unmarshall param, hres 80004005 How can I find out what is wrong here? --- Jeroen
Jeroen Janssen wrote:
As far as I see it I have two options (to run this outprocess client/server program): 1) use the available proxy/stub code 2) use the typelib marshaller if a typelib is registered
And maybe a 3rd option: use native ole/rpcrt/etc dlls? --- Jeroen
participants (3)
-
Jeroen Janssen -
Marcus Meissner -
Mike Hearn