COM outproc & CFProxy unhandled interface for IRunnableObject

[Jeroen Janssen]

Hello,

I'm trying to run 2 programs:
1) is a COM server program
2) is a COM client program

Now, program 2) tries to access a COM component from 1) (outproc).

It seems some marshalling is being done, but eventually I get:

fixme:ole:CFProxy_QueryInterface Unhandled interface:
{00000126-0000-0000-c000-000000000046}

This interface seems to be IRunnableObject.

Now I'm not exactly sure how this is supposed to work, or even if this is
the reason why my test currently fails. I can provide more logging/info if
I know what exactly to provide.

Note that I tried a small outproc client/server test that seems to go ok
without this error, so the 'basic' outproc mechanism seems to work ok.

Can someone provide more information on how wine deals with Outproc COM?
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?).

Best regards,

Jeroen Janssen

[Robert Shearman]

Jeroen Janssen wrote:
> Hello,
>
> I'm trying to run 2 programs:
> 1) is a COM server program
> 2) is a COM client program
>
> Now, program 2) tries to access a COM component from 1) (outproc).
>
> It seems some marshalling is being done, but eventually I get:
>
> fixme:ole:CFProxy_QueryInterface Unhandled interface:
> {00000126-0000-0000-c000-000000000046}
>
> This interface seems to be IRunnableObject.
>
> Now I'm not exactly sure how this is supposed to work, or even if this is
> the reason why my test currently fails. I can provide more logging/info if
> I know what exactly to provide.

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).
> Note that I tried a small outproc client/server test that seems to go ok
> without this error, so the 'basic' outproc mechanism seems to work ok.

Good.
> 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.
> 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

Rob

[Jeroen Janssen]

> 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

[Mike Hearn]

On Thu, 22 Jul 2004 14:45:31 +0200, Jeroen Janssen wrote:
> 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).

Are you sure you're using COM right? I have also written an outproc
server test and it works OK - at least I've been able to marshal a Hello
World RPC across.

The class factory that is marshalled back across only supports
IClassFactory as far as I know, IRunnableObject may well be implemented on
the instances it creates but not the factory itself.
> > 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

It's not really possible (or a good idea) to merge all of it. Try googling
for "world-of-dcom" and that should show you the patch I got last time I
did a quick merge.

Me and Rob are starting to scrape together a plan, I think, and as part of
working on other apps we're fixing bits as we go, but it's a long long
road we have ahead of us. Any help would certainly be welcome.

thanks -mike