From mbd at dbc.dk  Fri Jun  1 07:03:41 2007
From: mbd at dbc.dk (Mads Bondo Dydensborg)
Date: Fri, 1 Jun 2007 13:03:41 +0200
Subject: [Mono-dev] OdbcConnection pooling?
Message-ID: <200706011303.42034.mbd@dbc.dk>

Hi there

On 
http://msdn2.microsoft.com/en-us/library/system.data.odbc.odbcconnection(vs.80).aspx
it says

"To deploy high-performance applications, you frequently must use connection 
pooling. However, when you use the .NET Framework Data Provider for ODBC, you 
do not have to enable connection pooling because the provider manages this 
automatically."

However, a few tests with Mono suggest that there is a substantial overhead in 
creating a opening OdbcConnections. Does Mono support automatic pooling of 
OdbcConnections?

Regards,

Mads

-- 
Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34



From sanxiyn at gmail.com  Fri Jun  1 08:35:20 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Fri, 1 Jun 2007 21:35:20 +0900
Subject: [Mono-dev] Mono profiler question
Message-ID: <5b0248170706010535n75ce84e9jb9b61995c3157a84@mail.gmail.com>

I want to write a Mono profiler that would call C# callback when
methods satisfying certain criteria are entered or left. In
particular, I want to check whether a certain custom attribute is
defined in the assembly that defines the method.

struct _MonoProfiler {
MonoClass *check_for_this_attribute;
}

void
mono_profiler_startup
{
prof->check_for_this_attribute = <MonoClass for class X in namespace
Y.Z, assembly W>
}

Eh, how do I get that MonoClass?

-- 
Seo Sanghyeon


From lupus at ximian.com  Fri Jun  1 12:19:09 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Fri, 1 Jun 2007 18:19:09 +0200
Subject: [Mono-dev] Mono policies.
In-Reply-To: <d74c39240705310440o48c2c55j7519625c05d04f46@mail.gmail.com>
References: <1180415966.26722.58.camel@erandi.dom>
	<d74c39240705290108l56c9aeb5tee08d9dd8da9b0b9@mail.gmail.com>
	<d74c39240705310440o48c2c55j7519625c05d04f46@mail.gmail.com>
Message-ID: <20070601161909.GG4081@debian.org>

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

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


From lupus at ximian.com  Fri Jun  1 12:17:08 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Fri, 1 Jun 2007 18:17:08 +0200
Subject: [Mono-dev] IMT patch
In-Reply-To: <8cca42d80705310355o6807d47fj94c2ec3f2eb861a9@mail.gmail.com>
References: <1180604542.4329.61.camel@matrix.ximian.com>
	<8cca42d80705310355o6807d47fj94c2ec3f2eb861a9@mail.gmail.com>
Message-ID: <20070601161708.GF4081@debian.org>

On 05/31/07 Rodrigo Kumpera wrote:
> Do you have any measurements of the collision rates the hash function
> generates over corlib? This should provide enough data to verify the hash
> quality. If collision is too bad, you could store the IMT slot in MonoMethod
> and do slot distribution when the interface is loaded.

We won't store the imt slot in MonoMethod, because it would be an
additional field and waste memory for something seldomly used. Besides
it's cheap to calculate the hash and that happens only in
non-performance critical codepaths.

> You are using indirect absolute jmps over the vtable pointer, which is
> slower than relative jmps. The code could check if the target method is
> already compiled and issue a relative jump directly. The compile trampolines
> could patch the thunks, but this could end been really tricky.

We used the indirect jumps to avoid having to patch the thunks
(which would required either to decode the instructions or to keep
additional info in memory).

> How fast is the hash function? Shouldn't the IMT slot be cached in
> MonoMethod?

See above, it doesn't matter if the hash is slow and using more runtime
memory is a bigger issue.

lupus

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


From lupus at ximian.com  Fri Jun  1 12:01:14 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Fri, 1 Jun 2007 18:01:14 +0200
Subject: [Mono-dev] [patch 5/5] Enable JIT on hppa-linux
In-Reply-To: <465F3DBF.9040506@tausq.org>
References: <465F3DBF.9040506@tausq.org>
Message-ID: <20070601160114.GD4081@debian.org>

On 06/01/07 Randolph Chung wrote:
> This is a work-in-progress to port the mono JIT to hppa. With this patch
> (and the previous ones in the series) in place, the JIT will compile and
> generate code.
> 
> The status of the regression tests are:
> basic: Overall results: tests: 2356, 100% pass, opt combinations: 19
> basic-calls: Overall results: tests: 475, 100% pass, opt combinations: 19
> basic-float: Overall results: tests: 475, 100% pass, opt combinations: 19
> basic-long: Overall results: tests: 1615, 100% pass, opt combinations: 19
> arrays: Overall results: tests: 399, failed: 10, opt combinations: 19
> (pass: 97.49%)
> exceptions: crashes
> objects: crashes
> bench: runs but fails
> generics: hangs
> 
> A simple "hello world" will run.

You made impressive progress! You may also want to start running the
tests in mono/mono/tests (with make test in that dir).
The patches looks good at a quick check, so we just need you to sign-off
them to include them in svn.
Thanks!

lupus

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


From miguel at novell.com  Fri Jun  1 13:51:28 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Fri, 01 Jun 2007 13:51:28 -0400
Subject: [Mono-dev] Mono profiler question
In-Reply-To: <5b0248170706010535n75ce84e9jb9b61995c3157a84@mail.gmail.com>
References: <5b0248170706010535n75ce84e9jb9b61995c3157a84@mail.gmail.com>
Message-ID: <1180720288.4099.75.camel@erandi.dom>

Hello,

> I want to write a Mono profiler that would call C# callback when
> methods satisfying certain criteria are entered or left. In
> particular, I want to check whether a certain custom attribute is
> defined in the assembly that defines the method.

If you have the MonoMethod handle (I assume you do):

	MonoClass *k = mono_method_get_class (method);

Then you can get the image:

	MonoImage *image = mono_class_get_image (k);

And then you can use:

    MonoType *t = mono_reflection_type_from_name ("TypeName", image);

Miguel

> struct _MonoProfiler {
> MonoClass *check_for_this_attribute;
> }
> 
> void
> mono_profiler_startup
> {
> prof->check_for_this_attribute = <MonoClass for class X in namespace
> Y.Z, assembly W>
> }
> 
> Eh, how do I get that MonoClass?
> 


From miguel at ximian.com  Fri Jun  1 18:06:21 2007
From: miguel at ximian.com (Miguel de Icaza)
Date: Fri, 01 Jun 2007 18:06:21 -0400
Subject: [Mono-dev] Ximian services (SVN,
	mailing lists) down for the weekend.
Message-ID: <1180735581.4099.114.camel@erandi.dom>

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.


From olivier.duff at gmail.com  Mon Jun  4 06:34:29 2007
From: olivier.duff at gmail.com (olivier dufour)
Date: Mon, 4 Jun 2007 12:34:29 +0200
Subject: [Mono-dev] Microsoft.Scripting.sll
Message-ID: <d74c39240706040334t360504a0n50540fd5609c5868@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070604/6109efd4/attachment.html 

From skolima at gmail.com  Mon Jun  4 06:25:42 2007
From: skolima at gmail.com (Leszek Ciesielski)
Date: Mon, 4 Jun 2007 12:25:42 +0200
Subject: [Mono-dev] Stubs for several methods in WIndows.Forms
In-Reply-To: <23a15590705070825l150ac130l4c0f86b319307b6@mail.gmail.com>
References: <23a15590705070825l150ac130l4c0f86b319307b6@mail.gmail.com>
Message-ID: <23a15590706040325g326ed643jea772f573bd1a225@mail.gmail.com>

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 <skolima at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: evemon_stubs_2007-06-04.patch
Type: application/octet-stream
Size: 5712 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070604/f12532c8/attachment.obj 

From ClassDevelopment at A-SoftTech.com  Sat Jun  2 12:51:12 2007
From: ClassDevelopment at A-SoftTech.com (Andreas Nahr)
Date: Sat, 2 Jun 2007 18:51:12 +0200
Subject: [Mono-dev] Some implementation classes for PropertyGrid
In-Reply-To: <1180735581.4099.114.camel@erandi.dom>
References: <1180735581.4099.114.camel@erandi.dom>
Message-ID: <0DE0BD5492A6461880087528FD780E5F@ansirua>

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CollectionEditor.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070602/90b5278f/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DateTimeEditor.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070602/90b5278f/attachment-0001.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MultilineStringEditor.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070602/90b5278f/attachment-0002.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ArrayEditor.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070602/90b5278f/attachment-0003.pl 

From miguel at novell.com  Mon Jun  4 12:13:20 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 04 Jun 2007 12:13:20 -0400
Subject: [Mono-dev] Stubs for several methods in WIndows.Forms
In-Reply-To: <23a15590706040325g326ed643jea772f573bd1a225@mail.gmail.com>
References: <23a15590705070825l150ac130l4c0f86b319307b6@mail.gmail.com>
	<23a15590706040325g326ed643jea772f573bd1a225@mail.gmail.com>
Message-ID: <1180973600.9389.144.camel@erandi.dom>

Hello,

   Bugzilla is up again 


From miguel at novell.com  Mon Jun  4 12:14:37 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 04 Jun 2007 12:14:37 -0400
Subject: [Mono-dev] Microsoft.Scripting.sll
In-Reply-To: <d74c39240706040334t360504a0n50540fd5609c5868@mail.gmail.com>
References: <d74c39240706040334t360504a0n50540fd5609c5868@mail.gmail.com>
Message-ID: <1180973677.9389.147.camel@erandi.dom>

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.


From krapfenbauer at ict.tuwien.ac.at  Mon Jun  4 03:38:46 2007
From: krapfenbauer at ict.tuwien.ac.at (Harald Krapfenbauer)
Date: Mon, 4 Jun 2007 09:38:46 +0200
Subject: [Mono-dev] mono debugger: some questions
Message-ID: <AE8F9DA4B3AA6A40A2AFB30FB6C8859F77EFAB@dc2003.ICT.TUWIEN.AC.AT>

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.


From krapfenbauer at ict.tuwien.ac.at  Mon Jun  4 12:38:46 2007
From: krapfenbauer at ict.tuwien.ac.at (Harald Krapfenbauer)
Date: Mon, 4 Jun 2007 18:38:46 +0200
Subject: [Mono-dev] Mono Debugger: Some questions
Message-ID: <AE8F9DA4B3AA6A40A2AFB30FB6C8859F77F03F@dc2003.ICT.TUWIEN.AC.AT>

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


From krapfenbauer at ICT.TUWIEN.AC.AT  Mon Jun  4 03:45:15 2007
From: krapfenbauer at ICT.TUWIEN.AC.AT (Harald Krapfenbauer)
Date: Mon, 4 Jun 2007 09:45:15 +0200
Subject: [Mono-dev] (no subject)
Message-ID: <AE8F9DA4B3AA6A40A2AFB30FB6C8859F77EFB3@dc2003.ICT.TUWIEN.AC.AT>

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


From miguel at ximian.com  Sat Jun  2 11:37:47 2007
From: miguel at ximian.com (Miguel de Icaza)
Date: Sat, 02 Jun 2007 11:37:47 -0400
Subject: [Mono-dev] Ximian services Update (SVN, mailing lists)
In-Reply-To: <1180735581.4099.114.camel@erandi.dom>
References: <1180735581.4099.114.camel@erandi.dom>
Message-ID: <1180798667.9389.0.camel@erandi.dom>

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


