[Mono-dev] Mixed Mode Assemblies

[Tom Spink]

On 8 July 2011 18:57, Alex Corrado <alexander.corrado at gmail.com> wrote:

> Tom,
>
> On Fri, Jul 8, 2011 at 1:40 PM, Tom Spink <tspink at gmail.com> wrote:
> > Why do you think that?  I've actually pondered this approach for a while,
> as
> > it could potentially bring a couple of benefits.
>
> I am curious to know what benefits you are referring to. The original
> poster said:
>
> >>> Without a doubt, every case where I've wanted/needed to use C++.NET has
> been
> >>> to create a mixed mode assembly with the intent of creating a clean,
> >>> optimized .NET interface for some piece of unmanaged code. If P/Invoke
> and
> >>> System.Runtime.InteropServices formed a complete solution for importing
> >>> native functionality into .NET, then I doubt Microsoft would have
> bothered
> >>> allowing for mixed-mode assemblies at all.
>
> I tend to agree with this statement. Mixed-mode assemblies, whether in
> PE or some other format, strike me as hackish and are not portable
> across platforms. How managed and native code are packaged (same
> binary or separately) is not really related to the problem of the two
> interoperating. It would be perfectly possible to create a
> source-compatible C++/CLI implementation that emits native code in a
> platform native binary, and managed code in an ECMA CLI native (PE)
> binary.
>
> Best,
>
> Alex Corrado
>


Hi Alex,

Interestingly enough, I wasn't thinking about mixed-mode assemblies at all!
 I was just thinking about normal assemblies being packaged in an ELF
container, rather than a PE container.  (I must have lost track of the
conversation)

The reason being, on a platform that supported loading ELF binaries, you
could get to load the mono runtime by emitting native code in in the
appropriate ELF section, for the entry-point.  Of course, on Linux you have
binfmt_misc - but personally, this has always felt like a hack.

And, I completely agree that mixed-mode assemblies are, even by definition,
non-portable - for the reasons you've already given.

-- 
Tom Spink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20110708/554487f4/attachment.html