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 -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list