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

[Jonathan Gilbert]

At 10:57 PM 6/4/2007 +0200, Robert Jordan wrote:
>Oh, now I see that the patch is actually changing WAPI's CreateProcess.
>
>This means that it won't work on Windows, where the native
>native CreateProcess is called instead.
>
>I think it's better to implement this in System.Diagnostics.Process
>using an icall that exposes argv[0].

I still prefer the environment variable approach. Are there any serious
disadvantages? Here are some additional thoughts:

- My understanding is that adding icalls is generally considered undesirable.
- If it isn't going to work to have the code inside CreateProcess, then if
it is implemented using an environment variable, the code for detecting CLR
binaries can be 100% managed. The only downside is that the logic for
determining the full path to the binary then needs to be duplicated, but it
needs to be duplicated anyway if the implementation can't be inside
CreateProcess, and if this is done in managed code, it can take advantage
of things like Path.GetFullName().
- Tools can be written to compare behaviour and/or performance of .NET
applications across different runtimes. For instance, on UNIX, code aware
of the behaviour could select between mono and DotGNU by setting the
environment variable. Similarly, on Windows, code could select between mono
and the MS .NET framework by clearing and re-setting the environment
variable. Also, on any platform, performance comparisons could be easily
done in an automated fashion between different versions of mono installed
side-by-side.

Shall I rework the patch to do the check directly inside
System.Diagnostics.Process.Start?

Also, is there any advantage in keeping the code in both places, so that
anybody directly calling into io-layer can take advantage of the change as
well? Is there any disadvantage for leaving it there for those few?

Jonathan Gilbert