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

[Paolo Molaro]

On 06/06/07 Jonathan Gilbert wrote:
> penalty? Surely the overhead of actually setting up a 10,000 child
> processes totally eclipses a 5 second penalty.

Well, maybe on windows it does. My 3 year old laptop can execute 2500
processes in those 5 seconds.

> >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.
> 
> Well I've never had that basic expectation. I've always felt that the same

Maybe because you have only a single use-case in mind?
What if you want to execute a managed C++/COM app or something else that
we still don't support in mono? Forcing the runtime to execute it with
mono will only get you a crash and worse, there is no way for you to
fix it, because your code prevented any possibility of running the program
with the MS runtime.

> framework classes. One of the strongest tenets of .NET for me has always
> been that the same *binary* will work in the same way on all platforms and
> with any run-time, and child processes being created under a different
> run-time completely violates that.

The Process class is for telling the operating system to execute child
processes, there is nothing in the documentation or anywhere else about
"using the same runtime".

I understand that you your scenario needs a solution, but hacking
Process is not it. What if you use "prog" instead of "prog.exe"
as the name of the executable? Windows will look for prog.exe
and run that, right? When you want to test with mono you'll have
a test directory with a prog.bat batch file and you can put that
directory at the start of your PATH environment var and execute your
program with mono: windows will load the batch file which in turn uses
mono to execute your prog.exe managed assembly.

> Are you sure? Even if argc is 0, argv is still NULL-terminated, is it not?

It is not defined to be NULL terminated.

> >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).
> 
> Sorry? You're saying that the use of Process.Start to launch a child
> process is a *bug* and that is not open for negotiation?

No, executing a managed assembly that way can be considered a bug,
just like not using PathSeparator for directories: anywhere but
windows it is \n, like anywhere but windows a prog.exe is a simple data
file and not an executable (modulo the binfmt registration I mentioned).
And it is definitely a bug to assume that the same runtime will be used
and I bet that this happens also when having different MS frameworks
installed on windows (run a program with the 1.1 framework and make it
execute a program that requires 2.0, or play some tricks with the 32 or
64 variants of the frameworks on a 64 bit box).

lupus

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