[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
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: mono-devel-list@lists.ximian.com 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
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 profile/.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 readexecute 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 required in the future) and it's quite easy to locate the directory of mscorlib.dll so the file can be located easily as well. However, I haven't yet managed to read entries from the event log. Does anyone have any info on doing this (using C#) ? Using API it's quite easy:
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
[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
[Mono-list] MonoDevelop causing SIGSEV on hardened
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, I have been trying to solve this on my own for about three month now, but I have failed. I know that it is my own fault to be on a hardened system, but maybe someone else knows this error and can help me out. I have checked through the list, forums and the web without finding anything useful. I am running a Gentoo-box which is hardened. This means that libc, gcc and some other packages are compiled with SSP (stack-smashing-protection) and PIE (position-independent-executable). Also the kernel has patches for GRSEC and PAX applied. This is known to cause some trouble with several applications, however with the exception of MonoDevelop I was able to solve them all. Let me get to the point: When I try to run MonoDevelop I get a SIGSEV. The results are the same whether I run the monodevelop-script or directly start the assembly. This is my error and stacktrace: - --- [EMAIL PROTECTED] /usr/lib/monodevelop/bin $ mono --debug MonoDevelop.exe (MonoDevelop:10598): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 432 and height -23 (MonoDevelop:10598): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 432 and height -23 = Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Stacktrace: in (wrapper managed-to-native) Gtk.Application:gtk_main_iteration_do (bool) 0x4 in (wrapper managed-to-native) Gtk.Application:gtk_main_iteration_do (bool) 0xffe4 in Gtk.Application:RunIteration (bool) 0xc in MonoDevelop.Ide.Gui.Dialogs.SplashScreenForm:RunMainLoop () 0xe in MonoDevelop.Ide.Gui.Dialogs.SplashScreenForm:SetProgress (double) 0x22 in MonoDevelop.Ide.Gui.Dialogs.SplashScreenForm:MonoDevelop.Core.IProgressMonitor.EndTask () 0x32 in MonoDevelop.Ide.Gui.IdeApp:Initialize (MonoDevelop.Core.IProgressMonitor) 0x660 in MonoDevelop.Ide.Gui.IdeStartup:Run (string[]) 0x8ad in MonoDevelop.Core.AddIns.AddInService:StartApplication (string,string[]) 0x169 in MonoDevelop.Startup.SharpDevelopMain:Main (string[]) 0x39 in (wrapper runtime-invoke) System.Object:runtime_invoke_int_string[] (object,intptr,intptr,intptr) 0xc8c62ac2 Native stacktrace: mono(mono_handle_native_sigsegv+0xf6) [0x801401d6] mono [0x8012857a] /lib/tls/libpthread.so.0 [0xb7e92970] /usr/lib/mozilla/components/libwidget_gtk2.so [0xb18897e5] /usr/lib/mozilla/components/libwidget_gtk2.so [0xb188b9fb] /usr/lib/libgtk-x11-2.0.so.0 [0xb62152cd] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x14b) [0xb5dbf6bb] /usr/lib/libgobject-2.0.so.0 [0xb5dd9239] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x65a) [0xb5dda41a] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x42) [0xb5ddaa02] /usr/lib/libgtk-x11-2.0.so.0 [0xb63435d4] /usr/lib/libgtk-x11-2.0.so.0(gtk_widget_send_expose+0xe1) [0xb6343871] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3bf) [0xb621362f] /usr/lib/libgdk-x11-2.0.so.0 [0xb6056660] /usr/lib/libgdk-x11-2.0.so.0(gdk_window_process_all_updates+0x98) [0xb6056748] /usr/lib/libgtk-x11-2.0.so.0 [0xb615fb87] /usr/lib/libglib-2.0.so.0 [0xb7eded3c] /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x20b) [0xb7edafeb] /usr/lib/libglib-2.0.so.0 [0xb7edcd05] /usr/lib/libglib-2.0.so.0(g_main_context_iteration+0x78) [0xb7edd1d8] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_iteration_do+0x3c) [0xb621175c] [0xb67636a4] [0xb6763655] [0xb6763587] [0xb6766b1b] [0xb676691b] [0xb4794c91] [0xb6c2d5e6] [0xb6e09082] [0xb74c5932] [0xb74c5874] mono [0x8012830b] mono(mono_runtime_invoke+0x46) [0x800a0b56] mono(mono_runtime_exec_main+0x16f) [0x800a54df] mono(mono_runtime_run_main+0x1cf) [0x800a572f] mono(mono_jit_exec+0xbb) [0x8001e74b] mono(mono_main+0x1199) [0x8001f989] mono(main+0x3a) [0x8001e17a] /lib/tls/libc.so.6(__libc_start_main+0xd4) [0xb7d4ff34] mono [0x8001e061] - --- Getting weird results with PAX is casual. However this is what I get AFTER disabling all protections so it shouldn't interfere with PAX or GRSEC. (To make sure I tried running it with a vanilla-kernel. Same results there. Also I downloaded the official binary from the web to make sure that there was no problem with the way my modified GCC treats the sourcecode. It however produced the same results as above. Therefore I do not think that it is a problem in the
Re: [Mono-list] Drawing graphics
Thanks!!! On 8/11/06, Joe Audette [EMAIL PROTECTED] wrote: yes, there's ZedGraph http://zedgraph.org/wiki/index.php?title=Main_Page Joe joe_audette [at] yahoo dotcom http://www.joeaudette.com http://www.mojoportal.com - Original Message From: Arx Henrique [EMAIL PROTECTED] To: mono-list@lists.ximian.com Sent: Friday, August 11, 2006 7:04:19 PM Subject: [Mono-list] Drawing graphics Hello all, Is there some application to drawing graphics (bar and pie chart) in asp.net running on mono ? Would be nice if be free too :D Cheers Arx Cruz -- A fé remove montanhas, mas eu prefiro a dinamite ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- A fé remove montanhas, mas eu prefiro a dinamite ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Miguel (on MS opensource) mentioned compiz-sharp
after googling and google-news'ing i am only seeing http://git.ndesk.org/ i would love to have a 3D cube on compiz for my V desktop selection. i also need to get some kde features into compiz (i.e. remember where windows should sit (using 2-3 monitors Xinerama and need to enforce where windows launch to) , and pinning windows) I also love to have it that when i get new mail, that i could say trigger blue water rain (for a few seconds) on the desktop, etc. so compiz-sharp sounds like the vehicle to do this, but I can't find a home web site for it, anyone one of anymore links? or is this puppy brand spank'n new, with no real home/community yet? -tl ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
