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

[Leszek Ciesielski]

On 6/2/07, Jonathan Gilbert <2a5gjx302 at sneakemail.com> wrote:
> Hello,
>
> A long time ago, I ran into the issue where Process.Start within mono
> doesn't do what is expected. On Windows, it always runs the child process
> with Microsoft's framework, which can cause problems if it is remoting back
> to the parent process and hits an incompatibility. On other platforms, it
> is even worse: The Process.Start call simply does nothing, since the host
> operating system does not recognize the PECOFF/CLR binary format.
>
> Recently, I saw someone else having the same issue and decided it was
> finally time to do something about it (actually in my opinion it was time
> to do something about it a long time ago). I have created a patch to enable
> mono to find itself and call the child process with the same 'mono'
> interpreter if it is a CLR EXE file. I implemented it by means of an
> environment variable. While this may seem strange, I think it is the most
> logical choice. I have enumerated the advantages and disadvantages that I see:
>
> Advantages:
> - Allows people embedding mono to specify which external 'mono' binary is
> used, if any, by Process.Start calls.
> - Environment variable is inherited by child processes; children of a
> 'mono' process that embed mono will automatically use the same 'mono'.
> - Programs that are aware of multiple run-times can easily override or
> remove the value to determine which run-time will be used for a
> Process.Start call (e.g. DotGNU or MS .NET).
> - No new i-calls or exported data symbols are needed.
>
> Disadvantages:
> - Does not work on platforms that do not support environment variables (do
> we support any of those?).
>
> If I've missed anything and there is any particularly good reason not to
> implement it in this way, I'd be happy to hear it. :-)

There was some discussion of how this should work here:
http://bugzilla.ximian.com/show_bug.cgi?id=79263
I am still thinking that invoking through
AppDomain.ExecuteAssemblyByName
(http://msdn2.microsoft.com/en-us/library/6d3hh0kx.aspx) would be the
best way performance-wise... Although this is just my 2c, I did not
test this.

-- 
MS-DOS user since 5.0
Windows user since 3.11
Linux user since kernel 2.4
Novell Netware user since 2.2
WARCRAFT user since 1.0