[Mono-devel-list] .export Directive in IL

[Jonathan S. Chambers]

Thanks for the answers. I'm just experimenting with methods to call managed code from unmanaged code without using COM interop, i.e. something that would work on both .Net and Mono. Any advice would be appreciated. 

Also, perhaps the reason the library even loaded was because it was specified to load lazily, so the load really didn't ever happen.

Thanks Again,
Jonathan


-----Original Message-----
From:	Jonathan Pryor [mailto:jonpryor at vt.edu]
Sent:	Wed 6/29/2005 10:29 PM
To:	Jonathan S. Chambers
Cc:	Mono-devel-list at lists.ximian.com
Subject:	Re: [Mono-devel-list] .export Directive in IL
On Wed, 2005-06-29 at 10:26 -0400, Jonathan S. Chambers wrote:
> Hello All,
> 	I know that mixed mode assemblies are not supported under Mono
> (at least in the managed/unmanaged C++ sense). There is an older article
> (I've listed the link below) that demonstrates how to call managed
> functions from unmanaged code using some IL hacking. This is working
> fine under MS/.Net, and functions somewhat under Linux/Mono.

It functions at all?  Weird.

Basic question: where do you want this to run?  Mono/Win32 or
Mono/Linux?

It will not, and *cannot*, work under Mono/Linux.

The reason is that what .export does is it creates a normal PE export,
identical to any other PE export accessible via
LoadLibrary/GetProcAddress.  The problem with this is that Linux doesn't
use PE, it uses ELF, which is a very different mechanism.  (One major
difference: exported symbols are global to the entire process, not
scoped to a particular library, so binding to g_file_chooser_dialog_new
finds the *first* symbol in *all* libraries in the address space, which
might not be the one found in libgtk-x11-2.0.so.0.)

I'm surprised that a dlopen(3) of a PE file worked AT ALL.

This could work on Mono/Win32, since at least the file formats are
correct, though your later message may be correct that mono's ilasm
doesn't properly handle .extern.  This isn't a major problem, though,
since .extern isn't portable anyway (see above), so there is little
point in implementing it unless someone (1) provides the patch, or (2)
pays Novell for the functionality. :-)

 - Jon