From kamil.skalski at gmail.com  Sat Jun  2 12:27:30 2007
From: kamil.skalski at gmail.com (Kamil Skalski)
Date: Sat, 2 Jun 2007 18:27:30 +0200
Subject: [Mono-dev] New Mono.Data.Sqlite problems with UTF8 conversion on
	Windows
Message-ID: <711aea6b0706020927t4c507435gc0d6929ad72a0e36@mail.gmail.com>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sqlite_utf.diff
Type: application/octet-stream
Size: 1710 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070602/b7bf1930/attachment.obj 

From 2a5gjx302 at sneakemail.com  Sat Jun  2 16:29:30 2007
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: Sat, 02 Jun 2007 15:29:30 -0500
Subject: [Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
Message-ID: <30990-68458@sneakemail.com>

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 (file, 0, SEEK_SET);
+
+	/* We know we need to read a header field at offset 60. */
+	if (file_size < 64)
+		managed_so_far = FALSE;
+
+	/* Verify the MZ executable signature word. */
+	if (managed_so_far) {
+		num_read = read (file, buffer, 2);
+
+		if ((num_read != 2)
+		 || (buffer[0] != 'M')
+		 || (buffer[1] != 'Z'))
+			managed_so_far = FALSE;
+	}
+
+	/* Get the offset of the PE header. */
+	if (managed_so_far) {
+		off_t new_offset = lseek (file, 60, SEEK_SET);
+
+		if (new_offset != 60)
+			managed_so_far = FALSE;
+		else {
+			num_read = read (file, buffer, 4);
+
+			if (num_read != 4)
+				managed_so_far = FALSE;
+			else {
+				pe_header_offset =  buffer[0]
+				                 | (buffer[1] <<  8)
+				                 | (buffer[2] << 16)
+				                 | (buffer[3] << 24);
+
+				if (pe_header_offset + 24 > file_size)
+					managed_so_far = FALSE;
+			}
+		}
+	}
+
+	/* Verify that the header we've found is in fact the PE header. */
+	if (managed_so_far) {
+		off_t new_offset = lseek (file, pe_header_offset, SEEK_SET);
+
+		if (new_offset != pe_header_offset)
+			managed_so_far = FALSE;
+		else {
+			num_read = read (file, buffer, 4);
+
+			if ((num_read != 4)
+			 || (buffer[0] != 'P')
+			 || (buffer[1] != 'E')
+			 || (buffer[2] != 0)
+			 || (buffer[3] != 0))
+				managed_so_far = FALSE;
+		}
+	}
+
+	/* Verify that the header we want in the optional header data
+	 * is present in this binary.
+	 */
+	if (managed_so_far) {
+		off_t new_offset = lseek (file, pe_header_offset + 20, SEEK_SET);
+
+		if (new_offset != pe_header_offset + 20)
+			managed_so_far = FALSE;
+		else {
+			num_read = read (file, buffer, 2);
+
+			if ((num_read != 2)
+			 || ((buffer[0] | (buffer[1] << 8)) < 216))
+				managed_so_far = FALSE;
+		}
+	}
+
+	/* Read the CLR header address and size fields. These will be
+	 * zero if the binary is not managed.
+	 */
+	if (managed_so_far) {
+		off_t optional_header_offset = pe_header_offset + 24;
+		off_t new_offset = lseek (file, optional_header_offset + 208, SEEK_SET);
+
+		if (new_offset != optional_header_offset + 208)
+			managed_so_far = FALSE;
+		else {
+			guint32 first_word, second_word;
+
+			num_read = read (file, buffer, 8);
+
+			/* We are not concerned with endianness, only with
+			 * whether it is zero or not.
+			 */
+			first_word = *(guint32 *)&buffer[0];
+			second_word = *(guint32 *)&buffer[4];
+
+			if ((num_read != 8)
+			 || (first_word == 0)
+			 || (second_word == 0))
+				managed_so_far = FALSE;
+		}
+	}
+
+	close (file);
+
+	errno = original_errno;
+
+	return managed_so_far;
+}
+
 gboolean CreateProcess (const gunichar2 *appname, const gunichar2 *cmdline,
 			WapiSecurityAttributes *process_attrs G_GNUC_UNUSED,
 			WapiSecurityAttributes *thread_attrs G_GNUC_UNUSED,
@@ -741,6 +876,35 @@
 		   args_after_prog);
 #endif
 	
+	/* Check for CLR binaries; if found, we will try to invoke
+	 * them using the same mono binary that started us.
+	 */
+	if (is_managed_binary (prog) && (appname == NULL)) {
+		char *mono_executable = getenv ("MONOEXECUTABLE");
+
+		if (mono_executable != NULL) {
+			gsize bytes_ignored;
+
+			appname = mono_unicode_from_external (mono_executable, &bytes_ignored);
+
+			if (appname != NULL) {
+				cmdline = utf16_concat (appname, utf16_space, cmdline, NULL);
+
+				g_free ((gunichar2 *)appname);
+
+				if (cmdline != NULL) {
+					gboolean return_value = CreateProcess (NULL, cmdline, process_attrs,
+						thread_attrs, inherit_handles, create_flags, new_environ,
+						cwd, startup, process_info);
+
+					g_free ((gunichar2 *)cmdline);
+
+					return return_value;
+				}
+			}
+		}
+	}
+
 	if (args_after_prog != NULL && *args_after_prog) {
 		gchar *qprog;
 
Index: mono/mini/driver.c
===================================================================
--- mono/mini/driver.c	(revision 78469)
+++ mono/mini/driver.c	(working copy)
@@ -49,6 +49,7 @@
 #include "inssel.h"
 #include <locale.h>
 #include "version.h"
+#include <glib.h>
 
 static FILE *mini_stats_fd = NULL;
 
@@ -671,6 +672,14 @@
 	"\tDisabled:      " DISABLED_FEATURES "\n"
 	"";
 
+/*
+ * If your platform lacks setenv/unsetenv, you must upgrade your glib.
+ */
+#if !GLIB_CHECK_VERSION(2,4,0)
+#define g_setenv(a,b,c)   setenv(a,b,c)
+#define g_unsetenv(a) unsetenv(a)
+#endif
+
 int
 mono_main (int argc, char* argv[])
 {
@@ -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);
+
 	opt = parse_optimizations (NULL);
 
 	for (i = 1; i < argc; ++i) {
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProcessStartFix.diff.gz
Type: application/octet-stream
Size: 2060 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070602/7c62d5f5/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testapps.tar.gz
Type: application/octet-stream
Size: 377 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070602/7c62d5f5/attachment-0001.obj 

From robertj at gmx.net  Mon Jun  4 14:30:56 2007
From: robertj at gmx.net (Robert Jordan)
Date: Mon, 04 Jun 2007 20:30:56 +0200
Subject: [Mono-dev] PATCH: Make Process.Start() use the same 'mono'
	runtime
In-Reply-To: <30990-68458@sneakemail.com>
References: <30990-68458@sneakemail.com>
Message-ID: <f41lpr$mdp$1@sea.gmane.org>

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);
}



From skolima at gmail.com  Mon Jun  4 15:06:00 2007
From: skolima at gmail.com (Leszek Ciesielski)
Date: Mon, 4 Jun 2007 20:06:00 +0100
Subject: [Mono-dev] PATCH: Make Process.Start() use the same 'mono'
	runtime
In-Reply-To: <30990-68458@sneakemail.com>
References: <30990-68458@sneakemail.com>
Message-ID: <23a15590706041206p73c79637w6b7c58b886847d6d@mail.gmail.com>

On 6/2/07, Jonathan Gilbert <2a5gjx302 at sneakemail.com> 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


From ClassDevelopment at A-SoftTech.com  Mon Jun  4 15:08:25 2007
From: ClassDevelopment at A-SoftTech.com (Andreas Nahr)
Date: Mon, 4 Jun 2007 21:08:25 +0200
Subject: [Mono-dev] Some implementation classes for PropertyGrid
In-Reply-To: <0DE0BD5492A6461880087528FD780E5F@ansirua>
References: <1180735581.4099.114.camel@erandi.dom>
	<0DE0BD5492A6461880087528FD780E5F@ansirua>
Message-ID: <ED8DE36741394E37A5EC2EE5E4AC611B@ansirua>

It seems as if my outgoing mailserver virus-check did damage the
attachements. So please treat with care.

Happy Hacking
Andreas 

