As far as I see it I have two options (to run this outprocess client/server program):
- 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.
- 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