[Mono-dev] COM Interop in Mono
kornelpal at hotmail.com
Wed Nov 16 13:07:15 EST 2005
You are referencing something that you want to upload to SVN but did not
show it yet. What is it exactly?
Note that there were discussions about COM interop previously you should
look at them as well.
Some important things:
COM is Windows specific. If you want to use it you can use MS.NET instead of
Mono as relaying on COM interop is platform dependent. So there is no use to
implement COM interop only for use with Windows.
On the other hand COM interop could be implemented as a platform independent
object oriented P/Invoke-like layer that could be cool. But the problem is
that on Windows COM specifies a standard ABI (Application Binary Interface)
for representing COM objects that can be accessed by code compiled using
On other platforms (Linux for example) there is no standard ABI for objects,
only for classic C functions. This makes the things difficult. In addition
things like XPCOM assume that you use the same compiler on both sides of
interop so has no specific ABI, it depends on the C++ compiler you use.
Some people would like to implement COM interop as Bonobo interop in Mono
but these two layers are so much different that it cannot be done. Bonobo
interop has to be implemented separatedly as it requires different interop
attributes for example.
----- Original Message -----
From: "Jonathan S. Chambers" <Jonathan.Chambers at ansys.com>
To: "Jonathan S. Chambers" <Jonathan.Chambers at ansys.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, November 16, 2005 5:50 PM
Subject: RE: [Mono-dev] COM Interop in Mono
Well, no one has responded yet, so here comes the next email ;-)
This work is coming along, so I'd like to get it in svn soon.
Would this go under the trunk, as in /trunk/cominterop or something like
that? If anyone has a better name, please suggest. Also, I think this
work will also be similar to work needed for XPCOM. Should both be in
the same lib? Or where can I put shared functionality?
Ok, more details. All calls to the RCW's are finding their way to the
correct methods on the COM objects. Currently, I find the interface that
the method belongs to. I then subtract interface->method.start from the
method->slot. This gives me the offset of the method in the interface. I
then compensate for whether the interface is IUnknown based or IDispatch
based (3 or 7 methods at beginning of vtable). I then call that offset
on the correct vtable.
Now, more about integrating into mono. To correctly support COM interop
in mono, the following functionality is needed. I'm trying to begin to
define what the API needs to support.
1. Object Creation
2. Method Calls
3. Object Destruction (will all component wrappers need a finalizer?)
4. Casting (more difficult for me, can be supported later as this
dynamically adds interfaces to an object)
5. Interface/COM object marshalling
6. BSTR marshalling (I think this should be in this library, so mono has
no dependencies on the Sys*String routines for BSTRS)
Some humble beginning like:
/* creates unmanaged object */
/* destroys unmanaged object */
component_destroy(MonoObject * this);
/* gets managed->unmanaged wrapper for method calls, called by
component_get_method (MonoMethod *method)
Not sure about the marshalling yet...
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jonathan
Sent: Monday, November 14, 2005 10:06 PM
Cc: mono-devel-list at lists.ximian.com
Subject: [Mono-dev] COM Interop in Mono
Here is a brief overview of some work involving COM Interop support
in mono. I'm sure I'm wrong on multiple things below, so feel free to
Don't feel like saying alot. Lots of docs available.
MS COM Interop
Again, well documented. Especially via '.NET and COM: The Complete
Interoperability Guide' by Adam Nathan. COM interop is twofold.
1. Managed Client, COM Server - This allows for unmanaged com components
to be used in the managed runtime. This occurs via runtime callable
wrappers (RCW). The RCW is a managed wrapper that manages a single
unmanaged com object. The lifetime of the COM object is managed via the
RCW; the RCW's lifetime is managed like any other managed object. Also,
the interop can occur via early binding (using the Interop assembly and
vtables) or late binding via reflection.
2. COM Client, Managed Server - In this case, an managed object is
exposed to COM via a COM callable wrapper (CCW). The CCW behaves like a
normal COM object to the client. The CCW exposes interfaces
corresponding to the managed object's methods/properties, as well as
IUnknown, IDispatch, and other interfaces.
Another thing to note about COM interop is the runtime support for
casting. Normal managed objects fail upon a cast when an interface is
not implemented by that object. A RCW will try to cast the normal way,
via the metadata provided about the class. If the cast fails, the
runtime will then call QueryInterface on the underlying COM object for
the interface in question. If the QueryInterface succeeds, then the
runtime allows the cast to occur.
I'm ignoring other semi-important (depending on your situation) aspects
of COM interop such as COM threading, connection points, etc.
Old Approach (all in C#, runtime agnostic; i.e. worked on MS. Net and
I'm not going to spend much time on this. This work initially grew out
of looking at some code by Peter Bartok in Win32Dnd.cs in MWF. A COM
interface (really just a vtable) is essentially a structure of function
pointers. Function pointers can be marshalled as delegates (in 2.0) and
vice versa. So, for each COM interface a corresponding struct of
delegates was defined; except, the all the method signatures were
modified to take an IntPtr as the first argument, the 'this; pointer.
Once the COM object was created, it was QI'd for that interface. Then,
the returned pointer (which points to the vtable) was read via
Marshal.ReadIntPtr. This value is then marshalled as the struct
previously defined. The delegates can now be invoked.
In addition, custom marshallers were written for the marshalling of
interfaces and BSTRs. Tricks were played with pinning, GCHandles, etc
for lifetime management. Also, to get around the fact that there was no
runtime support for 'late' casting, Reflection.Rmit was used to build
This method proved useful, but ugly and inefficient to say the least.
This method involves the mono runtime directly. Currently, I'm focusing
on RCW, i.e. using COM components in managed code. I'm also using the
Interop assemblies generated via MS's tlbimp.exe (in the future, someone
could easily write a tool to generate compatible assemblies via an XML
definition or whatever instead of from a typelib).
When a RCW class is loaded by the runtime, extra space is allocated in
the class instance to contain the unmanaged object pointer. Upon
creation of a RCW, the underlying COM object is created via
CoCreateInstance and it's pointer is stored in the RCW.
All methods on a RCW are marked internal call. Thus, for each method a
managed->unmanaged wrapper is generated. Currently, here is the process
1. The pointer to the COM Object is obtained from the RCW.
2. The function pointer to the method obtained. The method layout in the
interop assembly is the same order as that of the vtable of the COM
object. Thus, the offset of the method on the RCW is used to offset into
the vtable of the COM object, and get the correct function pointer.
3. The interface pointer and method arguments are pushed on the stack.
If the managed method has a return value, a reference to a local
variable of that type is pushed on the stack as the last arg to the COM
method. The function pointer is called, expecting a int32 as a return
value (an HRESULT that will be translated to an exception in the case of
a failure). If there is a return value, this return value is pushed onto
the stack and the method returns.
Currently, this mechanism allows for the use of a COM collection of
doubles in managed code.
TODO (lots, I'll stick to near term)
1. Get lifetime management of COM object working correctly. Perhaps RCW
will need finalizer that calls Release on COM object?
2. RCW has one pointer to COM object, but COM object has multiple
vtables. Need correct vtable for current interface that is being called.
3. BSTR marshalling
4. Interface marshalling
5. Use COM marshalling rules instead of PInvoke rules
6. 'late' casting
7. Wrap this into all into a separate library, and communicate with
runtime via API so no component technology specific code is in mono.
59. connection points
I know very little about XPCOM, but I understand that it is quite
similar. This should be able to be extended to that quite easily I
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list