Re: [Mono-dev] greetings (new here)... a few things...
2009/1/6 BGB cr88...@hotmail.com: how much does mono depend on the specifics of its existing CLI / JIT implementation?... how much does it depend on Boehm and like?... Are you mostly interested in class libraries? As far as I know, Mono class libraries depend on internal calls, and not much else. See also docs/internal-calls. -- Seo Sanghyeon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] greetings (new here)... a few things...
BGB wrote: I am also not all that likely to re-use the existing CLI engine, as personally I find the code... displeasing... You might not be aware of it, but you're suffering from a declining not-invented-here syndrome ;-) Both GC and JIT are replaceable in mono. The first is sanely replaceable while the latter is replaceable in theory, as nobody has done it publicly besides the now obsolete interpreter. Mono's BCL does depend on the underlying runtime. If you want to replace the *whole* runtime, a lot of internal calls would have to be provided by the new runtime. This can be avoided by implementing a new JIT as mentioned above. Al this stuff can be easily discovered by reading the source and the docs. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] greetings (new here)... a few things...
I am also not all that likely to re-use the existing CLI engine, as personally I find the code... displeasing... The time taken to submit patches to make the code pleasing to you would be significantly less than the time taken to rewrite from scratch. If the patches are good, they'll be accepted. Why not give that a shot and see if you can advance your own project *and* mono at the same time, at a much much faster rate than you could by by rewriting from scratch. Just my opinion ;) Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Crash in gmcs
Hello Casey Compiling this: http://github.com/jskeet/dotnet-protobufs/tree/master With gmcs 2.0.1, I get this: Please use newer gmcs (2.2 or better). Regards, Marek Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at Mono.CSharp.GenericConstraints.get_IsReferenceType () [0x00049] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:82 at Mono.CSharp.GenericConstraints.get_IsReferenceType () [0x00077] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:87 at Mono.CSharp.ConstraintChecker.CheckConstraints (IResolveContext ec, Int32 index) [0x00065] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:1562 at Mono.CSharp.ConstraintChecker.CheckConstraints (IResolveContext ec) [0x7] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:1535 at Mono.CSharp.ConstraintChecker.CheckConstraints (IResolveContext ec, System.Type gt, System.Type[] gen_params, System.Type[] atypes, Location loc) [0xb] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:1758 at Mono.CSharp.ConstructedType.CheckConstraints (IResolveContext ec) [0x0] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:1399 at Mono.CSharp.Expression.ResolveAsTypeTerminal (IResolveContext ec, Boolean silent) [0x0008e] in .../sources-2.0.1-5/mono/mcs/mcs/ecore.cs:275 at Mono.CSharp.Constraints.ResolveTypes (IResolveContext ec) [0x000f1] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:413 at Mono.CSharp.TypeParameter.ResolveType (IResolveContext ec) [0xb] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:697 at Mono.CSharp.GenericMethod.Define (System.Reflection.Emit.MethodBuilder mb, Mono.CSharp.ToplevelBlock block) [0x000b2] in .../sources-2.0.1-5/mono/mcs/mcs/generic.cs:1863 at Mono.CSharp.MethodOrOperator.DefineGenericMethod () [0x00040] in .../sources-2.0.1-5/mono/mcs/mcs/class.cs:3836 at Mono.CSharp.MethodOrOperator.ResolveMembers () [0x0] in .../sources-2.0.1-5/mono/mcs/mcs/class.cs:3846 at Mono.CSharp.TypeContainer.DoResolveMembers () [0x00028] in .../sources-2.0.1-5/mono/mcs/mcs/class.cs:1194 at Mono.CSharp.TypeContainer.ResolveMembers () [0x00012] in .../sources-2.0.1-5/mono/mcs/mcs/class.cs:1184 at Mono.CSharp.TypeContainer.DefineType () [0x0004e] in .../sources-2.0.1-5/mono/mcs/mcs/class.cs:1166 at Mono.CSharp.Class.DefineType () [0x00071] in .../sources-2.0.1-5/mono/mcs/mcs/class.cs:2909 at Mono.CSharp.RootContext.ResolveTree () [0x00069] in .../sources-2.0.1-5/mono/mcs/mcs/rootcontext.cs:174 at Mono.CSharp.Driver.Compile () [0x00266] in .../sources-2.0.1-5/mono/mcs/mcs/driver.cs:1660 at Mono.CSharp.Driver.Main (System.String[] args) [0x0002e] in .../sources-2.0.1-5/mono/mcs/mcs/driver.cs:308 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono with SQLite
I'm working on porting my .NET application to Mono. My application runs perfectly fine on .NET. According to MoMA, the application itself has no problems at all. I'm using SQLite however that causes some problems. I'm using the System.Data.SQLite provider from http://sqlite.phxsoftware.com . As I understand it, Mono uses the same code so it's no use switching to Mono.Data.SqliteClient. I've already created a topic on the website above with my problem, but that resolved little. http://sqlite.phxsoftware.com/forums/t/1562.aspx ( 7 posts total ). (Link contains details about problem). Are there any suggestions as to what I can try to make my application cross platform. I would like to have only 1 version for both .Net and Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] greetings (new here)... a few things...
[merging responses here...] - Original Message - From: Seo Sanghyeon sanx...@gmail.com To: BGB cr88...@hotmail.com Cc: mono-devel-list@lists.ximian.com Sent: Tuesday, January 06, 2009 7:07 PM Subject: Re: [Mono-dev] greetings (new here)... a few things... 2009/1/6 BGB cr88...@hotmail.com: how much does mono depend on the specifics of its existing CLI / JIT implementation?... how much does it depend on Boehm and like?... Are you mostly interested in class libraries? As far as I know, Mono class libraries depend on internal calls, and not much else. See also docs/internal-calls. hmm... well, I have not yet examined the class libraries in much detail, but if they depend to heavily on the VM particulars, it may be a bit more effort... but, alas, there are several possible .NET based projects I could mine parts from, in the worst case (doing something purely homebrew would be hopefully avoided, as then I am the only one working on it, and I am well aware of this sort of isolation...). (whatever dependencies there are, I would like to be able to hopefully discover and consider). but, anyways, I am hoping I don't just end up wasting the time of the people here, but this is always a risk I guess... - Original Message - From: Robert Jordan robe...@gmx.net To: mono-devel-list@lists.ximian.com Sent: Tuesday, January 06, 2009 7:26 PM Subject: Re: [Mono-dev] greetings (new here)... a few things... BGB wrote: I am also not all that likely to re-use the existing CLI engine, as personally I find the code... displeasing... You might not be aware of it, but you're suffering from a declining not-invented-here syndrome ;-) I regularly do NIH, but partly this is because I am fairly fussy about some things... I also feel that it is of some value to have multiple implementations of things available, and to be able to mix and match parts to get the desired results, so as I see it, NIH is not purely a bad thing, even if, yes, it is not the most direct way to do things... this is after all, a good reason to have standards... I don't mean to try to rip on the existing codebase that much, but it is not quite how I tend to do things personally. after all, what has been achieved thus far has been impressive, which is more than can be said in my case. I usually end up making lots of code, often with a decently capable featureset, and at least as I view it, relatively clean coding practices, but the detractor is that code tends not to amount to much (I make code, but it tends to all be nothing of any real value...). so, the achievements are impressive, only that is is not as easy to be impressed by the code in itself... but, I expect that not everyone would like my approaches either, so that is ok... Both GC and JIT are replaceable in mono. The first is sanely replaceable while the latter is replaceable in theory, as nobody has done it publicly besides the now obsolete interpreter. yes, and these are the main parts I am looking at. not that I would do this in all cases (most of my code is specific to x86 and x86-64, and so would not likely fulfill everyones' needs, and there are likely many other advantages as well). the thing though is, I will just make much of what code I have available for whoever might be interested... yes, I have looked at some of the GC machinery already, as well as some of the code for the object system, ... however, as noted, a good deal more investigation is probably needed in my case (I have only looked over a small amount of the total codebase thus far). Mono's BCL does depend on the underlying runtime. If you want to replace the *whole* runtime, a lot of internal calls would have to be provided by the new runtime. This can be avoided by implementing a new JIT as mentioned above. Al this stuff can be easily discovered by reading the source and the docs. yeah, I have looked over parts of the source, but not that much (it is fragmentary, much like my reading thus far through ECMA-335...). but, yes, the kinds of calls is about as big of a question as that calls are needed, so I may look into this. I did not mean to say I think that libraries are fully independent of the implementation, only that from the design of CIL in general, it is likely to be much lower than for some other frameworks (where most of the framework is actually implemented in C, and most of what exists in the language is thin wrappers over the big mass of C...). - Original Message - From: Alan McGovern To: BGB Cc: mono-devel-list@lists.ximian.com Sent: Tuesday, January 06, 2009 8:20 PM Subject: Re: [Mono-dev] greetings (new here)... a few things... I am also not all that likely to re-use the existing CLI engine, as personally I find the code... displeasing... The time taken to submit patches to make the code pleasing to you would be significantly less than the time taken to rewrite from scratch. If the
Re: [Mono-dev] Mono with SQLite
From the site: *System.Data.SQLite ***is the original SQLite http://www.sqlite.org/database engine and a complete ADO.NET 2.0 provider all rolled into a single *mixed mode* assembly Mixed mode assemblies aren´t portable, period. They contain x86 native code in Windows-specific format, so it won't run in any other OSes or any other CPU architecture. If you really need a portable solution (across OSes) you should use Mono.Data.SqliteClient, and package both native library versions o sqlite (.dll and .so), the correct one will be used automatically by the managed provider. CPU portability is harder to tackle, and would only be reasonable to achieve by implementing a 100% managed version of the engine+provider. Hope it helps, 2009/1/6 FXHat - fxhat.m...@gmail.com I'm working on porting my .NET application to Mono. My application runs perfectly fine on .NET. According to MoMA, the application itself has no problems at all. I'm using SQLite however that causes some problems. I'm using the System.Data.SQLite provider from http://sqlite.phxsoftware.com . As I understand it, Mono uses the same code so it's no use switching to Mono.Data.SqliteClient. I've already created a topic on the website above with my problem, but that resolved little. http://sqlite.phxsoftware.com/forums/t/1562.aspx ( 7 posts total ). (Link contains details about problem). Are there any suggestions as to what I can try to make my application cross platform. I would like to have only 1 version for both .Net and Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] greetings (new here)... a few things...
On Tue, 2009-01-06 at 10:26 +0100, Robert Jordan wrote: Mono's BCL does depend on the underlying runtime. If you want to replace the *whole* runtime, a lot of internal calls would have to be provided by the new runtime. Which is not to say that it can't be done. It can be done and has been done; see Grasshopper[0], which uses Mono's runtime libraries to run .NET code on the JVM (so obviously it's not using Mono's JIT). - Jon [0] http://dev.mainsoft.com/Default.aspx?tabid=130 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] patches that allow calling mono_init_com_types from native using ICall's.
Tom, I agree with Kornél. Please add mono_init_com_types to GetIUnknownForObjectInternal and GetIDispatchForObjectInternal. I do not understand why it would be needed in QueryInterfaceInternal. Even if the object is managed, cominterop_ccw_queryinterface would need the mono_init_com_types call, but that should have been called from GetIUnknownForObjectInternal (when you add it.) Another way to put it is, what are you calling QueryInterface on that needs the types initialized from mono_init_com_types? -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] patches that allow calling mono_init_com_types from native using ICall's.
Hi,
Thanks for your input,
I have added it as a Bug,
https://bugzilla.novell.com/show_bug.cgi?id=463843
On Tue, 2009-01-06 at 10:06 -0500, Bill Holmes wrote:
Tom,
I agree with Kornél. Please add mono_init_com_types to
GetIUnknownForObjectInternal and GetIDispatchForObjectInternal. I do
not understand why it would be needed in QueryInterfaceInternal. Even
if the object is managed, cominterop_ccw_queryinterface would need the
mono_init_com_types call, but that should have been called from
GetIUnknownForObjectInternal (when you add it.)
Another way to put it is, what are you calling QueryInterface on that
needs the types initialized from mono_init_com_types?
yep I understand, I'm only passing objects to QueryInterfaceInternal
that have been retrieved by calling Get???ForObjectInternal, and so
adding it to QueryInterfaceInternal isn't necessary.
-bill
Attached is the patch which adds mono_init_com_types to suggested
functions.
Thanks,
Tom
Index: mono/metadata/marshal.c
===
--- mono/metadata/marshal.c (revision 121548)
+++ mono/metadata/marshal.c (working copy)
@@ -10733,6 +10733,8 @@
if (!object)
return NULL;
+ mono_init_com_types ();
+
if (cominterop_object_is_rcw (object)) {
MonoClass *klass = NULL;
MonoRealProxy* real_proxy = NULL;
@@ -10793,6 +10795,8 @@
ves_icall_System_Runtime_InteropServices_Marshal_GetIDispatchForObjectInternal (MonoObject* object)
{
#ifndef DISABLE_COM
+ mono_init_com_types ();
+
return cominterop_get_idispatch_for_object (object);
#else
g_assert_not_reached ();
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono with SQLite
You didn’t read far enough down my website … Mono support A managed-only version of the provider is also available that works on Mono against the official SQLite library from http://www.sqlite.org/. Requires 3.6.1 or higher. My apologies on not answering your thread on the forums – I’ve been on vacation over the holidays. From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Rafael Teixeira Sent: Tuesday, January 06, 2009 7:06 AM To: FXHat - Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono with SQLite From the site: System.Data.SQLite is the original SQLite http://www.sqlite.org/ database engine and a complete ADO.NET 2.0 provider all rolled into a single mixed mode assembly Mixed mode assemblies aren´t portable, period. They contain x86 native code in Windows-specific format, so it won't run in any other OSes or any other CPU architecture. If you really need a portable solution (across OSes) you should use Mono.Data.SqliteClient, and package both native library versions o sqlite (.dll and .so), the correct one will be used automatically by the managed provider. CPU portability is harder to tackle, and would only be reasonable to achieve by implementing a 100% managed version of the engine+provider. Hope it helps, 2009/1/6 FXHat - fxhat.m...@gmail.com I'm working on porting my .NET application to Mono. My application runs perfectly fine on .NET. According to MoMA, the application itself has no problems at all. I'm using SQLite however that causes some problems. I'm using the System.Data.SQLite provider from http://sqlite.phxsoftware.com http://sqlite.phxsoftware.com/ . As I understand it, Mono uses the same code so it's no use switching to Mono.Data.SqliteClient. I've already created a topic on the website above with my problem, but that resolved little. http://sqlite.phxsoftware.com/forums/t/1562.aspx ( 7 posts total ). (Link contains details about problem). Are there any suggestions as to what I can try to make my application cross platform. I would like to have only 1 version for both .Net and Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] patches that allow calling mono_init_com_types from native using ICall's.
On Tue, 2009-01-06 at 15:26 -0500, Bill Holmes wrote: Tom, This is fine to commit. Do you have write access to mono svn? I don't have write access. If not I can commit it if you are willing to license the changes under the MIT X11 license? Yes. Is this ChangeLog entry fine with you? Yep 2009-10-06 Tom Hindle tom_hin...@sil.org * marshal.c (GetIUnknownForObjectInternal, GetIUnknownForObjectInternal) : Adding a call to mono_init_com_types. Code is contributed under MIT/X11 license. Thanks for your help! Tom Thanks -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Coolite 0.7 CssClassPropertyAttribute
Is this class, *System.Web.UI.CssClassPropertyAttribute*, part of the Mono 2.0.1 release? It seems that when I attempt to use the 0.7 version of the Coolite binaries I am presented with an Error 500 stating the following: *Could not load type 'System.Web.UI.CssClassPropertyAttribute' from assembly 'Coolite.Ext.Web'.* *Description: *HTTP 500. Error processing request. *Stack Trace: * System.TypeLoadException: Could not load type 'System.Web.UI.CssClassPropertyAttribute' from assembly 'Coolite.Ext.Web'. at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x0] at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x0] at System.Reflection.MonoProperty.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x0] at Coolite.Ext.Web.ClientConfig.GetClientConfigAttribute (System.Reflection.PropertyInfo property) [0x0] at Coolite.Ext.Web.ClientConfig.GetProperties (System.Object obj) [0x0] at Coolite.Ext.Web.ClientConfig.Process (System.Object obj) [0x0] at Coolite.Ext.Web.ClientConfig.Serialize (System.Object obj, Boolean ignoreCustomSerialization) [0x0] at Coolite.Ext.Web.ClientConfig.Serialize (System.Object obj) [0x0] at Coolite.Ext.Web.WebControl.get_InitialConfig () [0x0] at Coolite.Ext.Web.WebControl.GetClientConstructor (Boolean instanceOnly, System.String body) [0x0] at Coolite.Ext.Web.WebControl.GetClientConstructor () [0x0] at Coolite.Ext.Web.WebControl.OnClientInit () [0x0] at Coolite.Ext.Web.Observable.OnClientInit () [0x0] at Coolite.Ext.Web.WebControl.SetResources () [0x0] at Coolite.Ext.Web.WebControl.PreRenderAction () [0x0] at Coolite.Ext.Web.WebControl.OnPreRender (System.EventArgs e) [0x0] at Coolite.Ext.Web.Container.OnPreRender (System.EventArgs e) [0x0] at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0] at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0] at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0] at System.Web.UI.Page.ProcessLoadComplete () [0x0] at System.Web.UI.Page.InternalProcessRequest () [0x0] at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0] I can confirm that this error occurs on other Linux distributions and with mod_mono and xsp2. It occurs as soon as I use a Coolite tag - like the essential ext:scriptmanager id=myscriptmanager runat=server / -- _ Joshua S. Martin CONFIDENTIALITY NOTE: This e-mail message, including any attachment(s), contains information that may be confidential, protected by the attorney client or other legal privileges, and or proprietary non public information. If you are not an intended recipient of this message or an authorized assistant to an intended recipient, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution, or reproduction of this message and or any of its attachments (if any) by unintended recipients is not authorized and may be unlawful. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Coolite 0.7 CssClassPropertyAttribute
2009/1/6 Joshua Martin josmar52...@endeavorcorp.com: Is this class, System.Web.UI.CssClassPropertyAttribute, part of the Mono 2.0.1 release? No, it was added on 2008-09-13: http://lists.ximian.com/pipermail/mono-patches/2008-September/127775.html AFAICT .NET 3.5 SP1 was released in mid-August, a month after Mono branched for 2.0. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RVA Irregularities
The following code excerpt from the attached C# program behaves differently
on Mono 2.0.1runtime for Windows and Mono 2.0.1 runtime on the OpenSUSE
VMWare image. It contains a lookup of the base address (contained in
getBaseAddress()). The loop should print the program's Main() function IL
code at runtime. This RVA was found by looking it up in ILDASM.
The program was compiled the MS compiler.
IntPtr baseAddr = getBaseAddress();
for (int offset = 0x211c; offset 0x2169; offset++)
{
Console.WriteLine(Addr = {0:X}\tByte = {1:X},
baseAddr.ToInt32() + offset,
Marshal.ReadByte(new IntPtr(baseAddr.ToInt32() + offset)));
}
It seems like the loader is behaving differently on each platform. Is there
something I should be doing to mitigate this behavior?
Windows Mono Runtime output:
Addr = 40211C Byte = 13
Addr = 40211D Byte = 30
Addr = 40211E Byte = 4
Addr = 40211F Byte = 0
Addr = 402120 Byte = 4B
Addr = 402121 Byte = 0
Addr = 402122 Byte = 0
Addr = 402123 Byte = 0
Addr = 402124 Byte = 2
Addr = 402125 Byte = 0
Addr = 402126 Byte = 0
Addr = 402127 Byte = 11
Addr = 402128 Byte = 28
Addr = 402129 Byte = 1
Addr = 40212A Byte = 0
Addr = 40212B Byte = 0
Addr = 40212C Byte = 6
Addr = 40212D Byte = A
Addr = 40212E Byte = 20
Addr = 40212F Byte = 1C
Addr = 402130 Byte = 21
Addr = 402131 Byte = 0
Addr = 402132 Byte = 0
Addr = 402133 Byte = B
Addr = 402134 Byte = 2B
Addr = 402135 Byte = 34
Addr = 402136 Byte = 72
Addr = 402137 Byte = 69
Addr = 402138 Byte = 0
Addr = 402139 Byte = 0
Linux Mono Runtime output:
Addr = B7DDB11C Byte = C
Addr = B7DDB11D Byte = 2
Addr = B7DDB11E Byte = 0
Addr = B7DDB11F Byte = 0
Addr = B7DDB120 Byte = 1
Addr = B7DDB121 Byte = 0
Addr = B7DDB122 Byte = 30
Addr = B7DDB123 Byte = 0
Addr = B7DDB124 Byte = 30
Addr = B7DDB125 Byte = 0
Addr = B7DDB126 Byte = 30
Addr = B7DDB127 Byte = 0
Addr = B7DDB128 Byte = 30
Addr = B7DDB129 Byte = 0
Addr = B7DDB12A Byte = 30
Addr = B7DDB12B Byte = 0
Addr = B7DDB12C Byte = 34
Addr = B7DDB12D Byte = 0
Addr = B7DDB12E Byte = 62
Addr = B7DDB12F Byte = 0
Addr = B7DDB130 Byte = 30
Addr = B7DDB131 Byte = 0
Addr = B7DDB132 Byte = 0
Addr = B7DDB133 Byte = 0
Addr = B7DDB134 Byte = 44
Addr = B7DDB135 Byte = 0
Addr = B7DDB136 Byte = E
Addr = B7DDB137 Byte = 0
Addr = B7DDB138 Byte = 1
Addr = B7DDB139 Byte = 0
using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Diagnostics;
namespace helloworld_cs
{
class Program
{
static IntPtr getBaseAddress()
{
IntPtr baseAddress = new IntPtr();
ProcessModuleCollection modules =
Process.GetCurrentProcess().Modules;
Assembly assembly = Assembly.GetExecutingAssembly();
bool foundBaseAddress = false;
foreach (ProcessModule procModule in modules)
{
if (procModule.FileName.Equals(assembly.Location))
{
Console.WriteLine(module: + procModule.FileName + |
assembly: + assembly.Location);
baseAddress = procModule.BaseAddress;
foundBaseAddress = true;
}
}
if (!foundBaseAddress)
throw new ApplicationException(string.Format(Failed to find
assembly: {0}, assembly.Location));
return baseAddress;
}
unsafe static void Main(string[] args)
{
IntPtr baseAddr = getBaseAddress();
for (int offset = 0x211c; offset 0x2169; offset++)
{
Console.WriteLine(Addr = {0:X}\tByte = {1:X},
baseAddr.ToInt32() + offset, Marshal.ReadByte(new
IntPtr(baseAddr.ToInt32() + offset)));
}
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RVA Irregularities
Hi,
I don't know how ProcessModule.BaseAddress is implemented on Linux but
you shouldn't use this.
If you want to look at the IL code open the file using FileStream or use
Cecil.
Note that even if you modify IL code that would not affect code that is
already compiled to native code.
Also note that RVA's are not required to be preserved when the image is
loaded to memory.
Mono on Windows is using LoadLibrary in most cases that will map the
image according to the RVAs but Linux has no support for PE files so
images are just loaded without mapping PE sections to their designated
virtual addresses.
Kornél
Nathan McCauley wrote:
The following code excerpt from the attached C# program behaves
differently on Mono 2.0.1runtime for Windows and Mono 2.0.1 runtime on
the OpenSUSE VMWare image. It contains a lookup of the base address
(contained in getBaseAddress()). The loop should print the program's
Main() function IL code at runtime. This RVA was found by looking it up
in ILDASM.
The program was compiled the MS compiler.
IntPtr baseAddr = getBaseAddress();
for (int offset = 0x211c; offset 0x2169; offset++)
{
Console.WriteLine(Addr = {0:X}\tByte = {1:X},
baseAddr.ToInt32() + offset,
Marshal.ReadByte(new IntPtr(baseAddr.ToInt32() + offset)));
}
It seems like the loader is behaving differently on each platform. Is
there something I should be doing to mitigate this behavior?
Windows Mono Runtime output:
Addr = 40211C Byte = 13
Addr = 40211D Byte = 30
Addr = 40211E Byte = 4
Addr = 40211F Byte = 0
Addr = 402120 Byte = 4B
Addr = 402121 Byte = 0
Addr = 402122 Byte = 0
Addr = 402123 Byte = 0
Addr = 402124 Byte = 2
Addr = 402125 Byte = 0
Addr = 402126 Byte = 0
Addr = 402127 Byte = 11
Addr = 402128 Byte = 28
Addr = 402129 Byte = 1
Addr = 40212A Byte = 0
Addr = 40212B Byte = 0
Addr = 40212C Byte = 6
Addr = 40212D Byte = A
Addr = 40212E Byte = 20
Addr = 40212F Byte = 1C
Addr = 402130 Byte = 21
Addr = 402131 Byte = 0
Addr = 402132 Byte = 0
Addr = 402133 Byte = B
Addr = 402134 Byte = 2B
Addr = 402135 Byte = 34
Addr = 402136 Byte = 72
Addr = 402137 Byte = 69
Addr = 402138 Byte = 0
Addr = 402139 Byte = 0
Linux Mono Runtime output:
Addr = B7DDB11C Byte = C
Addr = B7DDB11D Byte = 2
Addr = B7DDB11E Byte = 0
Addr = B7DDB11F Byte = 0
Addr = B7DDB120 Byte = 1
Addr = B7DDB121 Byte = 0
Addr = B7DDB122 Byte = 30
Addr = B7DDB123 Byte = 0
Addr = B7DDB124 Byte = 30
Addr = B7DDB125 Byte = 0
Addr = B7DDB126 Byte = 30
Addr = B7DDB127 Byte = 0
Addr = B7DDB128 Byte = 30
Addr = B7DDB129 Byte = 0
Addr = B7DDB12A Byte = 30
Addr = B7DDB12B Byte = 0
Addr = B7DDB12C Byte = 34
Addr = B7DDB12D Byte = 0
Addr = B7DDB12E Byte = 62
Addr = B7DDB12F Byte = 0
Addr = B7DDB130 Byte = 30
Addr = B7DDB131 Byte = 0
Addr = B7DDB132 Byte = 0
Addr = B7DDB133 Byte = 0
Addr = B7DDB134 Byte = 44
Addr = B7DDB135 Byte = 0
Addr = B7DDB136 Byte = E
Addr = B7DDB137 Byte = 0
Addr = B7DDB138 Byte = 1
Addr = B7DDB139 Byte = 0
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] greetings (new here)... a few things...
FYI - There is a new open-source AOT/JIT compiler for the CIL being written right now as a component of the MOSA project (http://mosa.codeplex.com). We plan to use the existing Mono's runtime libraries (except for the internal calls which we plan to implement in managed code). Phil On Tue, Jan 6, 2009 at 6:31 AM, Jonathan Pryor jonpr...@vt.edu wrote: On Tue, 2009-01-06 at 10:26 +0100, Robert Jordan wrote: Mono's BCL does depend on the underlying runtime. If you want to replace the *whole* runtime, a lot of internal calls would have to be provided by the new runtime. Which is not to say that it can't be done. It can be done and has been done; see Grasshopper[0], which uses Mono's runtime libraries to run .NET code on the JVM (so obviously it's not using Mono's JIT). - Jon [0] http://dev.mainsoft.com/Default.aspx?tabid=130 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.2 RC1...
Steven Munroe wrote: Thomas Wiest wrote: Hey Everyone, We've just released Mono 2.2 RC1 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs Please include this regression found while testing RC1 on PowerPC https://bugzilla.novell.com/show_bug.cgi?id=462438 It may be related to the similar bug in svn: https://bugzilla.novell.com/show_bug.cgi?id=462016 Added, thanks! Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.2 RC1...
matteot wrote: Hi, I posted this one, cause it seems that in 2.2 there is some regression on mac osx windows.forms https://bugzilla.novell.com/show_bug.cgi?id=462024 Added, thanks! :) Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.2 RC1...
Tobi wrote: Thomas Wiest wrote: Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: A C# compiler bug: https://bugzilla.novell.com/show_bug.cgi?id=462592 Added, thanks! :) Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.2 RC1...
Stifu wrote: I just reported: https://bugzilla.novell.com/show_bug.cgi?id=462661 Wrong MouseEventArgs coordinates given in MouseWheel function Added, thanks! :) Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] Announcing Mono 2.2 RC1...
Peter Alfredsen wrote: On Monday 22 December 2008, Thomas Wiest wrote: Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you tag the summary of the bug with [Regression], then it is much more likely your bug will get fixed. I wasn't able to get an account because of a 504 Gateway Time-Out, but I was only going to use it to attach some additional information to bug 450782: https://bugzilla.novell.com/show_bug.cgi?id=450782 Added, thanks! :) Btw, the Gateway timeout should be fixed now. Bugzilla seems to be operating normally right now. Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-osx] Announcing Mono 2.2 RC1...
Leszek Ciesielski wrote: Could this one: https://bugzilla.novell.com/show_bug.cgi?id=459450 get included as well? It's needed for CruiseControl.Net. Added, thanks! :) Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-osx] Announcing Mono 2.2 RC1...
Евгений Гришуль wrote: Please add another one ( 1min to fix =) ): https://bugzilla.novell.com/show_bug.cgi?id=464012 Added, thanks! :) Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
