[Mono-bugs] [Bug 71887][Wis] Changed - detect .NET binaries and automatically invoke them with mono

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by 4lw0e0402@sneakemail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=71887

--- shadow/71887	2005-01-29 06:38:02.000000000 -0500
+++ shadow/71887.tmp.30560	2005-01-29 14:18:52.000000000 -0500
@@ -95,6 +95,37 @@
 ------- Additional Comments From atsushi@ximian.com  2005-01-29 06:38 -------
 > "Binary compatibility" depends on users code
 
 The effect of "binary compatibility", I mean. I never mean, the
 meaning (definition) of "binary compatibility" depends on users.
 
+
+------- Additional Comments From 4lw0e0402@sneakemail.com  2005-01-29 14:18 -------
+Atsushi-san,
+
+Suppose a user writes code for MS.NET that uses Process.Start() to 
+start another .NET program. Then, later, a different user wishes to 
+use this program under mono. At best, the process invocation starts 
+the process under a different runtime. This can affect Remoting 
+compatibility. At worst, the process invocation fails because the 
+system is unable to recognize that the binary should be started with 
+mono.
+
+When there are multiple runtimes installed (e.g. .NET + mono on 
+Windows), it is important that the process be started with the same 
+runtime. When there is only 'mono', it is important that the process 
+be started at all. Without any changes, it will fail.
+
+To resolve this problem, many programmers tell mono to invoke "mono 
+Program.exe". This makes the problem worse, because the program 
+developed using mono won't ever work properly on a system with the 
+Microsoft .NET Framework.
+
+It was also noted on mono-devel-list that binfmt-misc isn't able to 
+tell the difference between a .NET program and a regular Windows 
+program. This means that binfmt-misc can't be effectively used when 
+the user wants to be able to transparently invoke both mono and WINE, 
+depending on the binary's type.
+
+Can you think of a situation where it would be desirable for the 
+child process to run under a different framework than the parent 
+process?