[Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
Andreas Färber
andreas.faerber at web.de
Fri Jun 8 04:10:40 EDT 2007
Jonathan is right in pointing out that some Windows applications
might rely on a managed .exe file being executed on the target
platform. If we didn't want compatibility with Windows based .NET
apps we could dump the whole System.Windows.Forms and other Windows
specific stuff. Novell has made a certain investment there and it
would be half-heartedly to ignore this issue now even if it is only a
corner case for the majority of platform-aware Mono users.
Paolo however is right in saying executing managed .exes is possible
under Linux with binfmt, and Linux probably is the most widespread
Mono platform at the time. But I am not aware of making this work on
e.g. Mac OS X.
http://www.mono-project.com/
FAQ:_Technical#Can_I_run_Mono_applications_without_using_.
27mono_program.exe.27.3F
We might want to look into whether the Mono.framework could simply
map the .exe filetype to mono instead, not sure how Apple does it for
jars (but that would probably block opening native .exes with e.g.
Wine and would probably only work with "open my.exe" not "./my.exe")
Me neither, I don't like the solution of putting this into io-layer
(which I believe should behave as close as possible like Windows API)
or forcing the use of an environment variable pointing to mono on all
Mono users. I am embedding Mono on OS X and I do certainly not want
plugins of my app messing around with argv[0] in case they should try
Process.Start("some.exe").
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
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?
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
have Microsoft .NET so Mono's tools would be around to convert a
managed ELF assembly if necessary and vice versa. Metadata tables
would remain binary compatible with .NET, just the stub and maybe
offsets would change between executable formats.
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
Windows)
Simply prepending a pure shebang line does not seem to be an option
given that mono does not read assemblies from stdin.
Andreas
More information about the Mono-devel-list
mailing list