[Mono-devel-list] COM Interop

[Jonathan S. Chambers]

	Thanks for the response Rafael. I have a large amount of C++/COM
code and migrating it all is not an option (due to shear size and
performance reasons). I can port this code to *nix but have no way to
call it.
	I have already discussed this with some members of the mailing
list offline. Essentially, all I want to do is be able to call into a
C++ vtable. All of my code is COM in origin; so all my calls are through
interfaces (C++ abstract base classes), stdcall calling convention,
HRESULT return value, etc. After some discussion, the idea of
implementing COM Interop came up. But perhaps this is not the best
solution. Perhaps I should just host the mono runtime and make any minor
modifications I need to make. If there is not enough interest/benefit in
COM Interop, then embedding mono to meet my needs might be the
easiest/best solution.
	And just an FYI, I don't want all the COM/COM Interop
functionality. I wanted the runtime to be able to call into the vtable I
define through a corresponding managed interface, and the ability to
handle casting by calling QI (if trying to cast an unmanaged component
to a different interface, a cast can succeed if the QI succeeds even if
the managed wrapper does not inherit from that interface). Any insight
on this would be appreciated.

- Jonathan

-----Original Message-----
From: Rafael Teixeira [mailto:monoman at gmail.com] 
Sent: Monday, July 25, 2005 1:30 PM
To: Jonathan S. Chambers
Cc: mono-devel
Subject: Re: [Mono-devel-list] COM Interop

On 7/25/05, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
>         I am interested in implementing some support for COM Interop
for
> the mono runtime. A goal is that the mono version of COM Interop could
> support various component models (COM, XPCOM, and Bonobo have been
> proposed); whether more than one can be supported at one time is
another
> decision that someone will need to make.

I would hope that not to happen, as COM is just more trouble than it
is worth. I prefer to rewrite any COM component as something fully
managed, but yes there are cases (like using OLE Automation to control
omnipresent apps) that we may have to concede. But I personally would
not space for COM to breath.

Alas, you are in the group that may have invested so much on COM, or
depend on OLE Automation or Third-Party ActiveX Components so let's
see what I can help than further discuss the merit of the proposition.

>         Component model specific code will not be part of the mono
> runtime, but part of an external library loaded at runtime (as
> requested).

Very good decision. I just don't think Bonobo will fit in nicely as it
is very different from the other two, and from the COM-Interop
premises embedded in .NET.

> A few questions
> 
> 1. Would the mono runtime be aware of common functionality that exists
> in all (currently proposed) component models; essentially the
> functionality of the Unknown interface (reference counting and
interface
> querying)?

I fear you'll have to do that: Just to mimic correctly all the
COM-specific things that the Base Class Library has.

> 2. As MS has a base COM object wrapper (__ComObject), I was planning a
> similar one for mono. This wrapper would hold onto the unmanaged
object
> pointer and provide additional functionality as required. Does this
> sound ok?

Yes, but you'll need a lot more baggage than this class. Issues with
threading-models and GC x ReferenceCounting clutter this space and are
mapped in this API surface.

> 3. I assume some sort of reference counting will take place. For
> simplicity, I was planning on AddRef'ing/Release'ing at every
> interaction. This is different that the MS implementation, I believe.
> For example, (again, I believe) MS keeps track of the IUnknown pointer
> and addref's only once upon entry into the managed runtime. Each
> unmanaged component then seems to be wrapped by only one managed
> wrapper.

The problem is you can't Release freely as it may kill the object
prematurely. I'm not sure but I think the Disposable pattern is used
to control the lifetime of wrapped COM objects a bit better but some
exceptions to the rule may appear.

> 4. I assume each unmanaged interfaces will have a corresponding
managed
> interface defined and tagged with appropriate attributes. The
> GuidAttribute would work for COM/XPCOM, but Bonobo takes a string for
> its QueryInterface.

Well that is what I said about Bonobo not fitting in. Let's look at
the problem from the developer that will be using it perspective.

Bonobo components are normally totally diverse from similar COM
components, it is hard to imagine having an interface-for-interface
match that would allow you to write a single hosting code to  accept a
COM component and an equivalent Bonobo component. That's is easier
between COM /XPCOM as that was way XPCOM was written in the first
place.

So If I want to write apps that use Bonobo components the most I would
expect is to be able to reuse "concepts", and similarly named classes,
but little mor than that.

So probably a BonoboObject (double-underscores aren't really needed in
this case) should be built as a counterpart to the __ComObject that
may be able to deal with COM and XPCOM.

> (Kornel mentioned having additional namespaces under
> System.Runtime.InteropServices, such as
> System.Runtime.InteropServices.Bonobo).

No way. Adding subnamespaces in the ECMA/MS namespaces isn't allowed. 
We can have a Mono.Runtime.InteropServices.Bonobo or a shorter and
appropriate Bonobo namespace.

> Thanks,
> Jonathan
> 

Good luck,

-- 
Rafael "Monoman" Teixeira
---------------------------------------
I'm trying to become a "Rosh Gadol" before my own eyes. 
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!