[Mono-devel-list] Seemless Executibles?

[Jonathan Pryor]

On Fri, 2004-06-18 at 12:32, Tom Larsen wrote:
> According to an article in MSDN on PE format titled "An In-Depth Look Into
> The Win32 Portable Executable File Format" by Matt Pietrek, .NET is tied
> in kind of how I decribed:

I know, and that's true for every Windows OS *except* Windows XP.  Alas,
I can't find a reference, but early in the Mono project (~June 2002)
mcs+mono-generated programs would properly execute under XP, but would
generate errors ("not a win32 program") on Windows 2000.  IIRC, the
reason for this was XP could tell from the program header that it was a
.NET program and would immediately use .NET.  Windows 2000 had no such
knowledge, and used the "trick" you described.  Since the mcs-generated
programs were broken, the trick failed under Windows 2000, resulting in
an incompatibility between mcs+mono and .NET.  This has been fixed. :-)

<snip/>

> In any event, to support it wholesale would be quite a task since not all
> Unix environments are ELF supported or x86.  I am a little interested in
> "native to native" though.  If you are building assemblies and executibles
> on Linux for running on Linux there should be a way to take a shortcut
> just like this.  Make the ELF header execute the mono IL interpeter using
> itself as data.  It sure won't be portable non-ELF systems and I'm iffy on
> whether or not it will work on non-x86 ELF systems.

The problem isn't that it would be a glorious hack, much as the current
.NET loading approach is. :-)  Nor is the problem that using ELF
wouldn't be portable to non-x86 ELF systems.

No, the problem is that it would have no compatibility.  Sure, you'd
have an IL container, but .NET would now refuse to launch it, as would
Rotor and Portable.NET.  Are you willing to use a solution that can only
be used by one program?  I'd bet most people aren't.

Plus, ELF lacks a number of "features" that PE provides, such as the
ability to embed arbitrary resources.  This is frequently used for icons
and language translations, to minimize the number of files required.

In short, providing "seamless" executables by using an ELF wrapper,
while possible, isn't viable -- no one would use it, except for those
individuals who not only don't care about Windows compatibility, but
actively want to *prevent* it.  This is a segment of the community that
I haven't seen much presence from, so I don't think it's worthwhile.

A more viable option is binfmt_misc and similar solutions -- just allow
the OS to load arbitrary executable formats.  Completely seamless, and
it retains compatibility.  It can also be readily extended to handle
Java programs, and anything else that may come along. :-)

 - Jon