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

[Paolo Molaro]

On 06/06/07 Jonathan Gilbert wrote:
> This makes having 'mono' in $PATH an official requirement for mono to
> operate correctly...

For some things it's already required to have the mono tools installed
in $PATH (see for example the use of codedom and mcs...).

> As Robert Jordan pointed out, this means it will have no effect on Windows.
> For this reason, and also because I prefer managed code, I've rewritten the
> support into Process.Create (attached). You can choose which patch you wish
> to apply :-) (I couldn't resist answering a question in a LAMESPEC comment
> and correcting a minor error in another comment; you may split off or omit
> those parts of the patch if you think they are inappropriately mixing
> changes.)

The managed version of the patch is completely unacceptable, IMHO.
It duplicates a large amount of code and it will slow down process
execution a lot for a tiny corner case.

> But it is not inherited. If a tool is running a program which could
> potentially spawn a child process, that child process could potentially not
> start at all, or start with the wrong runtime. I mean, I think it's a fair
> assumption that if anyone is using mono to run .NET apps on Windows,
> they're doing it for a reason, and for that same reason they would want
> child processes to also run under mono.

It's not clear at all that is what they mean. On windows a managed
binary is always run by the MS framework unless you explicitly execute
mono prog.exe: I don't think this basic expectation should be subverted.
If someone wants to run a program with mono he can simply execute mono
directly.

> Index: mono/mono/mini/driver.c
> ===================================================================
> --- mono/mono/mini/driver.c	(revision 78469)
> +++ mono/mono/mini/driver.c	(working copy)
> @@ -717,6 +726,9 @@
>  	g_log_set_always_fatal (G_LOG_LEVEL_ERROR);
>  	g_log_set_fatal_mask (G_LOG_DOMAIN, G_LOG_LEVEL_ERROR);
>  
> +	if ((argv [0] != NULL) && (argv [0] [0] != 0))
> +		g_setenv ("MONOEXECUTABLE", argv [0], TRUE);
> +

argc can be 0 and this can cause a segfault.
If we use anything like this the env var name should be MONO_EXECUTABLE.
That said, the code to get the mono binary is not correct (argv[0]
can be anything).

So, the starting point is that trying to execute a managed assembly
on windows must use the .net runtime (by means of CreateProcess)
and on any other system it should be considered pretty much a bug
(or you should use the linux binfmt registration). Since poorly-written
applications may depend on being able to call this anyway, a solution
may be to include this check in the MONO_IOMAP handling, so that only
buggy apps will suffer the slowdown that the check imposes.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better