[Mono-dev] Microsoft.Scripting.sll
Hi, What we will do for Microsoft.Scripting.dll Some said that it is open source so we can use microsoft dll directely. Other said that we must redo it. I have commit a start of it in olive module but the size of this dll is quite bigger than compiler and runtime. So if we can avoid to redo it for nothing... Wo what is the final choice?do or copy the MS dll in module as a ref? regards, Olivier dufour Lupus said : On 05/31/07 olivier dufour wrote: * My Mono.JScript.compiler use the MS.Scripting lib of silverlight. ** Is there any plan to support it? Is it ever supported somewhere in svn? ** Can I done it on olive module on SVN because it will be very useful for my ** compiler? ** Because, I see that we must do Mono.JScript.compiler and ** Mono.JScript.runtime but I see nobody talking about this lib. * MS.Scripting is the DLR and it has been released with an open source license so we don't need to reimplemnt it. lupus ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Stubs for several methods in WIndows.Forms
Bump. The patch is updated to current svn head. I would have created a bugzilla entry for this, but bugzilla page seems to be dead at the moment. On 5/7/07, Leszek Ciesielski [EMAIL PROTECTED] wrote: Hi, I am again playing with getting evemon to work on mono, this is a next set of stubs for missing methods. Regards, Leszek -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 evemon_stubs_2007-06-04.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Some implementation classes for PropertyGrid
Hi,
Had a few minutes of spare time yesterday and just wanted to code a little.
Attached are the results - some classes for System.Design that should help
for the Windows Forms PropertyGrid control to be completely functional.
I currently have to ability to commit myself. So somebody please review and
commit.
Btw. This was mostly developed blindly (against .Net) as the PropertyGrid
has a regression with displaying editors and I currently have no complete
mono devel setup, so please test before. It runs with MS.Net, but may not
with Mono.
They all belong into System.ComponentModel.Design in the System.Design
Assembly.
Changelog is: Implemented ;)
Happy Hacking
Andreas
//
// System.ComponentModel.Design.CollectionEditor.cs
//
// Author:
// Andreas Nahr ([EMAIL PROTECTED])
//
// (C) 2007 Andreas Nahr
//
//
// Permission is hereby granted, free of charge, to any person obtaining
// a copy of this software and associated documentation files (the
// Software), to deal in the Software without restriction, including
// without limitation the rights to use, copy, modify, merge, publish,
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
//
using System;
using System.Reflection;
using System.Collections;
using System.ComponentModel;
using System.Drawing.Design;
using System.Windows.Forms;
using System.Windows.Forms.Design;
namespace System.ComponentModel.Design
{
public class CollectionEditor : UITypeEditor
{
protected abstract class CollectionForm : Form
{
private CollectionEditor editor;
private object editValue;
public CollectionForm (CollectionEditor editor)
{
this.editor = editor;
}
protected Type CollectionItemType
{
get { return editor.CollectionItemType; }
}
protected Type CollectionType
{
get { return editor.CollectionType; }
}
protected ITypeDescriptorContext Context
{
get { return editor.Context; }
}
public object EditValue
{
get { return editValue; }
set {
editValue = value;
OnEditValueChanged ();
}
}
protected object[] Items
{
get { return editor.GetItems (editValue); }
set { editor.SetItems (editValue, value); }
}
protected Type[] NewItemTypes
{
get { return editor.NewItemTypes; }
}
protected bool CanRemoveInstance (object value)
{
return editor.CanRemoveInstance (value);
}
protected virtual bool CanSelectMultipleInstances ()
{
return editor.CanSelectMultipleInstances ();
}
protected object CreateInstance (Type itemType)
{
return editor.CreateInstance (itemType);
}
protected void DestroyInstance (object instance)
{
editor.DestroyInstance (instance);
}
protected virtual void DisplayError (Exception e)
{
MessageBox.Show (e.Message, Cannot construct
object, MessageBoxButtons.OK, MessageBoxIcon.Information);
}
protected override object
Re: [Mono-dev] Stubs for several methods in WIndows.Forms
Hello, Bugzilla is up again ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Microsoft.Scripting.sll
Hello, Some said that it is open source so we can use microsoft dll directely. We will use it directly. Other said that we must redo it. They are wrong. I have commit a start of it in olive module but the size of this dll is quite bigger than compiler and runtime. Do not commit this library to SVN, it is currently undergoing lots of changes, and I do not want to have to track that down. For now, just install IronPython 2.0 (where it comes) and use that. So if we can avoid to redo it for nothing... Wo what is the final choice?do or copy the MS dll in module as a ref? Until the final release of the DLR (or until it matures) just make your module assume that it is installed in the system path. For development, you will need to install it on your system path. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono debugger: some questions
hello martin, I recently investigated the mono debugger and it looks quite good and stable for mono c# development. however, I have some questions... 1) changing variables the mono web site states that the debugger is able to Inspect and change static and instance fields, local variables, and parameters [DONE]. inspecting variables etc. does work, but I did not found a command to change them. what's the current status or what is the correct command? 2) ironpython support debugging mono assemblies that were created by ironpython (i used 1.1) is partly working. I can set line breakpoints, next-stepping works, and source code lines of python code are also shown. (I saved the .exe before with -X:SaveAssemblies.) what's annoying is that the debugger always steps into the ironpython source code. furthermore, inspecting python variables does not work. say, I want to enhance mdb with ironpython support, what would I need to implement? create a new namespace Mono.Debugger.Languages.IronPython? 3) remote debugging support Say, I want to have remote debugging with mdb where mdb shall run on the host and the debugee runs on the target. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Debugger: Some questions
Hello Martin, I recently investigated the Mono Debugger and it looks quite good and stable for Mono C# development. However, I have some questions... 1) Changing variables The Mono web site states that the debugger is able to Inspect and change static and instance fields, local variables, and parameters [DONE]. Inspecting variables etc. does work, but I did not found a command to change them. What's the current status or what is the correct command? 2) IronPython support Debugging Mono assemblies that were created by Ironpython (i used 1.1) is partly working. I can set line breakpoints, next-stepping works, and source code lines of python code are also shown. (I saved the .exe before with -X:SaveAssemblies.) What's annoying is that the debugger always steps into the Ironpython source code. Furthermore, inspecting python variables does not work. Say, I want to enhance MDB with Ironpython support, what would I need to implement? Create a new namespace Mono.Debugger.Languages.IronPython? 3) Remote debugging support Say, I want to have remote debugging with MDB where MDB shall run on the host and the debugee runs on the target. I investigated mdb's source code and came to the following approach: For the host, the libmonodebuggerserver library does not issue the ptrace() commands locally, but send the commands via TCP/IP to the target. On the target, a small server listens, takes the commands, and executes the ptrace() commands locally. This would be similar to gdb and gdbserver. What do you think about this approach? Would it be feasible and a good solution? Are there any traps you think of? Best greetings and thank you in advance, Harald ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] (no subject)
hello martin, I recently investigated the mono debugger and it looks quite good and stable for mono c# development. however, I have some questions... 1) changing variables the mono web site states that the debugger is able to Inspect and change static and instance fields, local variables, and parameters [DONE]. inspecting variables etc. does work, but I did not found a command to change them. what's the current status or what is the correct command? 2) ironpython support debugging mono assemblies that were created by ironpython (i used 1.1) is partly working. I can set line breakpoints, next-stepping works, and source code lines of python code are also shown. (I saved the .exe before with -X:SaveAssemblies.) what's annoying is that the debugger always steps into the ironpython source code. furthermore, inspecting python variables does not work. say, I want to enhance mdb with ironpython support, what would I need to implement? create a new namespace Mono.Debugger.Languages.IronPython? 3) remote debugging support Say, I want to have remote debugging with mdb where mdb shall run on the host and the debugee runs on the target. I investigated mdb's source code and came to the following approach: For the host, the libmonodebuggerserver library does not issue the ptrace() commands locally, but send the commands via TCP/IP to the target. On the target, a small server listens, takes the commands, and executes the ptrace() commands locally. this would be similar to gdb and gdbserver. what do you think about this approach? would it be feasible and a good solution? are there any traps you think of? best greetings, harald ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Ximian services Update (SVN, mailing lists)
Hello, The Subversion repository is back up in the new location. They might need to recable it, so the service might go down for a few minutes today, but should not take more than that. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] New Mono.Data.Sqlite problems with UTF8 conversion on Windows
Hello! I was trying to use the new implementation of Sqlite provider available now on mono, but I had several problems with it... First of all it failed to perform BindParameters properly when I tried to use named parameters. After some debugging it appeared that the names of parameters are improperly read from data returned by sqlite native function. The problem was the usage of Marshal.PtrToStrAuto in SQLiteConvert.cs function, which didn't properly decode strings on Windows system. I patched the implementation with the way it is done in old Mono.Data.SqliteClient - the implementation isn't very elegant, since it adds usage of unsafe pointer, but it worked well in the old implementation. If anybody knows a better way to convert unmanaged utf8 strings into managed string, without adding dependency on other libraries, then we could do this better. The second problem I encounter with new implementation is that it seems to deadlock when there are two threads using the same data-base... I use separate connections for each thread, but it looks like when I perform data-modify operations from both, it locks totally (concurrent reads seems to be ok). If anyone has some suggestions, please let me know. For now I will stick with old implementation. -- Kamil Skalski http://nazgul.omega.pl sqlite_utf.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
Hello,
A long time ago, I ran into the issue where Process.Start within mono
doesn't do what is expected. On Windows, it always runs the child process
with Microsoft's framework, which can cause problems if it is remoting back
to the parent process and hits an incompatibility. On other platforms, it
is even worse: The Process.Start call simply does nothing, since the host
operating system does not recognize the PECOFF/CLR binary format.
Recently, I saw someone else having the same issue and decided it was
finally time to do something about it (actually in my opinion it was time
to do something about it a long time ago). I have created a patch to enable
mono to find itself and call the child process with the same 'mono'
interpreter if it is a CLR EXE file. I implemented it by means of an
environment variable. While this may seem strange, I think it is the most
logical choice. I have enumerated the advantages and disadvantages that I see:
Advantages:
- Allows people embedding mono to specify which external 'mono' binary is
used, if any, by Process.Start calls.
- Environment variable is inherited by child processes; children of a
'mono' process that embed mono will automatically use the same 'mono'.
- Programs that are aware of multiple run-times can easily override or
remove the value to determine which run-time will be used for a
Process.Start call (e.g. DotGNU or MS .NET).
- No new i-calls or exported data symbols are needed.
Disadvantages:
- Does not work on platforms that do not support environment variables (do
we support any of those?).
If I've missed anything and there is any particularly good reason not to
implement it in this way, I'd be happy to hear it. :-)
The patch makes changes in two places:
- Mini Driver: Good-lookin'!
er...
- mini/driver.c: In mono_main, the MONOEXECUTABLE environment variable is
set to argv[0] (unless argv[0] is empty -- I don't know if this can ever
happen, so the check can be removed if it is needless). I copied the
GLIB_CHECK_VERSION block that defines a g_setenv macro for older glib
versions over from metadata/icall.c.
- io-layer/processes.c: In CreateProcess, after the executable has been
identified, it is checked for PE and CLR headers using a new method
is_managed_binary (static to processes.c). If it is, then the command-line
is rebuilt to include the argv[0] value captured in the MONOEXECUTABLE
environment variable at the head and then CreateProcess is called
recursively. Note: It occurs to me that if the mono executable itself is
ever identified as a CLR executable, this will result in an unbounded loop
that will blow the bottom off of the stack in fairly short order. Is this
something to be concerned about?
I have included a simple test program for it too. (It isn't precisely a
test-case, though if needed I can figure out how to make one of them too.
:-) Simply compile parent.cs and child.cs with mcs (no flags needed), and
then 'mono parent.exe'. Before the patch, only the Process.Start call which
explicitly specifies 'mono' will work (assuming you have 'mono' in your
path). After the patch, both Process.Start calls in parent.cs will work
correctly.
I don't know if this patch is ready to be applied -- I probably don't even
know all of the cross-platform ramifications that it might have. Let me
know what you think about it :-)
I must apologize, by the way, for my mailer; if I attach the patch files as
plain text, it attempts to send them with no content-encoding and my
outbound mail server complains about the bare LF line endings. As such, I
have had to simply paste the patch into the e-mail. Since this is likely to
break it for the purposes of applying, I also attached a gzipped copy of
the file.
Enjoy,
Jonathan Gilbert
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 78469)
+++ mono/io-layer/processes.c (working copy)
@@ -18,6 +18,7 @@
#include unistd.h
#include signal.h
#include sys/wait.h
+#include fcntl.h
#include mono/io-layer/wapi.h
#include mono/io-layer/wapi-private.h
@@ -459,6 +460,140 @@
return (ret);
}
+static gboolean
+is_managed_binary (const gchar *filename)
+{
+ int original_errno = errno;
+#ifdef HAVE_LARGE_FILE_SUPPORT
+ int file = open (filename, O_RDONLY | O_LARGEFILE);
+#else
+ int file = open (filename, O_RDONLY);
+#endif
+ unsigned char buffer[8];
+ off_t file_size;
+ off_t pe_header_offset;
+ gboolean managed_so_far = TRUE;
+ int num_read;
+
+ /* If we are unable to open the file, then we definitely
+* can't say that it is managed. The child mono process
+* probably wouldn't be able to open it anyway.
+*/
+ if (file 0) {
+ errno = original_errno;
+ return FALSE;
+ }
+
+ /* Retrieve the length of the file for future sanity checks. */
+ file_size = lseek (file, 0, SEEK_END);
+ lseek
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
Hi Jonathan,
+static gboolean
+is_managed_binary (const gchar *filename)
+{
You can replace this func with something like that:
gboolean
mono_image_is_cil (const char *fname)
{
MonoImageOpenStatus status;
MonoImage *image;
image = mono_image_open_full (fname, status, TRUE);
if (image) mono_image_close (image);
return (image status == MONO_IMAGE_OK);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
On 6/2/07, Jonathan Gilbert [EMAIL PROTECTED] wrote: Hello, A long time ago, I ran into the issue where Process.Start within mono doesn't do what is expected. On Windows, it always runs the child process with Microsoft's framework, which can cause problems if it is remoting back to the parent process and hits an incompatibility. On other platforms, it is even worse: The Process.Start call simply does nothing, since the host operating system does not recognize the PECOFF/CLR binary format. Recently, I saw someone else having the same issue and decided it was finally time to do something about it (actually in my opinion it was time to do something about it a long time ago). I have created a patch to enable mono to find itself and call the child process with the same 'mono' interpreter if it is a CLR EXE file. I implemented it by means of an environment variable. While this may seem strange, I think it is the most logical choice. I have enumerated the advantages and disadvantages that I see: Advantages: - Allows people embedding mono to specify which external 'mono' binary is used, if any, by Process.Start calls. - Environment variable is inherited by child processes; children of a 'mono' process that embed mono will automatically use the same 'mono'. - Programs that are aware of multiple run-times can easily override or remove the value to determine which run-time will be used for a Process.Start call (e.g. DotGNU or MS .NET). - No new i-calls or exported data symbols are needed. Disadvantages: - Does not work on platforms that do not support environment variables (do we support any of those?). If I've missed anything and there is any particularly good reason not to implement it in this way, I'd be happy to hear it. :-) There was some discussion of how this should work here: http://bugzilla.ximian.com/show_bug.cgi?id=79263 I am still thinking that invoking through AppDomain.ExecuteAssemblyByName (http://msdn2.microsoft.com/en-us/library/6d3hh0kx.aspx) would be the best way performance-wise... Although this is just my 2c, I did not test this. -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
Hello Jonathan, A long time ago, I ran into the issue where Process.Start within mono doesn't do what is expected. On Windows, it always runs the child process with Microsoft's framework, which can cause problems if it is remoting back to the parent process and hits an incompatibility. On other platforms, it is even worse: The Process.Start call simply does nothing, since the host operating system does not recognize the PECOFF/CLR binary format. This is fantastic! I just was running into that problem over the weekend. Recently, I saw someone else having the same issue and decided it was finally time to do something about it (actually in my opinion it was time to do something about it a long time ago). I have created a patch to enable mono to find itself and call the child process with the same 'mono' interpreter if it is a CLR EXE file. I implemented it by means of an environment variable. While this may seem strange, I think it is the most logical choice. I have enumerated the advantages and disadvantages that I see: I rather not use the environment variable, for one computing the actual program name might not be easy. I rather just hard code it to `mono' and it would be up to the user to set the path name appropriately. I can not think of production uses where I would like to be using different kind of Monos to run different applications, other than testing (and it seems like setting this at startup would defeat that purpose except for embedding). Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
Hey, I rather not use the environment variable, for one computing the actual program name might not be easy. I rather just hard code it to `mono' and it would be up to the user to set the path name appropriately. At least in Debian, the mono executable is not called mono. It's cli: http://pkg-mono.alioth.debian.org/cli-policy/ I can not think of production uses where I would like to be using different kind of Monos to run different applications, other than testing (and it seems like setting this at startup would defeat that purpose except for embedding). Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
Hey, Miguel de Icaza wrote: You can replace this func with something like that: The problem is that this code lives in io-layer.c and Dick pointed out that it might be best to not depend on metadata code. Oh, now I see that the patch is actually changing WAPI's CreateProcess. This means that it won't work on Windows, where the native native CreateProcess is called instead. I think it's better to implement this in System.Diagnostics.Process using an icall that exposes argv[0]. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] Ximian services Update (SVN, mailing lists)
Hello, All services should be back up, please let me know if anything is not working, so we can look into it. Miguel. Hello, The Subversion repository is back up in the new location. They might need to recable it, so the service might go down for a few minutes today, but should not take more than that. Miguel ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ximian services (SVN, mailing lists) down for the weekend.
Board of Directors Officers, Directors (NASDAQ:NOVL) With all due respect, what are you thinking allowing this to happen? MONO is arguably (one of) NOVLs Holy Grail(s), as are the Ximian technologists, crown jewels. Sincerely and respectfully, /s/esecurites.com formerly wallstreetradio.com acquired by Vcall.com beneficial shareholders (NASDAQ:NOVL) ps Congratulations with q2 fy2007, GPLv3 last call http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=tmbn=12776tid=221642mid=221642tof=4frt=2 http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=tmbn=12776tid=221365mid=221366tof=37rt=2frt=2off=1 http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=tmbn=12776tid=221443mid=221443tof=2frt=2 On 6/1/07, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello folks, I have just been told that the network at the Ximian/Novell office in Cambridge (where the Mono mailing lists, web site and Subversion repositories). It is unfortunate that I only learned about this minutes before the network was supposed to go down, so I could not make alternative plans for the Mono web site. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
I rather not use the environment variable, for one computing the actual program name might not be easy. I rather just hard code it to `mono' and it would be up to the user to set the path name appropriately. At least in Debian, the mono executable is not called mono. It's cli: http://pkg-mono.alioth.debian.org/cli-policy/ They have both, cli i think is a symlink, if they dont do that, its not our fault, and they should provide a patch just like they patch the rest. I can not think of production uses where I would like to be using different kind of Monos to run different applications, other than testing (and it seems like setting this at startup would defeat that purpose except for embedding). Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono'runtime
At 10:57 PM 6/4/2007 +0200, Robert Jordan wrote: Oh, now I see that the patch is actually changing WAPI's CreateProcess. This means that it won't work on Windows, where the native native CreateProcess is called instead. I think it's better to implement this in System.Diagnostics.Process using an icall that exposes argv[0]. I still prefer the environment variable approach. Are there any serious disadvantages? Here are some additional thoughts: - My understanding is that adding icalls is generally considered undesirable. - If it isn't going to work to have the code inside CreateProcess, then if it is implemented using an environment variable, the code for detecting CLR binaries can be 100% managed. The only downside is that the logic for determining the full path to the binary then needs to be duplicated, but it needs to be duplicated anyway if the implementation can't be inside CreateProcess, and if this is done in managed code, it can take advantage of things like Path.GetFullName(). - Tools can be written to compare behaviour and/or performance of .NET applications across different runtimes. For instance, on UNIX, code aware of the behaviour could select between mono and DotGNU by setting the environment variable. Similarly, on Windows, code could select between mono and the MS .NET framework by clearing and re-setting the environment variable. Also, on any platform, performance comparisons could be easily done in an automated fashion between different versions of mono installed side-by-side. Shall I rework the patch to do the check directly inside System.Diagnostics.Process.Start? Also, is there any advantage in keeping the code in both places, so that anybody directly calling into io-layer can take advantage of the change as well? Is there any disadvantage for leaving it there for those few? Jonathan Gilbert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono'runtime
At 08:06 PM 6/4/2007 +0100, Leszek Ciesielski wrote: There was some discussion of how this should work here: http://bugzilla.ximian.com/show_bug.cgi?id=79263 I am still thinking that invoking through AppDomain.ExecuteAssemblyByName (http://msdn2.microsoft.com/en-us/library/6d3hh0kx.aspx) would be the best way performance-wise... Although this is just my 2c, I did not test this. This small increase in performance is definitely not worth the serious breaking difference in behaviour. When AppDomain.ExecuteAssemblyByName is used, the child process is actually within the same process as the caller. How would the object returned by Process.Start represent this? What if you wanted to kill off the child process after a certain timeout? Process.Kill would terminate the parent as well! Jonathan Gilbert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
