[Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime

[Andreas Färber]

Hi Robert,

>> 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 [...]
>
> 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.

I know and dislike "the Java mess", and thus it is a bad argument for  
Mono doing so on Linux and Mac!!!

It's just the most uncomplicated way of going about it from the  
developer's point of view.

>> 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?
>
> #!/bin/sh
> # Universal PE Converter, Copyright (C) Robert `Smartass' J. :-)
> exec mono my-exciting-app.exe "$*"

This is not a converter and we both know it, we have tons of such  
scripts flying around for Mono, and some do not work on Solaris due  
to shell differences, e.g. mono-service.
Also, mono then gets a different pid than the executable started  
(maybe relevant on Windows and an apparent issue when playing with  
Cocoa# and AppleScript).

>> 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.

Thanks for pointing that out, wasn't aware.

However my general point is still valid: We don't have to blindly  
follow Microsoft, they made decisions from their local perspective  
(call it "cross-Windows") and we might want to be compatible but do  
not need to limit us to that scope. We are not "breaking the specs"  
should we do something unique, and if we want to do breaking  
differences we can still embed our own runtime identifier according  
to those same specs and go ahead with it, in theory.

For example, Microsoft does not seem to implement the full scope of  
their own ECMA spec while I would still very much like to see an  
implementation of the optional System.Threading.Parallel assembly on  
Mono. (I have done some initial non-parallel work on it and it might  
be beneficial to extend the spec's probably-intended-semantics there)
Anyone who reads that section of the spec will clearly see that there  
are a number of vague sections in the standard, and we all know that  
the CLI had not started out as a true cross-platform infrastructure,  
thinking of the platform enum there.


>> 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.
>
> The PE format is, like every decent binfmt, mmapable, so handling
> it from a stream is not a smart option.

I didn't say it should. (But to be picky, for an exception see the  
Symbian thread - it doesn't make sense to map something already in  
memory to another part of limited (flash) memory when you have random  
access to the stream/file in the first place, and it worked fine for  
me.)

If you review the above points you will see that option no. 2 is  
exactly providing a shell script, so your suggestion is not new  
either way.
And it would work on Windows as well if the extension were not  
stripped but replaced with .cmd (as we're only supporting NT anyway).

Andreas