[Mono-devel-list] Interoperatbility between Unmanaged and Managed Programs

Jonathan Pryor jonpryor at vt.edu
Wed Mar 10 07:57:37 EST 2004


Below...

On Wed, 2004-03-10 at 07:21, Friedrich Priewasser wrote:
> Hello
> 
> For my thesis I have to implement a runtime mechanism that allows managed 
> programs to use unmanaged objects and vice versa.

Question 1: How are you defining "unmanaged object"?  GTK+ classes would
likely qualify, and the existing P/Invoke mechanism is sufficient to
support them (see Gtk#).

Strictly speaking, "unmanaged" means "anything that isn't managed",
which would include Java, Python, CLOS, O'Caml, and everything else that
isn't "managed", in addition to CORBA, COM, XPCOM, Ice...

Furthermore, do you want interoperability in the same process, such as
in-process COM?  Or will remoting work?  CORBA objects can be used with
Remoting.Corba (and if that isn't sufficient, then I'm sure
Remoting.Corba would welcome additional assistance).  DCOM could
probably be "plugged" into the existing Remoting infrastructure as
well.  Remoting+SOAP would likely permit use of existing "unmanaged"
objects for a large majority of cases.

The problem I see is that you haven't sufficiently defined what
*exactly* you want to do.  I can only assume that you want to use
existing in-process COM objects (or some equivalent, such as XPCOM
objects).  What would be cool is if we could use the existing Remoting
infrastructure to do in-process "Remoting", communicating with the
unmanaged objects.

Maybe that isn't a good idea.  I have no idea.  But it could be
interesting.

> If I'm rigth the best 
> way to do this is to implement COM, XPCOM or ORBit.

COM and XPCOM would either require trying to wrap them into Remoting,
which might be an interesting solution, or follow .NET's path of using
COM Callable Wrappers (CCWs) and Runtime Callable Wrappers (RCWs), to
permit the unmanaged code to call managed code (CCW) and for the managed
code to call COM objects (RCWs).

ORBit shouldn't be required; I would hope that Remoting.Corba would
permit ORBit interoperability.  If it doesn't, there's something to work
on. :-)

> My questions about that are:
> Which of these technologies is the best to solve my problem (if you think 
> I should use one of this)?

As mentioned above, you need to be more specific about what your problem
is.  I can only assume, and I've outlined some possible approaches
above, but the specifics will narrow the possible solution set.

> Has there be done any work in mono to use unmanaged objects?

P/Invoke and the DllImport attribute.

Remoting.Corba should also work with Mono.  At least, it did before.

I think someone worked on a .NET/Python bridge at one point...

> I would be glad if you could give me some information what I should do 
> first and where to get more information how I could do my task.

First, come up with a problem that needs solving.  "Interoperability
between Unmanaged and Managed [code]" is too vague, as I hope I've
pointed out by now, as there is a variety of unmanaged code, each of
which may require a different solution.  (For example, how do you
inter-operate with another system which has it's own garbage collector,
such as Java?  You'll need some way of making sure objects you create
can be tracked by both GC systems, so that things don't get out of
sync.  Or find an alternative solution, such as Remoting, to handle
communication between the systems.  An RMI/Remoting bridge might be
interesting...)

Second, do *lots* of reading, both about what you want to inter-operate
with (e.g. COM documentation), and about the existing .NET/Mono-native
interop mechanisms, such as P/Invoke and Remoting.  Try to leverage the
existing infrastructure as much as possible, both to simplify things,
test things, and keep life sane.

As for where to get more information....  Google?

 - Jon

(Random internal thought: what's with Remoting in this reply?  I'm not
even a Remoting developer, and it's like every other paragraph mentions
it...  Cool technology, in any event.)





More information about the Mono-devel-list mailing list