[Mono-dev] Unmanaged Component Interop in Mono

[Paolo Molaro]

On 03/23/06 Jonathan S. Chambers wrote:
> So, this additional attribute takes a type that specifies the manager
> for this type of component. If we don't find this attribute we assume
> normal COM Interop, else we use this manager. At this point, the manager
> has a very simple role. It has to implement the methods on the class
> (it would probably also store a lot of utility methods). Right now
> in the runtime, I handle ComImport objects specially. When a method
> needs implemented, I emit the wrapper code needed to call the unmanaged
> object. My proposal is to move this to managed, and allow the various
> component managers to emit this code.
> 
> If I look at my changes to the runtime, I only really need 2/3 hooks in
> there; the rest of the code could be managed. The UNO work uses objects
> derived from MarshalByRef object and works via a proxy; they handle
> the method calls in the Invoke method via messages. This is very close
> to what I'm proposing except remove the Message layer for performance
> reasons. Give people a hook to directly emit code for the methods,
> rather than having to handle a message.
> 
> So, the manager object has a method that takes a method info and
> returns the emitted method. The is pretty much possible right now using
> the DynamicMethod class (or we could create a very simlar class in the
> component namespace). So, when the FastMethod class is created, the .ctor

DynamicMethod won't be duplicated, it may only be enhanced if needed
with some internal functions.

> code is emitted by the manager. The manager emits code for the constructor
> to create the unmanaged object and store it. Subsequent method calls are
> similarly resolved by the manager emitting code to invoke the methods on
> the underlying unmanaged objects. Deriving from MarshalByRef object and
> using a proxy object is what allows for 'late' casting (allow casting
> to succeed depending on a QueryInterface call). We could continue to use
> this method, or provide another hook for casting calls. If they succeed
> the methods would again be dynamically emitted by the manager.

The JIT must know about the cast or it can't be done efficiently.

> In short, this gets a lot of component interop code out of the
> runtime. It also opens up a way for mono to support a variety of component
> systems without people having to modify the runtime.

I'm all for having code written on the managed side when it makes
sense, but just moving code to managed is not going to make it better as
the last review of the COM support showed. I guess we'd need to see how
the code looks like.
I suggest first completing the COM support so it can be put in svn and
then taking a look at how we can better integrate also other object
systems.

Thanks.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better