[Mono-dev] Questions on Cecil
I've begun writing the interface layer to Cecil for my CIL optimizer, and I have some questions on using Cecil that I have not been able to find an answer to on my own. Any help would be appreciated. 0. I assume Cecil is sufficiently related to Mono for questions about it to be on-topic on this list, especially as I don't see any Cecil-specific mailing list. Am I correct? (if not: sorry! :-) ) 1. I'm using ildasm and the largely uncommented Cecil source as documentation. Is there some actual documentation other than the FAQ? 2. I need to know the types of the things on the stack. Can Cecil help with that? If not, is there some nice way to get .NET to handle the operations on the type lattice? 3. When emitting a Br (branch) instruction, Cecil insists on getting the target instruction immediately. The trouble is that when I am writing out CIL to Cecil from the CIL representation internal to my program, it is often the case that the target of the branch has not been emitted yet. Currently I get around this by passing it a dummy Nop instruction and then correcting the target in a second pass. Is there some way to avoid constructing a dummy instruction, such as by getting Cecil to accept a null as the (preliminary) target? (When I try to do that the obvious way I get an exception) 4. Cecil requires that the type of a local variable be specified as a TypeReference, so I need to get those. Is there some way to get a TypeReference for built in types like System.Int32 without loading an assembly? The way I am doing it now is getting it as assembly.MainModule.TypeReferences["System.Int32"]. 5. I would like to emit the short form of the Br instruction when this is possible. My initial idea is to always emit the short form, and then expand to the long form where necessary. That makes it necessary to take into account the possibility of a cascade where expanding one instruction increases the distance to the target of another Br instruction which then also needs to be expanded to the long form and so on. I would like to avoid this trouble, so is there some way to get Cecil to do this for me? /Bjarke Roune ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Required Libraries
Thank you for giving me your answer. I'm finding other options to this but I've got other question. I'm using other small libraries on windows fairly well. When I pass them out to linux, the project is compiled correctly. But is it possible other bigger windows libraries, which are well compiling on mono, have executing problems on mono. Maybe I know the answer ( It depends on the library) but I would like to know an experience comment. Rafael Teixeira wrote: > > Just clarifying the legal bits, first: > --- > This is a Microsoft Patterns & Pratices library of building block and > its license (EULA) says: > > "10. That you may run the Software or modifications only on the > Windows platform." > > So you can't use with Mono, outside Windows at least that is the more > common need. > --- > > AFAIK, there is no plan to implement its API that is just some best > pratices guidance, and there are plenty of other open source projects > that overlap its functionality, so I suggest you to use them instead > of this. > > For ORM you have nhibernate, for lower-level db-abstraction you have > ADP and CSDO, for configuration you have nini. and so on > > :) > > On 8/10/06, pepuso <[EMAIL PROTECTED]> wrote: >> >> Hi all >> >> I was googling because I'm using the library >> Microsoft.Practices.EnterpriseLibrary.Configuration on C# on Windows >> software and I wanted to used it on Mono. >> >> Is this library, or similars, available to Mono? >> >> Until now, I've not found anything yet. Any aid will be helpfull. >> >> Thanks pepuso. >> >> >> -- >> View this message in context: >> http://www.nabble.com/Required-Libraries-tf2087668.html#a5753908 >> Sent from the Mono - Dev forum at Nabble.com. >> >> ___ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > > > -- > Rafael "Monoman" Teixeira > --- > "The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man." George Bernard Shaw > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://www.nabble.com/Required-Libraries-tf2087668.html#a5779977 Sent from the Mono - Dev forum at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] EventLog implementation
Hi Atsushi, As we discussed on #mono, I've made modifications to the UnixRegistry API to create the following registry hives in /var/lib/mono/registry instead of /.mono/registry: - HKEY_CURRENT_CONFIG - HKEY_CLASSES_ROOT - HKEY_DYN_DATA - HKEY_LOCAL_MACHINE - HKEY_PERFORMANCE_DATA - HKEY_USERS (not to be mistaken with HKEY_CURRENT_USER) By default, the owner (admin) has full control (rwx) while everony else has read&execute permission. That allows us to share machine-level registry information between different users, while preventing write access to this information by non-admins. As a result of this change, eventlog registration information is now also shared between different users, and event logs can now no longer be created by non-admins. This matches the behavior on MS.NET. The event entries created by the UnixEventLog implementation are now persisted in /var/lib/mono/eventlog, and access rights on this directory are rwx for everyone, while only giving file owners the right to delete files (using +t special bit). This should anyone to write entries to an event log once it has been created (by an admin). Does this match what we've discussed ? If so, I'll post the corresponding patch to the devel-list later today (or tomorrow). Once you've acknowledged the basics of the patch, I'll run the UnixRegistry API changes by Miguel as he's the author of the API. Gert > -Original Message- > From: [EMAIL PROTECTED] [mailto:mono-devel-list- > [EMAIL PROTECTED] On Behalf Of Atsushi Eno > Sent: vrijdag 11 augustus 2006 5:24 > To: Gert Driesen > Cc: 'Kornél Pál'; mono-devel-list@lists.ximian.com > Subject: Re: [Mono-dev] [PATCH] EventLog implementation > > As we talked on #mono yesterday, feel free to commit your changes that > include my local file based implementation (as you rather wanted, than > changing your code after my commit, dunno the reason though). However > it is not the case if you need much more time. > > Atsushi Eno > > Atsushi Eno wrote: > > Ok, then there is a gap in the premises. After I commit my changes, > > you don't have to wait for me. I can't waste my time on only-win32 > > implementation which can be used in theory. I don't deny the value of > > native win32 implementation, but it is totally out of my concern. > > > > I also don't care any structural changes you would like to make in > > common area, as long as it just works. I even don't think existing > > EventLogEntry.ctor() is good enough since it requires everything at > > construction time (and I guess that it won't meet WindowsAPI > > implementation demand). > > > > (now I read your next message before sending it as I'm ready to > > commit) You don't have to spend your time to include my code. > > And I don't use XML here and stick to current code (I hate extraneous > > Xmlization ;-) > > > > Atsushi Eno > > > > Gert Driesen wrote: > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of > >>> Atsushi Eno > >>> Sent: donderdag 10 augustus 2006 19:53 > >>> To: Gert Driesen > >>> Cc: 'Kornél Pál'; mono-devel-list@lists.ximian.com > >>> Subject: Re: [Mono-dev] [PATCH] EventLog implementation > >>> > >>> Just curious, where is my local file implementation which just > works? > >>> > >>> If it isn't in your patch, I'll ignore it and commit my patch so > >>> that I don't have to waste customers' time for something > unimplemented. > >>> > >>> Feel free to improve your implementation after that. > >> I was waiting for (your) approval on this patch (which doesn't > >> necessarily means it has to be committed), and would then look into > >> integrating your local file implementation. > >> > >> Gert > >> > >>> Gert Driesen wrote: > Hi Kornél and Atsushi, > > I've attached a working patch for the new EventLog implementation, > along with a set of unit tests (that pass on Mono and .NET). > > Right now, reading of event log entries is not implemented for the > win32 implementation (Kornél, happen to volunteer for this ?). > > It's probably not perfect yet, but it should give us a good start. > > Gert > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of > > Kornél Pál > > Sent: donderdag 10 augustus 2006 13:03 > > To: Gert Driesen; 'Atsushi Eno' > > Cc: mono-devel-list@lists.ximian.com > > Subject: Re: [Mono-dev] local file based EventLog implementation > > > >> It's clear to me, but we'll need to see how we distribute this > >> file > > (on > >> Windows) and locate it. > > I think the easiest solution is to put the DLL to the directory > of > > mscorlib.dll. This lets us use different version based on > > framework version (altough it's not currently required but MS.NET > > does the > >>> same > > so may be require
Re: [Mono-dev] UnmanagedType.LPWStr and Big-Endian Unicode
Hi,
On big-endian machines everything is big-endian, including P/Invoke. In fact
there is no need to big-endian conversion because managed strings are
big-endian on big-endian machines. They are converted when they are read
from your assembly files.
Only things documented to be little-endian are little-endian on big-endian
machines.
For more information have a look at
http://lists.ximian.com/pipermail/mono-devel-list/2005-December/016352.html
Kornél
- Original Message -
From: "Dmitry Key" <[EMAIL PROTECTED]>
To:
Sent: Saturday, August 12, 2006 11:14 AM
Subject: [Mono-dev] UnmanagedType.LPWStr and Big-Endian Unicode
> Hi
>
> One has the following function declaration:
>
> [DllImport("libSQLDBC_C")]
> public unsafe extern static SQLDBC_Retcode
> SQLDBC_PreparedStatement_prepareNTS(
> IntPtr stmt,
> [MarshalAs(UnmanagedType.LPWStr)]string query,
> SQLDBC_StringEncodingType encoding);
>
> It is obvious that for the Little-Endian hardware the string "query" will
> be
> translated to the Little-Endian null-terminated Unicode string. But what
> happens for the Big-Endian architecture? I could not find answer for this
> question in the Mono documention.
>
> _
> Express yourself instantly with MSN Messenger! Download today it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
> ___
> 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] UnmanagedType.LPWStr and Big-Endian Unicode
Hi
One has the following function declaration:
[DllImport("libSQLDBC_C")]
public unsafe extern static SQLDBC_Retcode
SQLDBC_PreparedStatement_prepareNTS(
IntPtr stmt,
[MarshalAs(UnmanagedType.LPWStr)]string query,
SQLDBC_StringEncodingType encoding);
It is obvious that for the Little-Endian hardware the string "query" will be
translated to the Little-Endian null-terminated Unicode string. But what
happens for the Big-Endian architecture? I could not find answer for this
question in the Mono documention.
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
