<div class="gmail_quote">On 8 July 2011 18:04, Alex <span dir="ltr">&lt;<a href="mailto:xtzgzorex@gmail.com">xtzgzorex@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
While this is theoretically possible, it would be completely<br>
nonstandard. How do you actually want to store CIL /and/ native code<br>
in ELFs? I&#39;m not very familiar with the format, but I can&#39;t imagine<br>
it&#39;d be a clean endeavor.<br>
<br>
Regards,<br>
<font color="#888888">Alex<br>
</font><div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>Hi Alex,</div><div><br></div><div>Why do you think that?  I&#39;ve actually pondered this approach for a while, as it could potentially bring a couple of benefits.</div>
<div><br></div><div>At the moment, the metadata is stored in the PE&#39;s text section.  So, why not just store it in the ELF&#39;s text section?  All the PE headers are completely ignored by the Windows runtime loader - they don&#39;t care about it (except for the CLR data directory offset, and text section offset, which is required to calculate RVAs).</div>
</div><div><br></div>Also, if you wrap the metadata in an ELF container, you could potentially write stubs to load the mono runtime.<div><br></div><div>Whilst I&#39;ve not dug into the Mono image loader code, I can&#39;t imagine it&#39;d be /too/ difficult to make it load an ELF binary, probably converting it to a pluggable system along the way.<br>
<br>-- <br>Tom Spink<br>
</div>