[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