COM outproc & CFProxy unhandled interface for IRunnableObject

Jeroen Janssen japj at xs4all.nl
Thu Jul 22 07:45:31 CDT 2004


> IRunnableObject does not have anything to do with COM marshalling; it is
> an OLE thing. MSDN says this about it: "The *IRunnableObject *interface
> enables a container to control the running of its embedded objects". So
> basically, I don't see any reason why CFProxy (IClassFactory proxy)
> should implement it. Therefore, I suspect this message is just
> distracting you from the real source of the problem (and you don't state
> what the problem is).

Well MSDN also states "In the case of an object implemented with a local
server, calling IRunnableObject::Run launches the server's .EXE file. In
the case of an object implemented with an in-process server, calling the
Run method causes the object .DLL file to transition into the running
state".
So I'm wondering now if there is a relation with 'outproc' behaviour.

As far as the problem that I'm seeing, I indeed forget to mention that.
It seems that my client program can not access a COM object from the
server using outproc.
Maybe my 'real' problem is that based upon the logging, I also see a
CFProxy Unhandled interface for the first interface that the client is
trying to access (but I need to know more about how COM/wine deals with
this).

>>Can someone provide more information on how wine deals with Outproc COM?
>
> Mike Hearn posted a really good outline of COM to wine-devel a week or
> two ago. I suggest that you read that first, but feel free to ask any
> specific questions.

Ok, I'll read that first. Thanks for pointing this out.

>>On a side note, what are the main differences in COM implementation
>>between wine and winex (if I understand correctly, Transgaming rewrote
>> the
>>COM implemenation for winex in order to better support the InstallShield
>>installer?).
>
> Ove from Transgaming has donated their COM implementation to wine
> (several years ago), and Mike Hearn and I are trying to find a way to
> merge it that:
> 1) Improves our (D)COM implementation
> 2) Doesn't introduce any regressions
> 3) Has the right architecture to build upon for future features

Ok, is the code that Ove released available somewhere?
How far in the process are you with merging?
Is there a TODO list or something like that?
I'm trying to understand if I can help the wine project by getting this
application working, so that's why I'm asking.
----
Jeroen Janssen



More information about the wine-devel mailing list