[Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
robertj at gmx.net
Fri Jun 8 08:25:30 EDT 2007
Andreas Färber wrote:
> From my view the core problem is rather the PE format of the
> assemblies. The reason why Microsoft is using it is because it's
> their *native* executable format and the x86 stub in there, as far as
> I understood, blocks execution under DOS (like all Windows apps) and
> somehow calls into mscoree.dll (or similar) to have the assembly
Well, look at the Java mess on Windows: the average Windows user
is not even able to launch such apps, when they not come with
wrappers, shortcuts, whistles and bells.
No wonder MS has chosen their native exec format.
> executed on Windows. This is in the ECMA standard, okay, but I have
> been wondering why we don't provide a converter between PE and ELF/
> Mach-O to do the equivalent?
# Universal PE Converter, Copyright (C) Robert `Smartass' J. :-)
exec mono my-exciting-app.exe "$*"
> This is different from mkbundle's semantics in not embedding a full
> Mono but providing a stub only - either one dynamically linked to
> libmono.so/.dylib or invoking mono with the assembly, similar to a #!
> line. I understand that using the PE format is the basis of
> interoperability with Microsoft .NET but for a Unix-only app we don't
> need that and rather want to provide a convenient experience to users
> and developers (which a script does not always). On the Mac we don't
Is it worthwhile to spend a couple of weeks to blow up the runtime
with X binfmt readers/writers, while breaking the specs and
eventually obsoleting an one liner script?
BTW, you can achieve this with mkbundle using its "--nodeps" option
and omitting "--static". It's an one liner, too.
> Some other options to consider:
> - use .config file to map exe to the desired executable (whether
> script or mono) as done for libraries
> - instead of invoking mono with or without environment variables just
> strip the .exe extension and let the user take care of the path there
> (Unix only)
> - try to execute .exe, if this fails (because .NET is not installed
> or we can't execute PE binaries) fall back to invoking mono (monow on
> Simply prepending a pure shebang line does not seem to be an option
> given that mono does not read assemblies from stdin.
The PE format is, like every decent binfmt, mmapable, so handling
it from a stream is not a smart option.
More information about the Mono-devel-list