Re: A puzzling question

From: Igor Tandetnik (itandetnik_at_mvps.org)
Date: 03/05/04 

Date: Fri, 5 Mar 2004 09:31:48 -0500

"Simon Trew" <ten.egnaro@werts> wrote in message
news:ehgcoxoAEHA.220@TK2MSFTNGP09.phx.gbl...
> "Igor Tandetnik" <itandetnik@mvps.org> wrote in message
> news:OKwHYohAEHA.3048@tk2msftngp13.phx.gbl...
> > It _is_ handled this way. Or rather, IUnknown is not remoted at
all -
> > it's a [local] interface. Except for the final Release, the proxy
can
> > satisfy any IUnknown calls locally.
>
> Well, on a call to CoCreateInstance, you specify the interface you
want
> back, right? So wouldn't COM have to call QI remotely once if a client
QI'd
> for the IUnknown when it specified a different interface to
> CoCreateInstance?

QueryInterface for IUknown is always satisfied locally, and returns an
IUnknown implementation of the proxy manager. Precisely to maintain COM
identity rule.

 (Because of the IUnknown identity rule.) Alternately, COM
> would have to specify IID_IUnknown to the remote server's
CoCreateInstance,
> and then remotely QI for the interface that the client specified (this
could
> of course be wrapped in one remote call in the implementation of COM).

That's pretty much what happens. One remote call establishes the
connection between the local proxy manager and the server-side stub, and
retrieves the first interface. In fact, the internal protocol supports
retrieving an arbitrary number of interfaces in a single remote call -
this functionality is exposed via CoCreateInstanceEx. On the server
side, COM runtime does a vanilla CoCreateInstance followed by several
QueryInterface calls, then marshals the whole thing back to the client.

> But
> anyway, I don't think that that would definitely be equivalent
(because the
> guarantees for IUnknown don't have to apply to other interfaces).

I'm not sure what you are saying here. Can you explain a specific
scenario that worries you? 

-- 
With best wishes,
    Igor Tandetnik
"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

Relevant Pages

  • Re: A puzzling question
    ... > satisfy any IUnknown calls locally. ... Well, on a call to CoCreateInstance, you specify the interface you want ... would have to specify IID_IUnknown to the remote server's CoCreateInstance, ...
    (microsoft.public.vc.atl)
  • Marshalling a marshalled interface pointer
    ... component that contains this object holds a container of IUnknown ... It also exposes the interface 'IDiscussions' which provides the method ... Another 'ChatServer' is started and registers itself with the ... ChatBroker with the name "Server2". ...
    (microsoft.public.vc.atl)
  • Re: IUnknown interface
    ... both directly derived from IUnknown. ... two different implementations (note that usually both interface tables ... ULONG STDMETHODCALLTYPE Release ... virtual HRESULT DoSomething ...
    (microsoft.public.vc.language)
  • Re: Dual interface
    ... and exposes IDispatch (it must expose IUnknown ... I think the law should be every interface of the COM component implements, ... If a component implements a customized interface, ... then we could invoke the ...
    (microsoft.public.vc.language)
  • Re: ATL and object aggregation (more)
    ... I don't think you should call Releaseon an interface's pointer. ... an helper method that is called by the 'true' COM interface method ... > It's wrong because the IUnknown interface will be lost during the Query ... then the IInObj3Ptr InObj3Ptr constructor is ...
    (microsoft.public.vc.atl)