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

[Paolo Molaro]

On 06/07/07 Jonathan Gilbert wrote:
> What use case requires a managed application to create many hundreds of
> extremely-short-lived processes every second for any period of time? Is

What matters is that you're adding an unacceptable 25% overhead
for a corner case that has other inexpensive solutions.

> Firstly, if you run a managed C++/COM app in .NET, it will never
> "accidentally" start a managed child process using mono. Secondly, aren't

See my discussion of even using two different MS runtimes.

> support of mixed assemblies and COM interop eventual goals of mono (two
> independent goals, with much more activity on the latter)?

I never heard of anyone interested in supporting mixed mode assemblies:
for us it is a completely uninteresting case since it would work only on
windows, so if someone wants the feature he will have to implement it
(like Jonathan is implementing COM support).
The important thing to note is that we're much more likely to get
compatible serialization than mixed mode support. And mixed mode and COM
are only 2 examples of many features that are valid only for windows and
that we don't have plans to implement. We're certainly not going to
break execution of many programs for this corner case that has perfectly
valid, simple and not buggy solutions.

> the parent process with Mono. Over the years I have seen many cases where
> something has been rejected for Mono because it would have allowed people
> to write managed applications that *only* Mono could run. Of course, there
> are yet many ways to do that, but the emphasis has always been on
> interoperability.

Interoperability doesn't include not being able to run some .net programs
which is what your solution would do.

> >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".
> 
> That documentation is written by Microsoft.

Microsoft provides different runtimes on the same box.

> >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.
> 
> Yes, yes, this works, but it makes an enormous assumption: that I am the
> author of the application in question. If I am merely a consumer who has
> purchased a .NET application and wishes to run it on Linux, and it fails to
> run because of something Mono could easily have taken care of, that is, in
> my eyes, pretty much Mono's fault. As far as I'm concerned, depending on

First, it is trivial to make it run as I pointed out already two times:
use the Linux binfmt support (third time). Miguel is too lazy to do it
so he committed something like your first patch on Linux, which works
since there is only one working .net runtime there. So don't worry about
Linux. Your issue is only related to windows and it has never been a
problem on Linux.

> the fact that one platform will see "prog" as a binary and another will not
> and will instead search for and find "prog.exe" is a much worse hack than
> doing something that the documentation does not comment on and

A documented behaviour is a hack while breaking execution of programs as
you suggest is not?

> automatically do what, for the majority of users, is the "right thing".
> Asking code authors to use Process.Start on something other than the actual
> program filename and at the same time asking end users to create batch
> files or shell scripts just for the privilege of using Mono to run a
> program they did not write and about the internals of which they know
> nothing is completely unacceptable; it will alienate people.

Breaking execution of .net programs with no way to fix it is going to
alianate many more people (which is exactly what you suggested above:
just don't use mono: we want people to use mono, not drive them away
as your solution does).

> If argc is 0, then argv[0] == NULL (or the platform is non-compliant). Do
> we support any non-compliant platforms?

Point taken, you're right on this one.

> >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
> 
> I have yet to encounter a platform where the path separator is '\n'. Even
> assuming you meant '/', there are platforms which use other characters,
> such as ':'. In any event, I have never used Environment.PathSeparator; I
> just use Path.Combine and let it figure out the details. Why can't I also
> use Process.Create and let it figure out the details?

Sure, in fact Process.Create() is supposed to call the operating system
and make it execute the program you told it to and on windows that means
eventually executing with the Ms runtime (it's the OS that does that).

> >like anywhere but windows a prog.exe is a simple data
> >file and not an executable (modulo the binfmt registration I mentioned).
> 
> The same applies to the binary format of any other operating systems; aside
> from hacks and wrappers added specifically to support it, a Linux binary is
> "only data" to a FreeBSD machine, and so on. The more abstract one becomes,
> though, the closer a file becomes to a universal binary; most platforms can
> be configured to run .NET binaries directly, and all platforms can be
> configured to run scripts (Perl, Python, Ruby, etc.) directly.

Sure that's why the problem that you said is a problem on Linux isn't,
so we don't need to add any slowdown and unmaintainable code to the
Process class.

> >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,
> 
> As I understand it, unless you are embedding the run-time, the newest
> version is always used to launch any .NET application on Windows. Which BCL
> is used is chosen based on where the metadata in the EXE refers, and the
> bytecode and icalls is backwards-compatible. Launching a .NET 1.1
> application loads it in the 2.0 VM but runs it against the 1.1 BCL. (Mono
> behaves the same way, does it not?)

1.1 is a different runtime (the runtime includes mscorlib etc, so even
if the jit binary is the same, mscorlib and hence the runtime is
different) and it is binary-incompatible wrt serialization and other
issues, which exactly proves my point that Process.Create() is in no
way guaranteed to execute with the same runtime (remember that your
original asserted reason for your hack was serialization compatibility).

> Launching any .NET application from any other on Windows *is* guaranteed to
> use the same run-time, but obviously there will be remoting
> incompatibilities and other issues communicating between two processes if
> they are using different versions of the BCL. However, any application
> which has been designed with a child process communicating back to a parent
> process will have both the parent and the child compiled for the same
> run-time version against the same BCL.

You can't guarantee that if you use any third-party program, which
is one of the reasons you can have .config files specify the runtime
(instead of having a .config file you'd have to use a batch file for
mono, big deal).

> >or play some tricks with the 32 or
> >64 variants of the frameworks on a 64 bit box).
> 
> Unless you are embedding the run-time, I'm pretty sure you have no control
> over this. I could be mistaken, however; I have never played with a 64-bit
> Windows box.

Neither did I, but I read the documentation and you can look it up on
the web, too: Process.Create() has no way to guarantee that a program is
executed with the same runtime (and for very good reasons). As such, for
the sake of interoperability which is so dear to you and also because it
would be a bug to do, we won't force down our users throat the decision
as to which runtime to use to execute any program: if the user didn't
specify one (by explicitly using mono to run it) it's up to the
operating system to decide.
Until you realize that your solution breaks execution of programs
and prevents the user from ever being able to fix it (and no, not using
mono at all is not a solution), you won't be able to convince anyone.

lupus

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