[Mono-dev] Re: Mono-devel-list Digest, Vol 11, Issue 85

Fri Mar 31 14:07:32 EST 2006

Thanks for that update Jonathan,  I look forward to any such anouncement :)

As I am almost exclusivly a c# developer (besides the c++/cli i did for this gameEngine project) I dont think I can be of much help, but if you think of anything, please let me know and i'll do my best to contribute to this feature.

  -Jason

"Jonathan S. Chambers" <Jonathan.Chambers at ansys.com> wrote:
        v\:* {behavior:url(#default#VML);}  o\:* {behavior:url(#default#VML);}  w\:* {behavior:url(#default#VML);}  .shape {behavior:url(#default#VML);}        st1\:*{behavior:url(#default#ieooui) }                The COM Interop will eventually work in the Unmanaged->Managed direction. I’m doing the Managed->Unmanaged first since it seems more useful (and was easier for me to implement).

  - Jonathan

---------------------------------

  From: Jason S [mailto:jaytau at yahoo.com] 
Sent: Friday, March 31, 2006 1:11 PM
To: Jonathan S. Chambers; Jonathan Pryor
Cc: mono-devel-list at lists.ximian.com
Subject: RE: [Mono-dev] Re: Mono-devel-list Digest, Vol 11, Issue 85

    I read the COM Interop message that was attached, and it looks to pertain to Managed -> Unmanaged interop.

    Does the COM Interop also help the other way, calling Managed code from Unmanaged?

    For me, I was planning on using the PInvoke method of Managed -> Unmanaged interop.

    However for Unmanged -> Managed, I have a bit of a problem.   My project is a game engine, which is an unmanaged (C++) exe.   Because of this, it is very hard for me to  shim in a way of passing the gameEngine.exe a function pointer to managed code.  To do this seems that I require an additional mono-based shim.exe and have gameEngine.dll instead of .exe   

    So without re-architecting the gameEngine to be loaded as a .dll  (a game engine I didnt write so doing such a change is not trivial), I would like to be able to instantiate a managed assembly, and invoke classes/methods directly at the locations I need, which would, for this purpose, solve the same problem that C++/CLI currently solves for me.

    From what I understand about the mono runtime, this behavior i just described is available, if I integrate the runtime into the engine, however if there was a native API that let me do the Native-to-Managed interop I'm describing it would be of great use.

    Maybe such a native-mono-api already exists, if so then a pointer to some of the docs on how to use it would be very appreciated.

    Thank you for your patience, and spending the time to read this verbose mail!

    -Jason

"Jonathan S. Chambers" <Jonathan.Chambers at ansys.com> wrote:

    Yes, I was working on COM Interop a little while ago. My schedule got
busy for a little bit, but now I hope to finish the work. This will
initially apply only to MS COM on Windows. However, as COM and XPCOM are
very similar I think XPCOM Interop could be done with a little bit of
additional work. 

Look for updates in the coming weeks. 

Thanks,
Jonathan

-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jonathan
Pryor
Sent: Friday, March 31, 2006 6:56 AM
To: Jason S
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] Re: Mono-devel-list Digest, Vol 11, Issue 85

On Thu, 2006-03-30 at 22:55 -0800, Jason S wrote:
> What I would like to see, is a nice way of interoping from a native C
> ++ program into Mono.

As you mention, Microsoft's solution is C++/CLI. There isn't likely to
be C++/CLI support for Mono any time soon.

However, Microsoft has another solution for C++/managed code
integration: COM Interop - the C++ code uses managed code as if they
were COM objects.

Furthermore, Jonathan Chambers has been working on COM Interop support
for Mono, with the idea of expanding it for Mozilla XPCOM integration
and other object systems.

You might be able to (1) help him, and (2) make use of this
infrastructure to permit better C++ integration.