-----Urspr?ngliche Nachricht-----
Von: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Andreas
Nahr
Gesendet: Samstag, 2. Juni 2007 18:51
An: mono-devel-list at lists.ximian.com
Betreff: [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



From miguel at novell.com  Mon Jun  4 16:18:56 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 04 Jun 2007 16:18:56 -0400
Subject: [Mono-dev] PATCH: Make Process.Start() use the same
	'mono'	runtime
In-Reply-To: <30990-68458@sneakemail.com>
References: <30990-68458@sneakemail.com>
Message-ID: <1180988336.23003.7.camel@erandi.dom>

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.


From miguel at novell.com  Mon Jun  4 16:28:00 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 04 Jun 2007 16:28:00 -0400
Subject: [Mono-dev] PATCH: Make Process.Start() use the same
	'mono'	runtime
In-Reply-To: <f41lpr$mdp$1@sea.gmane.org>
References: <30990-68458@sneakemail.com>  <f41lpr$mdp$1@sea.gmane.org>
Message-ID: <1180988880.23003.11.camel@erandi.dom>

Hello,

> 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.

> 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 at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


From robertj at gmx.net  Mon Jun  4 16:28:13 2007
From: robertj at gmx.net (Robert Jordan)
Date: Mon, 04 Jun 2007 22:28:13 +0200
Subject: [Mono-dev] PATCH: Make Process.Start() use the same 'mono'
	runtime
In-Reply-To: <1180988336.23003.7.camel@erandi.dom>
References: <30990-68458@sneakemail.com> <1180988336.23003.7.camel@erandi.dom>
Message-ID: <f41sl0$j9a$1@sea.gmane.org>

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



From robertj at gmx.net  Mon Jun  4 16:57:48 2007
From: robertj at gmx.net (Robert Jordan)
Date: Mon, 04 Jun 2007 22:57:48 +0200
Subject: [Mono-dev] PATCH: Make Process.Start() use the same 'mono'
	runtime
In-Reply-To: <1180988880.23003.11.camel@erandi.dom>
References: <30990-68458@sneakemail.com> <f41lpr$mdp$1@sea.gmane.org>
	<1180988880.23003.11.camel@erandi.dom>
Message-ID: <f41uce$q0v$1@sea.gmane.org>

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



From miguel at novell.com  Mon Jun  4 17:27:29 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 04 Jun 2007 17:27:29 -0400
Subject: [Mono-dev] [Mono-list] Ximian services Update (SVN,
	mailing lists)
In-Reply-To: <1180980985.9389.177.camel@erandi.dom>
References: <1180735581.4099.114.camel@erandi.dom>
	<1180980985.9389.177.camel@erandi.dom>
Message-ID: <1180992449.23003.33.camel@erandi.dom>

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  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list


From alt3r3d.carb0n at gmail.com  Sat Jun  2 14:00:59 2007
From: alt3r3d.carb0n at gmail.com (alt3r3d carb0n)
Date: Sat, 2 Jun 2007 14:00:59 -0400
Subject: [Mono-dev] Ximian services (SVN,
	mailing lists) down for the weekend.
In-Reply-To: <1180735581.4099.114.camel@erandi.dom>
References: <1180735581.4099.114.camel@erandi.dom>
Message-ID: <f65d3f720706021100l55dd8676g5857fc547bdb7143@mail.gmail.com>

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=tm&bn=12776&tid=221642&mid=221642&tof=4&frt=2

http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=tm&bn=12776&tid=221365&mid=221366&tof=37&rt=2&frt=2&off=1

http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_N/threadview?m=tm&bn=12776&tid=221443&mid=221443&tof=2&frt=2


On 6/1/07, Miguel de Icaza <miguel at ximian.com> 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 at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070602/76c0b8a5/attachment.html 

From miguel at novell.com  Mon Jun  4 17:31:22 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 04 Jun 2007 17:31:22 -0400
Subject: [Mono-dev] PATCH: Make Process.Start() use the same
	'mono'	runtime
In-Reply-To: <f41sl0$j9a$1@sea.gmane.org>
References: <30990-68458@sneakemail.com>
	<1180988336.23003.7.camel@erandi.dom>  <f41sl0$j9a$1@sea.gmane.org>
Message-ID: <1180992682.23003.35.camel@erandi.dom>


> > 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 at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


From 2a5gjx302 at sneakemail.com  Mon Jun  4 20:31:51 2007
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: Mon, 04 Jun 2007 19:31:51 -0500
Subject: [Mono-dev] PATCH: Make Process.Start() use the same
	'mono'runtime
In-Reply-To: <f41uce$q0v$1@sea.gmane.org>
References: <1180988880.23003.11.camel@erandi.dom> <30990-68458@sneakemail.com>
	<f41lpr$mdp$1@sea.gmane.org> <1180988880.23003.11.camel@erandi.dom>
Message-ID: <11904-20964@sneakemail.com>

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


From 2a5gjx302 at sneakemail.com  Mon Jun  4 20:37:35 2007
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: Mon, 04 Jun 2007 19:37:35 -0500
Subject: [Mono-dev] PATCH: Make Process.Start() use the same
	'mono'runtime
In-Reply-To: <23a15590706041206p73c79637w6b7c58b886847d6d@mail.gmail.com>
References: <30990-68458@sneakemail.com> <30990-68458@sneakemail.com>
Message-ID: <13748-38482@sneakemail.com>

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


From grendello at gmail.com  Tue Jun  5 06:36:54 2007
From: grendello at gmail.com (Marek Habersack)
Date: Tue, 5 Jun 2007 12:36:54 +0200
Subject: [Mono-dev] New Mono.Data.Sqlite problems with UTF8 conversion
 on Windows
In-Reply-To: <711aea6b0706020927t4c507435gc0d6929ad72a0e36@mail.gmail.com>
References: <711aea6b0706020927t4c507435gc0d6929ad72a0e36@mail.gmail.com>
Message-ID: <20070605123654.12138905@beowulf.thanes.org>

On Sat, 2 Jun 2007 18:27:30 +0200, "Kamil Skalski" <kamil.skalski at gmail.com>
scribbled:

> Hello!
Hello Kamil,

> 
> 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.
I've applied your patch to svn, revision 78615. Thanks.

> 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.
Could you file a bug with a simple test case and assign it to
mhabersack at novell.com? Thanks.

best regards,

marek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070605/d7def499/attachment.bin 

From informatique.internet at fiducial.fr  Tue Jun  5 12:03:34 2007
From: informatique.internet at fiducial.fr (Hubert FONGARNAND)
Date: Tue, 05 Jun 2007 18:03:34 +0200
Subject: [Mono-dev] Log4net RemotingAppender is not working with mono
Message-ID: <1181059414.16078.24.camel@hublinux.fidudev.fr>

with the  RemotingAppender you could log to a centralized remoting
server...

It fails with : Cannot create channel sink to connect to URL

it works with MS.NET 1.1

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

If you take a look at :
http://www.nabble.com/-jira--Created:-(LOG4NET-114)-Unit-tests-only-support-.NET-1.0-t3255315.html

log4net didn't pass the tests with mono especially with
remotingappender, it could be great to fix this issue, because log4net
is widely used in the .NET world!

Thanks

Hubert FONGARNAND

_______________________________________________
Ce message et les ?ventuels documents joints peuvent contenir des informations confidentielles.
Au cas o? il ne vous serait pas destin?, nous vous remercions de bien vouloir le supprimer et en aviser imm?diatement l'exp?diteur. Toute utilisation de ce message non conforme ? sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'?tant pas s?curis?es, l'int?grit? de ce message n'est pas assur?e et la soci?t? ?mettrice ne peut ?tre tenue pour responsable de son contenu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070605/fb12e432/attachment.html 

From miguel at novell.com  Tue Jun  5 00:23:45 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Tue, 05 Jun 2007 00:23:45 -0400
Subject: [Mono-dev] PATCH: Make Process.Start() use the
	same	'mono'runtime
In-Reply-To: <11904-20964@sneakemail.com>
References: <1180988880.23003.11.camel@erandi.dom>
	<30990-68458@sneakemail.com> <f41lpr$mdp$1@sea.gmane.org>
	<1180988880.23003.11.camel@erandi.dom>  <11904-20964@sneakemail.com>
Message-ID: <1181017425.23003.58.camel@erandi.dom>

Hello,

> I still prefer the environment variable approach. Are there any serious
> disadvantages? Here are some additional thoughts:

And I still think that we will use a hardcoded value for the
interpreter.

> - 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().

I think we can keep the code inside CreateProcess,

> - 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. 

Tools to do that can much more easily specify the runtime to use by
calling the specific interpreter instead of depending on yet another
obscure environment variable that if we are remotely lucky will be
documented.

Ie, Process.Start ("mono program.exe") and Process.Start ("clix
program.exe") much easier than setting the environment and then calling
program.exe

> 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.

This is arguably the only possible use for this setup and am not
convinced that supporting the extra feature/bloat is worth it.

> Shall I rework the patch to do the check directly inside
> System.Diagnostics.Process.Start?

I think your current patch is fine, I only ask you for either:

	* Sign a copyright assignment form, so we can get the code
	  in the runtime.

	* License the patch under the MIT X11 code, so we are allowed
	  to relicense it.

Miguel


From meebey at meebey.net  Tue Jun  5 14:15:26 2007
From: meebey at meebey.net (Mirco Bauer)
Date: Tue, 05 Jun 2007 20:15:26 +0200
Subject: [Mono-dev] PATCH: Make Process.Start() use the
	same	'mono'	runtime
In-Reply-To: <1180992682.23003.35.camel@erandi.dom>
References: <30990-68458@sneakemail.com>
	<1180988336.23003.7.camel@erandi.dom>  <f41sl0$j9a$1@sea.gmane.org>
	<1180992682.23003.35.camel@erandi.dom>
Message-ID: <1181067326.6006.3.camel@redbull.qnetp.net>

On Mon, 2007-06-04 at 17:31 -0400, Miguel de Icaza wrote:
> > > 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,

Thats correct, cli is a symlink which points to the best/preferred
installed CLI runtime like mono.

Also the cli symlink is only used for applications that are known to run
on any CLI runtime (that's about none to helloworld.exe)

>  if they dont do that, its not
> our fault, and they should provide a patch just like they patch the
> rest.

Do you believe I am insane and rename mono binaries? *cough*

-- 
Regards,

Mirco 'meebey' Bauer

PGP-Key:
http://keyserver.noreply.org/pks/lookup?op=get&search=0xEEF946C8

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GIT d s-:+ a-- C++ UL++++$ P L++$>+++$ E- W+++$ N o? K- w++>! O---- M-
V? PS
PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G>++ e h! r->++ y?
------END GEEK CODE BLOCK------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070605/16ae2a71/attachment.bin 

From cetin.sert at gmail.com  Tue Jun  5 17:12:54 2007
From: cetin.sert at gmail.com (Cetin Sert)
Date: Tue, 5 Jun 2007 23:12:54 +0200
Subject: [Mono-dev] C# Burstsort for Mono
Message-ID: <4665d1e0.23068f72.5973.1443@mx.google.com>

Hi...

 

Could someone write a burstsort implementation for Mono?
http://www.sf.net/projects/burstsort,
<http://goanna.cs.rmit.edu.au/~jz/fulltext/alenex03.pdf>
http://goanna.cs.rmit.edu.au/~jz/fulltext/alenex03.pdf,
http://www.cs.mu.oz.au/~rsinha/papers/SinhaRingZobel-2006.pdf 

 

Cetin Sert

INF 521, 4-6-2

69120 Heidelberg

Germany

 

http://tenkatext.sourceforge.net/contact

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070605/f22b7f14/attachment.html 

From etil15 at gmail.com  Tue Jun  5 17:29:30 2007
From: etil15 at gmail.com (Manuel de la Pena)
Date: Tue, 5 Jun 2007 22:29:30 +0100
Subject: [Mono-dev] C# Burstsort for Mono
In-Reply-To: <4665d1e0.23068f72.5973.1443@mx.google.com>
References: <4665d1e0.23068f72.5973.1443@mx.google.com>
Message-ID: <453D91DC-EACE-4C99-8F98-0E6AB0CB9064@gmail.com>

Sounds really interesting, I would not  mind to give it a shot unless  
someone else more experienced wants to do it.

On 5 Jun 2007, at 22:12, Cetin Sert wrote:

> Hi...
>
>
>
> Could someone write a burstsort implementation for Mono? http:// 
> www.sf.net/projects/burstsort, http://goanna.cs.rmit.edu.au/~jz/ 
> fulltext/alenex03.pdf, http://www.cs.mu.oz.au/~rsinha/papers/ 
> SinhaRingZobel-2006.pdf
>
>
>
> Cetin Sert
>
> INF 521, 4-6-2
>
> 69120 Heidelberg
>
> Germany
>
>
>
> http://tenkatext.sourceforge.net/contact
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070605/414675ca/attachment.html 

From cetin.sert at gmail.com  Tue Jun  5 18:00:22 2007
From: cetin.sert at gmail.com (Cetin Sert)
Date: Wed, 6 Jun 2007 00:00:22 +0200
Subject: [Mono-dev] C# Burstsort for Mono
In-Reply-To: <453D91DC-EACE-4C99-8F98-0E6AB0CB9064@gmail.com>
References: <4665d1e0.23068f72.5973.1443@mx.google.com>
	<453D91DC-EACE-4C99-8F98-0E6AB0CB9064@gmail.com>
Message-ID: <4665dd07.361ccc18.63ed.563a@mx.google.com>

Thanks for your interest. I would love to be of some help if I could but I
am not all that experienced myself. I'll nevertheless try to come up with
something and let you know if it turns out to be usable.

 

Cetin Sert

INF 521, 4-6-2

69120 Heidelberg

Germany

 

http://tenkatext.sourceforge.net/contact

 

From: Manuel de la Pena [mailto:etil15 at gmail.com] 
Sent: Dienstag, 5. Juni 2007 23:30
To: Cetin Sert
Cc: Mono-devel-list
Subject: Re: [Mono-dev] C# Burstsort for Mono

 

Sounds really interesting, I would not  mind to give it a shot unless
someone else more experienced wants to do it.

 

On 5 Jun 2007, at 22:12, Cetin Sert wrote:





Hi...

 

Could someone write a burstsort implementation for Mono?
http://www.sf.net/projects/burstsort,
<http://goanna.cs.rmit.edu.au/~jz/fulltext/alenex03.pdf>
http://goanna.cs.rmit.edu.au/~jz/fulltext/alenex03.pdf,
http://www.cs.mu.oz.au/~rsinha/papers/SinhaRingZobel-2006.pdf 

 

Cetin Sert

INF 521, 4-6-2

69120 Heidelberg

Germany

 

http://tenkatext.sourceforge.net/contact

 

_______________________________________________

Mono-devel-list mailing list

Mono-devel-list at lists.ximian.com

http://lists.ximian.com/mailman/listinfo/mono-devel-list

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070606/559a47bd/attachment.html 

From 2a5gjx302 at sneakemail.com  Wed Jun  6 02:22:26 2007
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: Wed, 06 Jun 2007 01:22:26 -0500
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <1181017425.23003.58.camel@erandi.dom>
References: <11904-20964@sneakemail.com> <1180988880.23003.11.camel@erandi.dom>
	<30990-68458@sneakemail.com> <f41lpr$mdp$1@sea.gmane.org>
	<1180988880.23003.11.camel@erandi.dom> <11904-20964@sneakemail.com>
Message-ID: <29828-16732@sneakemail.com>

At 12:23 AM 6/5/2007 -0400, Miguel de Icaza wrote:
>Hello,
>
>> I still prefer the environment variable approach. Are there any serious
>> disadvantages? Here are some additional thoughts:
>
>And I still think that we will use a hardcoded value for the
>interpreter.

This makes having 'mono' in $PATH an official requirement for mono to
operate correctly...

>> - 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().
>
>I think we can keep the code inside CreateProcess,

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.)

>> - 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. 
>
>Tools to do that can much more easily specify the runtime to use by
>calling the specific interpreter instead of depending on yet another
>obscure environment variable that if we are remotely lucky will be
>documented.
>
>Ie, Process.Start ("mono program.exe") and Process.Start ("clix
>program.exe") much easier than setting the environment and then calling
>program.exe

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.

>> Shall I rework the patch to do the check directly inside
>> System.Diagnostics.Process.Start?
>
>I think your current patch is fine, I only ask you for either:
>
>	* Sign a copyright assignment form, so we can get the code
>	  in the runtime.
>
>	* License the patch under the MIT X11 code, so we are allowed
>	  to relicense it.

The code in both patches is hereby officially licensed under the terms of
the MIT X11 license. :-)

Enjoy,

Jonathan Gilbert

The below is for review only; please use the attached gzip when applying
the patch to your local source tree.

Index: class/System/System.Diagnostics/Process.cs
===================================================================
--- mcs/class/System/System.Diagnostics/Process.cs	(revision 78469)
+++ mcs/class/System/System.Diagnostics/Process.cs	(working copy)
@@ -248,6 +248,11 @@
 		private extern static bool SetWorkingSet_internal(IntPtr handle, int
min, int max, bool use_min);
 
 		/* LAMESPEC: why is this an IntPtr not a plain int? */
+		/* One might speculate that on Windows, the API call
+		 * used by MS.NET takes a 32-bit integer on 32-bit
+		 * platforms and a 64-bit integer on 64-bit platforms.
+		 * An IntPtr thereby automatically marshals correctly.
+		 */
 		[DesignerSerializationVisibility (DesignerSerializationVisibility.Hidden)]
 		[MonitoringDescription ("The maximum working set for this process.")]
 		public IntPtr MaxWorkingSet {
@@ -725,7 +730,7 @@
 		[MethodImplAttribute(MethodImplOptions.InternalCall)]
 		extern static bool Kill_internal (IntPtr handle, int signo);
 
-		/* int kill -> 1 KILL, 2 CloseMainWindow */
+		/* int signo -> 1 KILL, 2 CloseMainWindow */
 		bool Close (int signo)
 		{
 			if (process_handle == IntPtr.Zero)
@@ -869,6 +874,293 @@
 								  IntPtr stderr,
 								  ref ProcInfo proc_info);
 
+		private static string shell_quote (string str)
+		{
+			StringBuilder ret = null;
+
+			for (int i=0; i < str.Length; i++) {
+				switch (str [i])
+				{
+					case '!':
+					case '\'':
+					case '\\':
+					{
+						if (ret == null) {
+							ret = new StringBuilder ("'");
+							ret.Append (str, 0, i);
+						}
+
+						ret.Append ('\\').Append (str, i, 1);
+
+						break;
+					}
+					default:
+					{
+						if (ret != null) {
+							ret.Append (str, i, 1);
+						}
+
+						break;
+					}
+				}
+			}
+
+			if (ret != null)
+				return ret.Append ('\'').ToString ();
+			else
+				return str;
+		}
+
+		private static string unshellquote_extract_first_word (ref string args)
+		{
+			StringBuilder ret = new StringBuilder ();
+
+			int idx = 0;
+			while (idx < args.Length) {
+				// If we've found the first whitespace dividing off the first word
+				// from the rest of the string, stop here, and update 'args' to
+				// match what we've pulled off so far.
+				if (char.IsWhiteSpace (args, idx)) {
+					args = args.Substring (idx + 1);
+					idx = 0;
+					break;
+				}
+
+				switch (args [idx])
+				{
+					case '\'':
+					case '"':
+					{
+						char end_char = args [idx];
+
+						idx++;
+
+						while ((idx < args.Length)
+						    && (args[idx] != end_char)) {
+							if (args[idx] == '\\') {
+								idx++;
+								if (idx >= args.Length) {
+									break;
+								}
+							}
+
+							ret.Append (args, idx, 1);
+
+							idx++;
+						}
+
+						idx++;
+
+						break;
+					}
+					case '`':
+					{
+						// If the user is asking the shell to insert the output
+						// of another command to find out what this command is
+						// going to be, we give up. Sorry :-)
+						return null;
+					}
+					default:
+					{
+						if (args[idx] == '\\') {
+							idx++;
+							if (idx >= args.Length) {
+								break;
+							}
+						}
+
+						ret.Append (args, idx, 1);
+						idx++;
+
+						break;
+					}
+				}
+			}
+
+			// If we hit the end of the string before finding a word boundary,
+			// then there are no arguments after the first word.
+			if (idx >= args.Length)
+				args = null;
+
+			return ret.ToString();
+		}
+
+		private static bool is_managed_binary (string filename)
+		{
+			try
+			{
+#if NET_2_0
+				using (FileStream stream = new FileStream (filename, FileMode.Open,
FileAccess.Read, FileShare.ReadWrite | FileShare.Delete))
+#else
+				using (FileStream stream = new FileStream (filename, FileMode.Open,
FileAccess.Read, FileShare.ReadWrite))
+#endif
+				{
+					// We know we need to read a header field at offset 60.
+					if (stream.Length < 64)
+						return false;
+
+					byte[] buffer = new byte[8];
+					int num_read;
+
+					// Verify the MZ executable signature word.
+					num_read = stream.Read (buffer, 0, 2);
+
+					if ((num_read != 2)
+					 || (buffer[0] != (byte)'M')
+					 || (buffer[1] != (byte)'Z'))
+						return false;
+
+					// Get the offset of the PE header.
+					stream.Position = 60;
+
+					num_read = stream.Read (buffer, 0, 4);
+
+					if (num_read != 4)
+						return false;
+
+					int pe_header_offset = BitConverter.ToInt32 (buffer, 0);
+
+					if (pe_header_offset + 24 > stream.Length)
+						return false;
+
+					// Verify that the header we've found is in fact the PE header.
+					stream.Position = pe_header_offset;
+
+					num_read = stream.Read (buffer, 0, 4);
+
+					if ((num_read != 4)
+					 || (buffer[0] != (byte)'P')
+					 || (buffer[1] != (byte)'E')
+					 || (buffer[2] != 0)
+					 || (buffer[3] != 0))
+						return false;
+
+					// Verify that the header we want in the optional header data
+					// is present in this binary.
+					stream.Position = pe_header_offset + 20;
+
+					num_read = stream.Read (buffer, 0, 2);
+
+					if ((num_read != 2)
+					 || (BitConverter.ToInt16 (buffer, 0) < 216))
+						return false;
+
+					// Read the CLR header address and size fields. These will be
+					// zero if the binary is not managed.
+					int optional_header_offset = pe_header_offset + 24;
+
+					stream.Position = optional_header_offset + 208;
+
+					num_read = stream.Read (buffer, 0, 8);
+
+					// We are not concerned with endianness, only with
+					// whether it is zero or not.
+					int first_word = BitConverter.ToInt32 (buffer, 0);
+					int second_word = BitConverter.ToInt32 (buffer, 4);
+
+					if ((num_read != 8)
+					 || (first_word == 0)
+					 || (second_word == 0))
+						return false;
+
+					// If we get here without cacking, then in all likelihood
+					// we're looking at a CLR binary!
+					return true;
+				}
+			}
+			catch
+			{
+				// If anything at all goes wrong, then we cannot say that
+				// it is a managed binary.
+				return false;
+			}
+		}
+
+		private static ProcessStartInfo redirect_for_managed_binary
(ProcessStartInfo start_info)
+		{
+			// Check if we have a MONOEXECUTABLE environment variable. If
+			// we don't, then there is no redirection to be done.
+			string mono_executable =
Environment.GetEnvironmentVariable("MONOEXECUTABLE");
+
+			if (mono_executable == null)
+				return start_info;
+
+			// Determine the target executable and the arguments being passed to it.
+			string application_filename = null, args = null;
+
+			if (start_info.FileName != null) {
+				application_filename = start_info.FileName;
+
+				if ((start_info.Arguments != null)
+				 && (start_info.Arguments.Trim().Length > 0)) {
+					args = start_info.Arguments;
+				}
+
+				// Fall back on treating the filename as the entire command-line
+				// if it is not (only) the name of an existing file.
+				if (!File.Exists (application_filename)) {
+					if (args != null) {
+						args = application_filename + ' ' + args;
+					} else {
+						args = application_filename;
+					}
+
+					application_filename = unshellquote_extract_first_word (ref args);
+				}
+			} else if (start_info.Arguments != null) {
+				args = start_info.Arguments.TrimStart();
+
+				application_filename = unshellquote_extract_first_word (ref args);
+			}
+
+			if (application_filename == null) {
+				return start_info;
+			}
+
+			bool need_redirect = is_managed_binary (application_filename);
+
+			// Determine whether we need a redirection.
+			if (!need_redirect) {
+				return start_info;
+			}
+
+			// If we need a redirection, build a new ProcessStartInfo and
+			// then alter just the parts we need. Otherwise, just return
+			// what we were passed.
+
+			ProcessStartInfo redirected = new ProcessStartInfo ();
+
+			// Copy over all of the values.
+			redirected.CreateNoWindow = start_info.CreateNoWindow;
+			redirected.ErrorDialog = start_info.ErrorDialog;
+			redirected.ErrorDialogParentHandle = start_info.ErrorDialogParentHandle;
+			redirected.RedirectStandardError = start_info.RedirectStandardError;
+			redirected.RedirectStandardInput = start_info.RedirectStandardInput;
+			redirected.RedirectStandardOutput = start_info.RedirectStandardOutput;
+			redirected.UseShellExecute = start_info.UseShellExecute;
+			redirected.Verb = start_info.Verb;
+			redirected.WindowStyle = start_info.WindowStyle;
+			redirected.WorkingDirectory = start_info.WorkingDirectory;
+
+			if (start_info.HaveEnvVars) {
+				foreach (DictionaryEntry variable in start_info.EnvironmentVariables) {
+					redirected.EnvironmentVariables [variable.Key.ToString()] =
variable.Value.ToString ();
+				}
+			}
+
+			// Set up the redirected ProcessStartInfo to run the
+			// application binary using the value of MONOEXECUTABLE.
+			redirected.FileName = mono_executable;
+
+			if (args != null) {
+				redirected.Arguments = shell_quote(application_filename) + ' ' + args;
+			} else {
+				redirected.Arguments = shell_quote(application_filename);
+			}
+
+			return redirected;
+		}
+
 		private static bool Start_shell (ProcessStartInfo startInfo,
 						 Process process)
 		{
@@ -885,7 +1177,7 @@
 				throw new InvalidOperationException ("UseShellExecute must be false in
order to use environment variables.");
 			}
 
-			ret = ShellExecuteEx_internal (startInfo,
+			ret = ShellExecuteEx_internal (redirect_for_managed_binary (startInfo),
 						       ref proc_info);
 			if (!ret) {
 				throw new Win32Exception (-proc_info.pid);
@@ -978,7 +1270,7 @@
 				stderr_wr = MonoIO.ConsoleError;
 			}
 			
-			ret = CreateProcess_internal (startInfo,
+			ret = CreateProcess_internal (redirect_for_managed_binary (startInfo),
 						      stdin_rd, stdout_wr, stderr_wr,
 						      ref proc_info);
 			if (!ret) {

Index: mono/mono/mini/driver.c
===================================================================
--- mono/mono/mini/driver.c	(revision 78469)
+++ mono/mono/mini/driver.c	(working copy)
@@ -49,6 +49,7 @@
 #include "inssel.h"
 #include <locale.h>
 #include "version.h"
+#include <glib.h>
 
 static FILE *mini_stats_fd = NULL;
 
@@ -671,6 +672,14 @@
 	"\tDisabled:      " DISABLED_FEATURES "\n"
 	"";
 
+/*
+ * If your platform lacks setenv/unsetenv, you must upgrade your glib.
+ */
+#if !GLIB_CHECK_VERSION(2,4,0)
+#define g_setenv(a,b,c)   setenv(a,b,c)
+#define g_unsetenv(a) unsetenv(a)
+#endif
+
 int
 mono_main (int argc, char* argv[])
 {
@@ -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);
+
 	opt = parse_optimizations (NULL);
 
 	for (i = 1; i < argc; ++i) {
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProcessStartFixManaged.diff.gz
Type: application/octet-stream
Size: 3511 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070606/9a065770/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProcessStartFixBoth.diff.gz
Type: application/octet-stream
Size: 4676 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070606/9a065770/attachment-0001.obj 

From tomasz.kubacki at gmail.com  Wed Jun  6 02:48:08 2007
From: tomasz.kubacki at gmail.com (Tomasz Kubacki)
Date: Wed, 6 Jun 2007 08:48:08 +0200
Subject: [Mono-dev] mono compile error
Message-ID: <d4da15310706052348x13877367n58891d62f5177f93@mail.gmail.com>

hello,

Since few days i'can't compile mono from svn head due to ...
-------cut-----------------
*** The compiler 'mcs' doesn't appear to be usable.
*** Trying the 'monolite' directory.
make[7]: Wej?cie do katalogu `/home/tomek/mono/mcs'
Corlib not in sync with this runtime: expected corlib version 56, found 57.
Download a newer corlib or a newer runtime at http://www.go-mono.com/daily.
-------cut----------------

i used to compile new version of mono this way:

make clean;./autogen.sh --prefix=/usr/local/mono/;make
get-monolite-latest;make

so monolite IS in the latest version.

regards,

Tomasz Kubacki

From lupus at ximian.com  Wed Jun  6 09:49:23 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Wed, 6 Jun 2007 15:49:23 +0200
Subject: [Mono-dev] mono compile error
In-Reply-To: <d4da15310706052348x13877367n58891d62f5177f93@mail.gmail.com>
References: <d4da15310706052348x13877367n58891d62f5177f93@mail.gmail.com>
Message-ID: <20070606134923.GS4081@debian.org>

On 06/06/07 Tomasz Kubacki wrote:
> Since few days i'can't compile mono from svn head due to ...
> -------cut-----------------
> *** The compiler 'mcs' doesn't appear to be usable.
> *** Trying the 'monolite' directory.
> make[7]: Wej??cie do katalogu `/home/tomek/mono/mcs'
> Corlib not in sync with this runtime: expected corlib version 56, found 57.
> Download a newer corlib or a newer runtime at http://www.go-mono.com/daily.
> -------cut----------------
> 
> i used to compile new version of mono this way:
> 
> make clean;./autogen.sh --prefix=/usr/local/mono/;make
> get-monolite-latest;make

get-monolite-latest should never be used as it is a completely
unreliable way to fix this issue. Get a mono tarball and build and
install it instead (as the README says).

lupus

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


From lupus at ximian.com  Wed Jun  6 10:39:02 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Wed, 6 Jun 2007 16:39:02 +0200
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <29828-16732@sneakemail.com>
References: <11904-20964@sneakemail.com> <1180988880.23003.11.camel@erandi.dom>
	<30990-68458@sneakemail.com> <f41lpr$mdp$1@sea.gmane.org>
	<1180988880.23003.11.camel@erandi.dom>
	<11904-20964@sneakemail.com> <29828-16732@sneakemail.com>
Message-ID: <20070606143902.GT4081@debian.org>

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

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


From miguel at novell.com  Wed Jun  6 11:14:16 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Wed, 06 Jun 2007 11:14:16 -0400
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <29828-16732@sneakemail.com>
References: <11904-20964@sneakemail.com>
	<1180988880.23003.11.camel@erandi.dom> <30990-68458@sneakemail.com>
	<f41lpr$mdp$1@sea.gmane.org> <1180988880.23003.11.camel@erandi.dom>
	<11904-20964@sneakemail.com>  <29828-16732@sneakemail.com>
Message-ID: <1181142856.14511.29.camel@erandi.dom>

Hello,

> This makes having 'mono' in $PATH an official requirement for mono to
> operate correctly...

This is already a dependency anyways (CodeDOM and anything that uses
CodeDOM for example).

> 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.)

Thanks, I'll investigate, but I rather have it in unmanaged land as it
will likely create less managed objects.

> 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.

This one can go both ways, what if you really want to use .NET?

Introducing (a new one, in addition to the current one) environment
variable is not my idea of the code I want to maintain.

> The code in both patches is hereby officially licensed under the terms of
> the MIT X11 license. :-)

Thanks!

> Enjoy,
> 
> Jonathan Gilbert
> 
> The below is for review only; please use the attached gzip when applying
> the patch to your local source tree.
> 
> Index: class/System/System.Diagnostics/Process.cs
> ===================================================================
> --- mcs/class/System/System.Diagnostics/Process.cs	(revision 78469)
> +++ mcs/class/System/System.Diagnostics/Process.cs	(working copy)
> @@ -248,6 +248,11 @@
>  		private extern static bool SetWorkingSet_internal(IntPtr handle, int
> min, int max, bool use_min);
>  
>  		/* LAMESPEC: why is this an IntPtr not a plain int? */
> +		/* One might speculate that on Windows, the API call
> +		 * used by MS.NET takes a 32-bit integer on 32-bit
> +		 * platforms and a 64-bit integer on 64-bit platforms.
> +		 * An IntPtr thereby automatically marshals correctly.
> +		 */
>  		[DesignerSerializationVisibility (DesignerSerializationVisibility.Hidden)]
>  		[MonitoringDescription ("The maximum working set for this process.")]
>  		public IntPtr MaxWorkingSet {
> @@ -725,7 +730,7 @@
>  		[MethodImplAttribute(MethodImplOptions.InternalCall)]
>  		extern static bool Kill_internal (IntPtr handle, int signo);
>  
> -		/* int kill -> 1 KILL, 2 CloseMainWindow */
> +		/* int signo -> 1 KILL, 2 CloseMainWindow */
>  		bool Close (int signo)
>  		{
>  			if (process_handle == IntPtr.Zero)
> @@ -869,6 +874,293 @@
>  								  IntPtr stderr,
>  								  ref ProcInfo proc_info);
>  
> +		private static string shell_quote (string str)
> +		{
> +			StringBuilder ret = null;
> +
> +			for (int i=0; i < str.Length; i++) {
> +				switch (str [i])
> +				{
> +					case '!':
> +					case '\'':
> +					case '\\':
> +					{
> +						if (ret == null) {
> +							ret = new StringBuilder ("'");
> +							ret.Append (str, 0, i);
> +						}
> +
> +						ret.Append ('\\').Append (str, i, 1);
> +
> +						break;
> +					}
> +					default:
> +					{
> +						if (ret != null) {
> +							ret.Append (str, i, 1);
> +						}
> +
> +						break;
> +					}
> +				}
> +			}
> +
> +			if (ret != null)
> +				return ret.Append ('\'').ToString ();
> +			else
> +				return str;
> +		}
> +
> +		private static string unshellquote_extract_first_word (ref string args)
> +		{
> +			StringBuilder ret = new StringBuilder ();
> +
> +			int idx = 0;
> +			while (idx < args.Length) {
> +				// If we've found the first whitespace dividing off the first word
> +				// from the rest of the string, stop here, and update 'args' to
> +				// match what we've pulled off so far.
> +				if (char.IsWhiteSpace (args, idx)) {
> +					args = args.Substring (idx + 1);
> +					idx = 0;
> +					break;
> +				}
> +
> +				switch (args [idx])
> +				{
> +					case '\'':
> +					case '"':
> +					{
> +						char end_char = args [idx];
> +
> +						idx++;
> +
> +						while ((idx < args.Length)
> +						    && (args[idx] != end_char)) {
> +							if (args[idx] == '\\') {
> +								idx++;
> +								if (idx >= args.Length) {
> +									break;
> +								}
> +							}
> +
> +							ret.Append (args, idx, 1);
> +
> +							idx++;
> +						}
> +
> +						idx++;
> +
> +						break;
> +					}
> +					case '`':
> +					{
> +						// If the user is asking the shell to insert the output
> +						// of another command to find out what this command is
> +						// going to be, we give up. Sorry :-)
> +						return null;
> +					}
> +					default:
> +					{
> +						if (args[idx] == '\\') {
> +							idx++;
> +							if (idx >= args.Length) {
> +								break;
> +							}
> +						}
> +
> +						ret.Append (args, idx, 1);
> +						idx++;
> +
> +						break;
> +					}
> +				}
> +			}
> +
> +			// If we hit the end of the string before finding a word boundary,
> +			// then there are no arguments after the first word.
> +			if (idx >= args.Length)
> +				args = null;
> +
> +			return ret.ToString();
> +		}
> +
> +		private static bool is_managed_binary (string filename)
> +		{
> +			try
> +			{
> +#if NET_2_0
> +				using (FileStream stream = new FileStream (filename, FileMode.Open,
> FileAccess.Read, FileShare.ReadWrite | FileShare.Delete))
> +#else
> +				using (FileStream stream = new FileStream (filename, FileMode.Open,
> FileAccess.Read, FileShare.ReadWrite))
> +#endif
> +				{
> +					// We know we need to read a header field at offset 60.
> +					if (stream.Length < 64)
> +						return false;
> +
> +					byte[] buffer = new byte[8];
> +					int num_read;
> +
> +					// Verify the MZ executable signature word.
> +					num_read = stream.Read (buffer, 0, 2);
> +
> +					if ((num_read != 2)
> +					 || (buffer[0] != (byte)'M')
> +					 || (buffer[1] != (byte)'Z'))
> +						return false;
> +
> +					// Get the offset of the PE header.
> +					stream.Position = 60;
> +
> +					num_read = stream.Read (buffer, 0, 4);
> +
> +					if (num_read != 4)
> +						return false;
> +
> +					int pe_header_offset = BitConverter.ToInt32 (buffer, 0);
> +
> +					if (pe_header_offset + 24 > stream.Length)
> +						return false;
> +
> +					// Verify that the header we've found is in fact the PE header.
> +					stream.Position = pe_header_offset;
> +
> +					num_read = stream.Read (buffer, 0, 4);
> +
> +					if ((num_read != 4)
> +					 || (buffer[0] != (byte)'P')
> +					 || (buffer[1] != (byte)'E')
> +					 || (buffer[2] != 0)
> +					 || (buffer[3] != 0))
> +						return false;
> +
> +					// Verify that the header we want in the optional header data
> +					// is present in this binary.
> +					stream.Position = pe_header_offset + 20;
> +
> +					num_read = stream.Read (buffer, 0, 2);
> +
> +					if ((num_read != 2)
> +					 || (BitConverter.ToInt16 (buffer, 0) < 216))
> +						return false;
> +
> +					// Read the CLR header address and size fields. These will be
> +					// zero if the binary is not managed.
> +					int optional_header_offset = pe_header_offset + 24;
> +
> +					stream.Position = optional_header_offset + 208;
> +
> +					num_read = stream.Read (buffer, 0, 8);
> +
> +					// We are not concerned with endianness, only with
> +					// whether it is zero or not.
> +					int first_word = BitConverter.ToInt32 (buffer, 0);
> +					int second_word = BitConverter.ToInt32 (buffer, 4);
> +
> +					if ((num_read != 8)
> +					 || (first_word == 0)
> +					 || (second_word == 0))
> +						return false;
> +
> +					// If we get here without cacking, then in all likelihood
> +					// we're looking at a CLR binary!
> +					return true;
> +				}
> +			}
> +			catch
> +			{
> +				// If anything at all goes wrong, then we cannot say that
> +				// it is a managed binary.
> +				return false;
> +			}
> +		}
> +
> +		private static ProcessStartInfo redirect_for_managed_binary
> (ProcessStartInfo start_info)
> +		{
> +			// Check if we have a MONOEXECUTABLE environment variable. If
> +			// we don't, then there is no redirection to be done.
> +			string mono_executable =
> Environment.GetEnvironmentVariable("MONOEXECUTABLE");
> +
> +			if (mono_executable == null)
> +				return start_info;
> +
> +			// Determine the target executable and the arguments being passed to it.
> +			string application_filename = null, args = null;
> +
> +			if (start_info.FileName != null) {
> +				application_filename = start_info.FileName;
> +
> +				if ((start_info.Arguments != null)
> +				 && (start_info.Arguments.Trim().Length > 0)) {
> +					args = start_info.Arguments;
> +				}
> +
> +				// Fall back on treating the filename as the entire command-line
> +				// if it is not (only) the name of an existing file.
> +				if (!File.Exists (application_filename)) {
> +					if (args != null) {
> +						args = application_filename + ' ' + args;
> +					} else {
> +						args = application_filename;
> +					}
> +
> +					application_filename = unshellquote_extract_first_word (ref args);
> +				}
> +			} else if (start_info.Arguments != null) {
> +				args = start_info.Arguments.TrimStart();
> +
> +				application_filename = unshellquote_extract_first_word (ref args);
> +			}
> +
> +			if (application_filename == null) {
> +				return start_info;
> +			}
> +
> +			bool need_redirect = is_managed_binary (application_filename);
> +
> +			// Determine whether we need a redirection.
> +			if (!need_redirect) {
> +				return start_info;
> +			}
> +
> +			// If we need a redirection, build a new ProcessStartInfo and
> +			// then alter just the parts we need. Otherwise, just return
> +			// what we were passed.
> +
> +			ProcessStartInfo redirected = new ProcessStartInfo ();
> +
> +			// Copy over all of the values.
> +			redirected.CreateNoWindow = start_info.CreateNoWindow;
> +			redirected.ErrorDialog = start_info.ErrorDialog;
> +			redirected.ErrorDialogParentHandle = start_info.ErrorDialogParentHandle;
> +			redirected.RedirectStandardError = start_info.RedirectStandardError;
> +			redirected.RedirectStandardInput = start_info.RedirectStandardInput;
> +			redirected.RedirectStandardOutput = start_info.RedirectStandardOutput;
> +			redirected.UseShellExecute = start_info.UseShellExecute;
> +			redirected.Verb = start_info.Verb;
> +			redirected.WindowStyle = start_info.WindowStyle;
> +			redirected.WorkingDirectory = start_info.WorkingDirectory;
> +
> +			if (start_info.HaveEnvVars) {
> +				foreach (DictionaryEntry variable in start_info.EnvironmentVariables) {
> +					redirected.EnvironmentVariables [variable.Key.ToString()] =
> variable.Value.ToString ();
> +				}
> +			}
> +
> +			// Set up the redirected ProcessStartInfo to run the
> +			// application binary using the value of MONOEXECUTABLE.
> +			redirected.FileName = mono_executable;
> +
> +			if (args != null) {
> +				redirected.Arguments = shell_quote(application_filename) + ' ' + args;
> +			} else {
> +				redirected.Arguments = shell_quote(application_filename);
> +			}
> +
> +			return redirected;
> +		}
> +
>  		private static bool Start_shell (ProcessStartInfo startInfo,
>  						 Process process)
>  		{
> @@ -885,7 +1177,7 @@
>  				throw new InvalidOperationException ("UseShellExecute must be false in
> order to use environment variables.");
>  			}
>  
> -			ret = ShellExecuteEx_internal (startInfo,
> +			ret = ShellExecuteEx_internal (redirect_for_managed_binary (startInfo),
>  						       ref proc_info);
>  			if (!ret) {
>  				throw new Win32Exception (-proc_info.pid);
> @@ -978,7 +1270,7 @@
>  				stderr_wr = MonoIO.ConsoleError;
>  			}
>  			
> -			ret = CreateProcess_internal (startInfo,
> +			ret = CreateProcess_internal (redirect_for_managed_binary (startInfo),
>  						      stdin_rd, stdout_wr, stderr_wr,
>  						      ref proc_info);
>  			if (!ret) {
> 
> Index: mono/mono/mini/driver.c
> ===================================================================
> --- mono/mono/mini/driver.c	(revision 78469)
> +++ mono/mono/mini/driver.c	(working copy)
> @@ -49,6 +49,7 @@
>  #include "inssel.h"
>  #include <locale.h>
>  #include "version.h"
> +#include <glib.h>
>  
>  static FILE *mini_stats_fd = NULL;
>  
> @@ -671,6 +672,14 @@
>  	"\tDisabled:      " DISABLED_FEATURES "\n"
>  	"";
>  
> +/*
> + * If your platform lacks setenv/unsetenv, you must upgrade your glib.
> + */
> +#if !GLIB_CHECK_VERSION(2,4,0)
> +#define g_setenv(a,b,c)   setenv(a,b,c)
> +#define g_unsetenv(a) unsetenv(a)
> +#endif
> +
>  int
>  mono_main (int argc, char* argv[])
>  {
> @@ -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);
> +
>  	opt = parse_optimizations (NULL);
>  
>  	for (i = 1; i < argc; ++i) {
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


From tracker1_lists at theroughnecks.com  Wed Jun  6 12:41:01 2007
From: tracker1_lists at theroughnecks.com (Michael J. Ryan)
Date: Wed, 06 Jun 2007 09:41:01 -0700
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <20070606143902.GT4081@debian.org>
References: <11904-20964@sneakemail.com>
	<1180988880.23003.11.camel@erandi.dom>	<30990-68458@sneakemail.com>
	<f41lpr$mdp$1@sea.gmane.org>	<1180988880.23003.11.camel@erandi.dom>	<11904-20964@sneakemail.com>
	<29828-16732@sneakemail.com> <20070606143902.GT4081@debian.org>
Message-ID: <4666E39D.1090704@theroughnecks.com>

Paolo Molaro wrote:
> 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.

And if the assembly (.exe) and the child process are written in windows, for 
MS.Net, but testing under mono?  I would expect that a managed exe, launching 
another managed exe would execute under the same framework...  Just my $.02

I'm just saying that I wouldn't expect to have to include mono... if that is 
the case I would have to do compiler directives to differentiate between mono, 
and ms.net.. on top of that, I would have to create separate executables for 
use with mono vs. ms.net .... I wouldn't want to, or expect to, have to do that.

-- 
Michael J. Ryan - tracker1(at)theroughnecks(dot)com - www.theroughnecks.net
icq: 4935386  -  AIM/AOL: azTracker1  -  Y!: azTracker1  -  MSN/Win: (email)

... Ferengi Rule of Acquisition #159:  The customer is always right ... until 
you have their cash



From neilcawse at geotab.com  Wed Jun  6 13:51:17 2007
From: neilcawse at geotab.com (Neil Cawse)
Date: Wed, 6 Jun 2007 13:51:17 -0400
Subject: [Mono-dev] Patch for SqlCommand
Message-ID: <CBD431B4860DD747819D5274E5F1DE5D36E88C99BA@server5.GEOTAB.local>

At the moment SqlCommand is broken in our application from a recent commit.

SqlDataReader is internally constructed with the SqlCommand that created it.
The close method of SqlDataReader relies on the fact that the connection for a command still exists:
command.Connection.DataReader = null
A previous commit sets this to null in the SqlCommand.Dispose

There may be better fixed with some re-architecture - not sure..

Index: /home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs
===================================================================
--- /home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs    (revision 78769)
+++ /home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs    (working copy)
@@ -582,7 +582,6 @@
                      if (disposing) {
                             parameters.Clear();
                             transaction = null;
-                            connection = null;
                      }
                      disposed = true;
               }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070606/e12d56b2/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SqlCommand.patch
Type: application/octet-stream
Size: 649 bytes
Desc: SqlCommand.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070606/e12d56b2/attachment.obj 

From lupus at ximian.com  Wed Jun  6 13:36:05 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Wed, 6 Jun 2007 19:36:05 +0200
Subject: [Mono-dev] Dictionary`2: optimized and serialization-compatible
	with MS.net
In-Reply-To: <1180630966.3118.86.camel@leonardo.hotfeet.ch>
References: <1180630966.3118.86.camel@leonardo.hotfeet.ch>
Message-ID: <20070606173605.GU4081@debian.org>

On 05/31/07 Juraj Skripsky wrote:
> Index: System.Collections.Generic/Dictionary.cs
> ===================================================================
> --- System.Collections.Generic/Dictionary.cs	(revision 78207)
> +++ System.Collections.Generic/Dictionary.cs	(working copy)

The change looks fine overall.
A few questions: did you have a measurable speedup by keeping the
hashcode around (if you tested with that case)?
Could you also experiment with separate key and value arrays
(it would help a lot for the cases where one of the two is not a
reference during GC)?
It would also be nice to try a variation with a 0 NO_SLOT value, because
it means you don't have to spend time initializing it (and it would mean
starting allocations of slots at 1 or adding compensation code, though).

Thanks!

lupus

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


From amc1999 at gmail.com  Wed Jun  6 14:36:33 2007
From: amc1999 at gmail.com (Amc Gmail)
Date: Wed, 6 Jun 2007 14:36:33 -0400
Subject: [Mono-dev] Patch for SqlCommand
In-Reply-To: <CBD431B4860DD747819D5274E5F1DE5D36E88C99BA@server5.GEOTAB.local>
References: <CBD431B4860DD747819D5274E5F1DE5D36E88C99BA@server5.GEOTAB.local>
Message-ID: <48a304b00706061136i745c8614w405ec2bc6610d56c@mail.gmail.com>

IMHO, we just need to remove from SqlDataReader Close() unnecessary line:
        command.Connection.DataReader = null;
because right after this we have
        command.CloseDataReader (moreResults);
which doing same things at the beginning of  CloseDataReader():
        Connection.DataReader = null;

Sorry, i can't test this today, it would be really nice if someone can
verify it.

also in SqlCommand.Dispose(), OdbcCommand.Dispose() and some other
places call of
    base.Dispose (disposing);
may be a good idea. without it Disposed events seems to be not going through.
regards,
amc




On 6/6/07, Neil Cawse <neilcawse at geotab.com> wrote:
>
>
>
>
> At the moment SqlCommand is broken in our application from a recent commit.
>
>
>
> SqlDataReader is internally constructed with the SqlCommand that created it.
>
> The close method of SqlDataReader relies on the fact that the connection for
> a command still exists:
>
> command.Connection.DataReader = null
>
> A previous commit sets this to null in the SqlCommand.Dispose
>
>
>
> There may be better fixed with some re-architecture ? not sure..
>
>
>
> Index:
> /home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs
>
> ===================================================================
>
> ---
> /home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs
>    (revision 78769)
>
> +++
> /home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs
>    (working copy)
>
> @@ -582,7 +582,6 @@
>
>                       if (disposing) {
>
>                              parameters.Clear();
>
>                              transaction = null;
>
> -                            connection = null;
>
>                       }
>
>                       disposed = true;
>
>                }
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>


From 2a5gjx302 at sneakemail.com  Wed Jun  6 15:56:07 2007
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: Wed, 06 Jun 2007 14:56:07 -0500
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <20070606143902.GT4081@debian.org>
References: <29828-16732@sneakemail.com> <11904-20964@sneakemail.com>
	<1180988880.23003.11.camel@erandi.dom> <30990-68458@sneakemail.com>
	<f41lpr$mdp$1@sea.gmane.org> <1180988880.23003.11.camel@erandi.dom>
	<11904-20964@sneakemail.com> <29828-16732@sneakemail.com>
Message-ID: <19310-39525@sneakemail.com>

At 04:39 PM 6/6/2007 +0200, Paolo Molaro wrote:
>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...).

I see.

>> 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.

I just ran a performance test. The unmanaged implementation adds about 1
second for every 100,000 child processes. Even the managed version, which
is, as expected, a lot slower, it adds less than 5 seconds for every 10,000
child processes. In what situation would this be a severe and noticeable
penalty? Surely the overhead of actually setting up a 10,000 child
processes totally eclipses a 5 second penalty.

>> 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.

Well I've never had that basic expectation. I've always felt that the same
runtime should be used for all child processes of a managed process, and
there are some practical reasons beyond the symmetry of it. For one thing,
while remoting is compatible, it is not perfect. Mono<->mono is guaranteed
to work, but Mono<->MS.NET continues to have issues for a number of the
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.

>> +	if ((argv [0] != NULL) && (argv [0] [0] != 0))
>> +		g_setenv ("MONOEXECUTABLE", argv [0], TRUE);
>> +
>
>argc can be 0 and this can cause a segfault.

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

>If we use anything like this the env var name should be MONO_EXECUTABLE.

Paint that bikeshed whatever colour you like.

>That said, the code to get the mono binary is not correct (argv[0]
>can be anything).

Sure, but in 99.9% of situations, it will be something that the shell can
resolve to the same binary that launched the current process. The
situations where it does not are user-error situations, where people are
doing odd things probably intentionally.

>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?

Jonathan Gilbert


From miguel at novell.com  Wed Jun  6 17:18:34 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Wed, 06 Jun 2007 17:18:34 -0400
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <19310-39525@sneakemail.com>
References: <29828-16732@sneakemail.com> <11904-20964@sneakemail.com>
	<1180988880.23003.11.camel@erandi.dom> <30990-68458@sneakemail.com>
	<f41lpr$mdp$1@sea.gmane.org> <1180988880.23003.11.camel@erandi.dom>
	<11904-20964@sneakemail.com> <29828-16732@sneakemail.com>
	<19310-39525@sneakemail.com>
Message-ID: <1181164714.14511.95.camel@erandi.dom>

Hey,

> I just ran a performance test. The unmanaged implementation adds about 1
> second for every 100,000 child processes. Even the managed version, which
> is, as expected, a lot slower, it adds less than 5 seconds for every 10,000
> child processes. In what situation would this be a severe and noticeable
> penalty? Surely the overhead of actually setting up a 10,000 child
> processes totally eclipses a 5 second penalty.

I went with your unmanaged code patch, so we are going with 1 instead of
5 ;-)

Thanks a *lot* for the patch, every couple of weeks I would think
"Jesus, how come we have not implemented this" and for one reason or
another never got around to it.

Miguel.


From 2a5gjx302 at sneakemail.com  Wed Jun  6 20:28:19 2007
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: Wed, 06 Jun 2007 19:28:19 -0500
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <1181164714.14511.95.camel@erandi.dom>
References: <19310-39525@sneakemail.com> <29828-16732@sneakemail.com>
	<11904-20964@sneakemail.com> <1180988880.23003.11.camel@erandi.dom>
	<30990-68458@sneakemail.com> <f41lpr$mdp$1@sea.gmane.org>
	<1180988880.23003.11.camel@erandi.dom> <11904-20964@sneakemail.com>
	<29828-16732@sneakemail.com> <19310-39525@sneakemail.com>
Message-ID: <16571-01110@sneakemail.com>

At 05:18 PM 6/6/2007 -0400, Miguel de Icaza wrote:
>Hey,
>
>> I just ran a performance test. The unmanaged implementation adds about 1
>> second for every 100,000 child processes. Even the managed version, which
>> is, as expected, a lot slower, it adds less than 5 seconds for every 10,000
>> child processes. In what situation would this be a severe and noticeable
>> penalty? Surely the overhead of actually setting up a 10,000 child
>> processes totally eclipses a 5 second penalty.
>
>I went with your unmanaged code patch, so we are going with 1 instead of
>5 ;-)

Actually 0.1 instead of 5. It really is a lot faster because it has a lot
less to do and even when it's doing the same thing it's so much more direct
than the FileStream class. At the same time, though, it doesn't fix the
problem on Windows. If I write an app that expects a child process to be
able to connect back to the parent with .NET Remoting, there's a good
chance users'll run into problems if they choose to run it with mono on
Windows. If Microsoft's framework isn't installed, it won't work *at all*;
if Microsoft's framework is installed, there could still be serious
problems with remoting incompatibilities (wasn't there just recently an
e-mail about remoting compatibility for
System.Collections.Generics.Dictionary`2?).

I wonder -- is there any possibility of supporting Windows and making the
(extremely minor in my opinion, but still much larger than with pure
unmanaged code) performance hit a Windows-only thing with something like
#if WIN32? Or is the managed part of the BCL designed to be buildable on
any platform and subsequently used on any other with no changes? I suppose
if Windows users complain about it, it could in the end be done with an
icall which is #ifdef WIN32'd on the C side... Heck, could even check
Environment.OSVersion.Platform (or use whatever better way there may be
available within the BCL for detecting the platform) and disable the
managed check that way. Presumably the overhead on that bitwise test would
be significantly less than actually opening the file and peeking at the
first few kilobytes. :-)

I'm sorry I just won't let this die, but it really feels like only half the
problem is solved because the problem isn't addressed for one of the
platforms mono supports.

>Thanks a *lot* for the patch, every couple of weeks I would think
>"Jesus, how come we have not implemented this" and for one reason or
>another never got around to it.

It was fun writing it :-)

Thanks,

Jonathan Gilbert


From savvkin at gmail.com  Thu Jun  7 04:43:26 2007
From: savvkin at gmail.com (Savva)
Date: Thu, 7 Jun 2007 12:43:26 +0400
Subject: [Mono-dev] Fwd: Mono 1.1 and 2.0 runtimes and SessionState
In-Reply-To: <c80dbdf30706052323v1469622dgf96f290cc32d514e@mail.gmail.com>
References: <c80dbdf30706052323v1469622dgf96f290cc32d514e@mail.gmail.com>
Message-ID: <c80dbdf30706070143x4833ff96wf68977f45b34132a@mail.gmail.com>

Hello.
I use openSUSE 10.2 image from site + daily monocharge binaries +
system auto update

I managed to compile ASP.NET 2.0 Web-Service under Apache + mod_mono,
but it still not working...

1. If I use those settings (in etc/apache2/server-default.conf), my
service runs under Mono Runtime 2.0. Is those settings are correct?

Alias /mstest /srv/www/htdocs/monoservice
MonoApplications msdefault "/mstest:/srv/www/htdocs/monoservice"
MonoServerPath msdefault "/usr/bin/mod-mono-server2"
<Directory /srv/www/htdocs/monoservice>
        Allow from all
         Order allow,deny
        SetHandler mono
        MonoSetServerAlias msdefault
</Directory>

2. Why do I get 2 pairs of methods are generated on page in case of runtime 2.0?

Methods
HelloWorld
HelloWorld2

and

Methods for MyServiceSoap12
HelloWorld
HelloWorld2

3. When I try to test any method with test form I get following error
(after about 60 sec of waiting):
--- start here ---
The remote server returned an error: (500) Internal Server Error.
<?xml version=" 1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html
       xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en"><head><title>Error
       500</title><style type="text/css">body
{font-family:"Verdana","DejaVu Sans",
     sans-serif;font-weight:normal;font-size:
.7em;color:black;background-color: white}
p {font-family:"Verdana","DejaVu
Sans",sans-serif;font-weight:normal;color:black;margin-top:
       -5px}
b {font-family:"Verdana","DejaVu
Sans",sans-serif;font-weight:bold;color:black;margin-top: -5px}
h1 { font-family:"Verdana","DejaVu
Sans",sans-serif;font-weight:normal;font-size:18pt;color:red
       }
h2 { font-family:"Verdana","DejaVu Sans",
      sans-serif;font-weight:normal;font-size:14pt;color:maroon }
pre {font-family:"Lucida Console","DejaVu Sans Mono",
monospace;font-size:  1.2em}
div.bodyText {font-family: "Verdana","DejaVu Sans",sans-serif}
 table.sampleCode  100%; background-color: #ffffcc;
.errorText  red; font-weight: bold
 .marker {font-weight: bold; color: black;text-decoration: none;}
.version  gray;
 .error {margin-bottom: 10px;}
.expandable { text-decoration:underline; font-weight:bold; color:navy;
cursor:hand;
       }</style></head><body><h1>Server Error in '/mstest' Application</h1><hr
       style="color: silver"/><h2><em>Object reference not set to an
instance of an
      object</em></h2>
<p><strong>Description: </strong>Error processing request.</p>
 <p><strong>Error Message: </strong>HTTP 500.
System.NullReferenceException: Object reference
      not set to an instance of an object
</p>
<p><strong>Stack Trace: </strong></p><table summary="Stack Trace"
class="sampleCode">
<tr><td><pre>System.NullReferenceException: Object reference not set
to an instance of an object
   at System.Web.SessionState.SessionInProcHandler.SetAndReleaseItemExclusive (
       System.Web.HttpContext  context, System.String id,
        System.Web.SessionState.SessionStateStoreData item,
System.Object lockId, Boolean
         newItem) [0x00000] </pre></td></tr>
</table>
 <![CDATA[
System.Web.HttpException:  ---> System.NullReferenceException: Object
reference not set to
      an instance of an object
  at System.Web.SessionState.SessionInProcHandler.SetAndReleaseItemExclusive  (
       System.Web.HttpContext context, System.String id,
         System.Web.SessionState.SessionStateStoreData item,
System.Object lockId, Boolean
        newItem) [0x00000] --- End of inner exception stack trace ---

]]>
<hr style="color: silver"/>02/17/2009 12:43:47</body></html>
--- end here ---

4. If I switch off SessionState or comment out config (and make it
1.1), it works

<sessionState mode="Off" cookieless="false" timeout="30" />

OR

#Alias /mstest /srv/www/htdocs/monoservice
 #MonoApplications msdefault "/mstest:/srv/www/htdocs/monoservice"
 #MonoServerPath msdefault "/usr/bin/mod-mono-server2"
#<Directory /srv/www/htdocs/monoservice>
 #        Allow from all
 #        Order allow,deny
#        SetHandler mono
 #        MonoSetServerAlias msdefault
#</Directory>

I have no idea how to fix all that... Please help.

This is src of my web service

--- start here ---
 using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.Common;
using System.Web;
 using System.Collections;
using System.Web.Services;
 using System.Web.Services.Protocols;
using System.ComponentModel;

 namespace MonoService
{

    [WebService(Namespace = " http://www.ru/", Name =
"MyApplicationServer", Description = "test")]
    //[WebServiceBinding(ConformsTo =  WsiProfiles.BasicProfile1_1)]
    public class Service1 : System.Web.Services.WebService
     {
        [WebMethod(EnableSession=true)]
        public DataSet HelloWorld(string query)
        {
            Session.Add("lastquery", query);
            SqlConnection conn = new
System.Data.SqlClient.SqlConnection(@"my conn string");
             SqlDataAdapter adap = new SqlDataAdapter(query, conn);
             DataSet ds = new DataSet();
            adap.Fill(ds);
             return ds;
        }
         [WebMethod(EnableSession = true)]
        public string HelloWorld2()
         {
            string lastquery = "";
            try
            {
                lastquery = Session["lastquery"].ToString();
            }
            catch (Exception ex)
             {
                lastquery = "Error: " + ex.ToString();
             }

            return lastquery;
         }
    }
}
--- end here ---


From mabra at manfbraun.de  Thu Jun  7 08:21:18 2007
From: mabra at manfbraun.de (mabra at manfbraun.de)
Date: Thu, 7 Jun 2007 14:21:18 +0200
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <16571-01110@sneakemail.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA5vnGI+hMzxGNBQCASISWKcKAAAAQAAAANAkaF8BsHUqmfwAiCDF8hAEAAAAA@manfbraun.de>

Hi All !

Sorry for my 2 cents.

I am working a lot with processes, both, native as .net related, mostly
under windows, but will be able to keep my code running on both worlds.

What I always expect is, a process is a process, nothing else. Which runtime
runs inside the process is up to the starter of the process. Usually, I
start windows executables, with and without GUI. Even if I start a .net
executable, which is handled by the windows shell to span a new runtime,
that is excactly, what I want to do. The spawned processes should keep
running, even my starter terminated in the meantime. A process is a stronger
isolation level that an appDomain, so I use this for a lot of reasons. If I
need to communcate with the spawned app, I use remoting.

I would never expect to run a new .net executable in the sampe process.
As I said, these are just my 2 cents.

Best regards,
Manfred

Sorry for initially posting accidentally to the original author :-(

-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jonathan
Gilbert
Sent: Thursday, June 07, 2007 2:28 AM
To: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime

At 05:18 PM 6/6/2007 -0400, Miguel de Icaza wrote:
>Hey,
>
>> I just ran a performance test. The unmanaged implementation adds about 1
>> second for every 100,000 child processes. Even the managed version, which
>> is, as expected, a lot slower, it adds less than 5 seconds for every
10,000
>> child processes. In what situation would this be a severe and noticeable
>> penalty? Surely the overhead of actually setting up a 10,000 child
>> processes totally eclipses a 5 second penalty.
>
>I went with your unmanaged code patch, so we are going with 1 instead of
>5 ;-)

Actually 0.1 instead of 5. It really is a lot faster because it has a lot
less to do and even when it's doing the same thing it's so much more direct
than the FileStream class. At the same time, though, it doesn't fix the
problem on Windows. If I write an app that expects a child process to be
able to connect back to the parent with .NET Remoting, there's a good
chance users'll run into problems if they choose to run it with mono on
Windows. If Microsoft's framework isn't installed, it won't work *at all*;
if Microsoft's framework is installed, there could still be serious
problems with remoting incompatibilities (wasn't there just recently an
e-mail about remoting compatibility for
System.Collections.Generics.Dictionary`2?).

I wonder -- is there any possibility of supporting Windows and making the
(extremely minor in my opinion, but still much larger than with pure
unmanaged code) performance hit a Windows-only thing with something like
#if WIN32? Or is the managed part of the BCL designed to be buildable on
any platform and subsequently used on any other with no changes? I suppose
if Windows users complain about it, it could in the end be done with an
icall which is #ifdef WIN32'd on the C side... Heck, could even check
Environment.OSVersion.Platform (or use whatever better way there may be
available within the BCL for detecting the platform) and disable the
managed check that way. Presumably the overhead on that bitwise test would
be significantly less than actually opening the file and peeking at the
first few kilobytes. :-)

I'm sorry I just won't let this die, but it really feels like only half the
problem is solved because the problem isn't addressed for one of the
platforms mono supports.

>Thanks a *lot* for the patch, every couple of weeks I would think
>"Jesus, how come we have not implemented this" and for one reason or
>another never got around to it.

It was fun writing it :-)

Thanks,

Jonathan Gilbert
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list



From robertj at gmx.net  Thu Jun  7 08:28:34 2007
From: robertj at gmx.net (Robert Jordan)
Date: Thu, 07 Jun 2007 14:28:34 +0200
Subject: [Mono-dev] Fwd: Mono 1.1 and 2.0 runtimes and SessionState
In-Reply-To: <c80dbdf30706070143x4833ff96wf68977f45b34132a@mail.gmail.com>
References: <c80dbdf30706052323v1469622dgf96f290cc32d514e@mail.gmail.com>
	<c80dbdf30706070143x4833ff96wf68977f45b34132a@mail.gmail.com>
Message-ID: <f48tlj$p4i$1@sea.gmane.org>

Savva wrote:
> 4. If I switch off SessionState or comment out config (and make it
> 1.1), it works
> 
> <sessionState mode="Off" cookieless="false" timeout="30" />
> 
[...]
> 
> I have no idea how to fix all that... Please help.

This is due to this bug:

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


Robert



From anagappan at novell.com  Thu Jun  7 09:00:23 2007
From: anagappan at novell.com (A Nagappan)
Date: Thu, 07 Jun 2007 07:00:23 -0600
Subject: [Mono-dev] Patch for SqlCommand
Message-ID: <46684EBF020000440000B2B3@lucius.provo.novell.com>

Hi,
  Tested the attached patch, could you please verify it in your
environment ?

Thanks
Nagappan

Nagappan A <anagappan at novell.com>
Linux Desktop Testing Project - http://ldtp.freedesktop.org
http://nagappanal.blogspot.com

Novell, Inc.
SUSE? Linux Enterprise 10
Your Linux is ready?
http://www.novell.com/linux


>>> "Amc Gmail" <amc1999 at gmail.com> 06/07/07 12:06 AM >>>
IMHO, we just need to remove from SqlDataReader Close() unnecessary
line:
        command.Connection.DataReader = null;
because right after this we have
        command.CloseDataReader (moreResults);
which doing same things at the beginning of  CloseDataReader():
        Connection.DataReader = null;

Sorry, i can't test this today, it would be really nice if someone can
verify it.

also in SqlCommand.Dispose(), OdbcCommand.Dispose() and some other
places call of
    base.Dispose (disposing);
may be a good idea. without it Disposed events seems to be not going
through.
regards,
amc




On 6/6/07, Neil Cawse <neilcawse at geotab.com> wrote:
>
>
>
>
> At the moment SqlCommand is broken in our application from a recent
commit.
>
>
>
> SqlDataReader is internally constructed with the SqlCommand that
created it.
>
> The close method of SqlDataReader relies on the fact that the
connection for
> a command still exists:
>
> command.Connection.DataReader = null
>
> A previous commit sets this to null in the SqlCommand.Dispose
>
>
>
> There may be better fixed with some re-architecture ? not sure..
>
>
>
> Index:
>
/home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs
>
> ===================================================================
>
> ---
>
/home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs
>    (revision 78769)
>
> +++
>
/home/neilcawse/mymono/mcs/class/System.Data/System.Data.SqlClient/SqlCommand.cs
>    (working copy)
>
> @@ -582,7 +582,6 @@
>
>                       if (disposing) {
>
>                              parameters.Clear();
>
>                              transaction = null;
>
> -                            connection = null;
>
>                       }
>
>                       disposed = true;
>
>                }
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dispose.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070607/304893fe/attachment.pl 

From lupus at ximian.com  Thu Jun  7 10:33:33 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Thu, 7 Jun 2007 16:33:33 +0200
Subject: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime
In-Reply-To: <19310-39525@sneakemail.com>
References: <29828-16732@sneakemail.com> <11904-20964@sneakemail.com>
	<1180988880.23003.11.camel@erandi.dom>
	<30990-68458@sneakemail.com> <f41lpr$mdp$1@sea.gmane.org>
	<1180988880.23003.11.camel@erandi.dom>
	<11904-20964@sneakemail.com> <29828-16732@sneakemail.com>
	<19310-39525@sneakemail.com>
Message-ID: <20070607143333.GY4081@debian.org>

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


From 2a5gjx302 at sneakemail.com  Thu Jun  7 16:24:20 2007
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: T