[Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
lupus at ximian.com
Wed Jun 6 10:39:02 EDT 2007
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
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
> 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  != NULL) && (argv   != 0))
> + g_setenv ("MONOEXECUTABLE", argv , 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
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 at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list