[Mono-list] Enumerating ip interfaces
On dotnet on windows Dns.GetHostByName(Dns.GetHostName()).AddressList Gives me a list of all external addresses on the machine. With mono I get back a single address - The loopback address. So how can I find the external interfaces? Thanks Ralph ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: monodevelop on osx - was: [Mono-list] SIGILL in I18N on OSX
Erik Dasque wrote: Hmmm, Yes, I think I had this problem at some point. Set LD_LIBRARY_PATH since you're talking about .so libraries here. Renaming them to dylib won't help, they're not dylibs. So set LD_LIBRARY_PATH the same way you set DYLD_LIBRARY_PATH. Let me know if that fixes it. Erik At 08:14 PM 3/23/2004, Attila Balogh wrote: hello, still on running monodevelop on osx. I get a gtksharpglue dll not found exception. Those are in /usr/local/lib/libgtksharpglue.so, ... (I even renamed them to .dylib, and I tried a entry in the config, no change). at me the first problem is with libgnomeui.so this is the exact message: Unhandled Exception: System.DllNotFoundException: libgnomeui-2.so.0 #0: 0x00011 throw in Gnome.Modules::libgnomeui_module_info_get () #1: 0x0 call in Gnome.Modules::get_UI () #2: 0xa call in MonoDevelop.SharpDevelopMain::Main ([O:0xa5f78] ) Rob suggested to export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/lib, it didn't help either. (i edited /sw/etc/lib/mono/config, .so* -> .dylib already) any ideas, Urs did you get further? Attila ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list tried it, didn't work, exactly the same message. Attila ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] need some help abt .net
Michael J. Ryan wrote: AFAIK, your best bet would be to use the OpenGL Libraries, not sure if there is a project to write a nice OpenGL Wrapper for .Net, but would be surprised if there wasn't... most newer graphics cards have systems that are almost as optimised for OpenGL 2.0 as they are for DirectX 8.1+ further reading.. :) Tao Framework - Misc C# wrappers for OpenGL (used by Axiom) http://www.randyridge.com/Tao/Default.aspx Axiom - C# 3D game engine for .Net http://axiomengine.sourceforge.net/ ExoEngine - A C# OpenGL and Cg 3D Game Engine for .NET http://www.exocortex.org/3dengine/ -- Michael J. Ryan - tracker1(at)theroughnecks(dot)com - www.theroughnecks.net icq: 4935386 - AIM/AOL: azTracker1 - Y!: azTracker1 - MSN/Win: (email) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: monodevelop on osx - was: [Mono-list] SIGILL in I18N on OSX
Attila Balogh wrote: hello, still on running monodevelop on osx. I get a gtksharpglue dll not found exception. Those are in /usr/local/lib/libgtksharpglue.so, ... (I even renamed them to .dylib, and I tried a entry in the config, no change). at me the first problem is with libgnomeui.so this is the exact message: Unhandled Exception: System.DllNotFoundException: libgnomeui-2.so.0 #0: 0x00011 throw in Gnome.Modules::libgnomeui_module_info_get () #1: 0x0 call in Gnome.Modules::get_UI () #2: 0xa call in MonoDevelop.SharpDevelopMain::Main ([O:0xa5f78] ) Rob suggested to export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/lib, it didn't help either. (i edited /sw/etc/lib/mono/config, .so* -> .dylib already) any ideas, Urs did you get further? Attila I did get the same error, though I'm not on osx. The problem was with my distribution. The package was incorrect, and some gnome schemas were missing, etc. Maybe it's the same on osx. Just my 2¢ -- Brice Carpentier aka Br|ce ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
monodevelop on osx - was: [Mono-list] SIGILL in I18N on OSX
hello, still on running monodevelop on osx. I get a gtksharpglue dll not found exception. Those are in /usr/local/lib/libgtksharpglue.so, ... (I even renamed them to .dylib, and I tried a entry in the config, no change). at me the first problem is with libgnomeui.so this is the exact message: Unhandled Exception: System.DllNotFoundException: libgnomeui-2.so.0 #0: 0x00011 throw in Gnome.Modules::libgnomeui_module_info_get () #1: 0x0 call in Gnome.Modules::get_UI () #2: 0xa call in MonoDevelop.SharpDevelopMain::Main ([O:0xa5f78] ) Rob suggested to export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/lib, it didn't help either. (i edited /sw/etc/lib/mono/config, .so* -> .dylib already) any ideas, Urs did you get further? Attila ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] need some help abt .net
Dany Gates wrote: hi, first of all i would like to say that u guys are doing great work by building such a project(mono)! Keep it up!! The Next thing is that i would like to know whether we can build High Quality 3D games using mono in present or in future? My aim is to build a game which can be used on both win and linux platforms ,so building it on .net platform is the best solution. In case of win i would be using managed DirectX9 which has been newly introduced by MS. So are u even planning to introduce something like DirectX in mono so that apps build using DirectX(Managed i.e .NET compatible) can be run on mono (and in turn on linux). Or u are building 3D Graphics support in Graphics lib of mono? It would be of great help if u introduce some equivalent of DirectX in mono. AFAIK, your best bet would be to use the OpenGL Libraries, not sure if there is a project to write a nice OpenGL Wrapper for .Net, but would be surprised if there wasn't... most newer graphics cards have systems that are almost as optimised for OpenGL 2.0 as they are for DirectX 8.1+ ... -- Michael J. Ryan - tracker1(at)theroughnecks(dot)com - www.theroughnecks.net icq: 4935386 - AIM/AOL: azTracker1 - Y!: azTracker1 - MSN/Win: (email) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Finding assemblies with embedded Mono and MONO_PATH
I am learning how to use the Mono embedding API, and I have run into an issue with loading assemblies that I cannot seem to get past. My goal is to be able to take advantage of the $MONO_PATH environment variable when loading assemblies into application domains, but as far as I can tell, the suggested function call, mono_domain_assembly_open(), ignores $MONO_PATH completely. After tracing through the code a few times, I found that mono_assembly_load() searches $MONO_PATH, and I can load my test assembly using that function. However, I cannot figure out how to add the newly loaded assembly to my application domain. My question basically boils down to this: is it valid for me to use mono_assembly_load() instead of mono_domain_assembly_open(), and if so, how do I add the loaded assembly to an application domain? If it is not a good idea for my code to call mono_assembly_load(), should I emulate the relevant calls in mono/metadata/assembly.c so that my code searches $MONO_PATH prior to each call to mono_domain_assembly_open()? -Patrick -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED]| 2274 Howe Hall Room 2624 http://www.vrac.iastate.edu/~patrick/ | http://www.vrac.iastate.edu/ PGP: http://wwwkeys.gpg.cz:11371/pks/lookup?op=get&search=0xEBF86398 signature.asc Description: This is a digitally signed message part
Re: [Mono-list] About performance
On SciMark, the performance drop is much worse, with Mono taking about 2.2X long as .NET. On Tuesday 23 March 2004 7:06 pm, Philippe Lavoie wrote: > Simple inquiry here, > > I have a program which takes 20 seconds with .NET from Microsoft and it > takes 28 seconds on mono (both run are made inside a Windows 2000 > laptop). So it's about 30% slower to run it on mono. The code does > multiple least square fit of data points to generate an array of NURBS > curves, it also use log4net to write log information to a file and it > uses XML deserialization to load all the input data (about 2Mb worth). > So it's heavy on maths (lots a loops) with some IO tasks thrown in. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
On Tue, 2004-03-23 at 10:22, Ben Maurer wrote: > fdOn Tue, 2004-03-23 at 12:34, Noa Resare wrote: > > A solution to this problem would be to have the ability to bootstrap the > > mono environment from a verifiable source. I immediately come to think > > about Portable.NET, since the cscc compiler is written in c and the > > system bootstraps from a standard c environment without any binary code. Thanks for bringing this up. While I don't worry about such issues myself (I download prepackaged binaries all the time), I do enjoy thinking about them. > How did you get gcc on your system? Did you compile it from source? With > what, another gcc compiler? How did you get that gcc compiler? Did it > come with your operating system? I am betting that somewhere along the > line, you got a gcc compiler from somebody else. I have several options for making sure my gcc binaries match the sources, depending on my level of paranoia: bootstrap from a commercial compiler; bootstrap from two different commercial compilers (under different operating systems) and make sure the results are identical; write a C interpreter and bootstrap from that. > What kind of cpu are you running? Intel? AMD? Did you make the chip > yourself, where you there to see it made? Have you inspected it for a > backdoor? Depending on how paranoid you are: Maybe you're worried that some rogue engineer at WizzyCorp added a back door into the WizzyCorp processor. The back door is probably small and subtle (or somebody would have noticed that the engineer's module takes way too much board area, or runs too slowly). It's unlikely to be something like noticing the login process, and accepting a certain password; the engineer doesn't have enough bits of storage for anything that complex. It's more likely to be something like: if you execute some strange instruction sequence, then you get to execute kernel-level code (ring 0, supervisor, whatever). The instruction sequence has to be sufficiently unlikely that people won't stumble across it by accident; only people who know about it ahead of time will create it. Then the solution is never to execute binary code you didn't compile yourself (since the compiler is very unlikely to create this sequence). You could execute untrusted code under a VM like .NET or JVM, or you could execute untrusted machine code under an emulator like bochs or mips64emul. If you're worried about a more pervasive backdoor (due to a conspiracy among several engineers, or authorized by WizzyCorp management), one which might be capable of noticing the login process, then your options get a lot more expensive and worse-performing. One idea is to have two boxes with different processors running the same software. They communicate to the outside world through a single link; all input from the outside world is duplicated to both machines, and output is only allowed back to the outside world if both machines say the same thing. > How about your RAM? Did you see it being made? Is it possible that there > is some back door hidden in there? I doubt that a rogue engineer could insert a back door into a RAM chip; I'll bet that every RAM design has several engineers who know exactly how many transistors the data goes through and can explain the reason that each transistor is required. If you're still worried about the RAM, then fall back to the multiple-system idea described above; or run under a modified version of bochs, where the emulated machine's main memory is encrypted. > Compared to something like, say a CPU, the mcs/corlib binary that you > get is pretty inspectable. A dedicated person could probably > hand-inspect the output of monodis/ildasm/whatever pnet has in a > reasonable amount of time. Monodis is written 100% in C, so that meets > your trust requirements. The other two implementations could serve as > verification that monodis does not have a backdoor. > > In short, the verification of mcs is probably the least of your > problems. There are much bigger things you would really need to verify, > and mcs is easy in comparison. Even if mcs is easy to verify with a disassembler, that's no reason not to verify the compilation as well. > Or, in essence `We all need somebody to lean on'. Be it the distributor > of your operating system, Intel, AMD, whoever makes your ram (Who does > make ram?), you are going to be relying on something. > > So, what makes distributing binaries secure? There are a few factors > that help out: > > * Who is in charge of the creation process -- the monocharge > tarballs are cooked up inside Novell. This gives you alot of > security. If there were to be a backdoor inside the tarball, you > would have a clear target for blame. This is different than, > say, some random project on SourceForge where there is no clear > path back to the origionator of the binaries. Somebody cant do a > `hit and run' > * How wide of distribution t
Re: [Mono-list] Re: Npgsql doesn't work anymore
Jaroslaw Kowalski wrote: OK. It was my fault. I didn't notice the first AAA message (I ran the tests through nunit) :) My problem was related to invalid hostname in the connection string. I should have used localhost instead of DNS name. After I changed it - it worked. Hmmm, don't you get any NpgsqlException regarding connection problem? Thanks in advance. -- Regards, Francisco Figueiredo Jr. Membro Fundador do Projeto MonoBrasil - MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - "Science without religion is lame; religion without science is blind." ~ Albert Einstein ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
tis 2004-03-23 klockan 20.37 skrev Ben Maurer: > Not really. If you can get a backdoor into the C compiler, you can make > any kernel routine do anything. So, rather than just your app accepting > a backdoor password, i have a nice little rootkit. Of course having a trojan in the system c compiler has other implications, but there are also other ways of verifying the system at that level (multiple c compiler implementatations with different origin, and multiple libc-implementations for example). Self-hosting environments (such as mono and glibc/gcc) have the problem of trojans propagating in binaries without being present in the source. As soon as you can bootstrap the system from something different it makes the trojan-propagation much much more difficult (but not impossible). > I don't think shifting around mcs source code is the correct way to fix > cscc. My point was that while I was doing this experiment simple workarounds in mcs was much easier for me. Of course it would be better in the long run to actually fix the buggy compiler, or at least report the bugs to the proper maintainer. > I am pretty sure that the potential to have a rootkit inside your kernel > is much greater than the risk that mcs is corrupt. And the ability to > detect the former is very low, given that you would pretty much have to > inspect the bytes on your disk with a `clean' computer. On the other hand, bootstrapping gcc from sun cc on a sparc and cross compiling over a gcc to my architecture would decrease the probability that any compiler trojans mess up my kernel kernels. I am happy to hear that the same method can be used for mono with the micrsoft c# compiler. cheers/noa -- And the lions ate the christians and the christians burned the witches, and even I am out of explanations -- Ola Salo gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] About performance
On Tue, 2004-03-23 at 14:49, Philippe Lavoie wrote: > The zipped source + data files takes 6 Mb with .zip. > > Do you know any public FTP I could dump this on? Feel free to send it by email, i can post it. > On a somewhat related note, do you know if the Novell forge uses > subversion? It does not. -- Ben ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] More Mac OS X problems
Abe Gillespie wrote: Thanks to the help of this list I finally got Mono compiled. Now, though, I get "Bus Error" every time I run mcs. (And yes, "mcs" is actually a script that runs mcs.exe via mint as described in the Mac OS X write-up.) I can do "mcs --help" and "mcs --about" w/o problems. But I can't compile anything due to said error. Hm, I'm not getting this with my build of 0.31. I'm doing the 0.31 Fink build I put out yesterday, it seems to work fine (I was actually able to build mcs-0.31 with mint, and I'm giving gtk# another shot right now.) -- Benjamin Reed, a.k.a. RangerRick [EMAIL PROTECTED] / http://ranger.befunk.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] About performance
The zipped source + data files takes 6 Mb with .zip. Do you know any public FTP I could dump this on? On a somewhat related note, do you know if the Novell forge uses subversion? Philippe Lavoie Cactus Commerce eBusiness. All Business. Tel 819.778.0313 x302 * 888.CACTUS.0 * Fax 819.771.0921 www.cactuscommerce.com [EMAIL PROTECTED] -Original Message- From: Ben Maurer [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:12 PM To: Philippe Lavoie Cc: [EMAIL PROTECTED] Subject: Re: [Mono-list] About performance On Tue, 2004-03-23 at 14:06, Philippe Lavoie wrote: > Is this representative of the performance drop we can expect when > going from MS .NET to mono? Anyway, I was just curious. I'm also > curious to know if I'm even allowed to discuss performance > comparisons. If you can send us --profile output, or better yet, source + instructions, we could probably reduce that. -- Ben ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
On Tue, 2004-03-23 at 14:24, Noa Resare wrote: > > In short, the verification of mcs is probably the least of your > > problems. There are much bigger things you would really need to verify, > > and mcs is easy in comparison. > > I disagree. Yes, mcs is "easy" to verify, but it is also a very powerful > point of entry for some black hat since the abstraction level is much > higher than say the CPU or even your average lib/c compiler. > > One can never be totally secure, but an attack that propgagates a trojan > from my cc/libc by the way of the Portable.NET runtime into mcs is > several orders of magnitude more difficult to execute than the attack > that I described in my original post. Not really. If you can get a backdoor into the C compiler, you can make any kernel routine do anything. So, rather than just your app accepting a backdoor password, i have a nice little rootkit. > Then there is hack value, and that is of course the most important > reason for trying bootstrapping mono from Portable.NET. Yep, there is a hack value to this. Just dont trick yourself into thinking that you are enhancing security when you are doing a hack ;-). > > > I just tried to this, with mixed success. A trivial patch to mcs/decl.cs > > > to work around a bug in enum initialization in cscc made mcs.exe > > > compile. Some more kluges applied to to the mcs sources made mcs.exe > > > work in the Portable.NET environment for simple test cases, like > > > compiling a runnable HelloWorld.exe. > > The correct way to go about this is to fix up cscc. MCS's source is > > valid, it can be compiled with csc. > > Of course. But hacknig mcs is so much easier since it's written in a > better language :) If there is ever an officially supported way of > bootstrapping mono with Portable.NET all fixes would of course be > applied on the appropriate places in the respective trees first. I don't think shifting around mcs source code is the correct way to fix cscc. Anyways, where is that hack value? Don't you want to make the software you are touching *less* buggy. > > Also, you can just compile our corlib with cscc, (that is how it was > > created in the first place, mcs and corlib were compiled with csc, and > > scp'd over to linux). > > True, but that would mean that I'd need to buy windows licenses that I > won't use for anything else. What i mean to say is: You do not have to use mcs to compile corlib, you can just use any other c# compiler. MCS is not able to compile corlib on the MS runtime, I would not expect any runtime other than Mono to bootstrap corlib with mcs. > > > > For the reasons stated above, I think this is an effort that will not > > net you any additional security. > > I fail to see how you draw that conclusion. The total security is equal > to the security of the "weakest link" in the chain and you can't know > beforehand which link is weakest. Therefore improving the safeguards > against a certain class of attacks against the distributed mcs/corlib > binaries will give additional security. It might not be much though. And > then there is hack value :) I am pretty sure that the potential to have a rootkit inside your kernel is much greater than the risk that mcs is corrupt. And the ability to detect the former is very low, given that you would pretty much have to inspect the bytes on your disk with a `clean' computer. MCS on the other hand, you could just disassemble. Again, there is a hack value here, but the security benefit is very marginal, I argue that it does not even exist. -- Ben ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
tis 2004-03-23 klockan 19.22 skrev Ben Maurer: > I doubt there is one person in the world who can say that he has > traced the creation of his computer environment from square one Valid point. However, it's all about risk/feasability. Just because I can't verfiy evertything back to the big bang doesn't mean that is's pointless to be somewhat strict about what I do in the environment that I have choosen to trust. > In short, the verification of mcs is probably the least of your > problems. There are much bigger things you would really need to verify, > and mcs is easy in comparison. I disagree. Yes, mcs is "easy" to verify, but it is also a very powerful point of entry for some black hat since the abstraction level is much higher than say the CPU or even your average lib/c compiler. One can never be totally secure, but an attack that propgagates a trojan from my cc/libc by the way of the Portable.NET runtime into mcs is several orders of magnitude more difficult to execute than the attack that I described in my original post. Then there is hack value, and that is of course the most important reason for trying bootstrapping mono from Portable.NET. > > I just tried to this, with mixed success. A trivial patch to mcs/decl.cs > > to work around a bug in enum initialization in cscc made mcs.exe > > compile. Some more kluges applied to to the mcs sources made mcs.exe > > work in the Portable.NET environment for simple test cases, like > > compiling a runnable HelloWorld.exe. > The correct way to go about this is to fix up cscc. MCS's source is > valid, it can be compiled with csc. Of course. But hacknig mcs is so much easier since it's written in a better language :) If there is ever an officially supported way of bootstrapping mono with Portable.NET all fixes would of course be applied on the appropriate places in the respective trees first. > System.Reflection.Emit was never designed to compile corlib. Remember, > csc.exe is written in C++, it uses Microsoft's internal C++ interface to > metadata. To enable mcs to be written in c#, extensions were needed. > > So, if you really want to do this, you would need to replicate the Mono > `magic' methods. Ok. Perhaps something to do when I'm bored someday. > Also, you can just compile our corlib with cscc, (that is how it was > created in the first place, mcs and corlib were compiled with csc, and > scp'd over to linux). True, but that would mean that I'd need to buy windows licenses that I won't use for anything else. > > For the reasons stated above, I think this is an effort that will not > net you any additional security. I fail to see how you draw that conclusion. The total security is equal to the security of the "weakest link" in the chain and you can't know beforehand which link is weakest. Therefore improving the safeguards against a certain class of attacks against the distributed mcs/corlib binaries will give additional security. It might not be much though. And then there is hack value :) cheers/noa -- And the lions ate the christians and the christians burned the witches, and even I am out of explanations -- Ola Salo gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] About performance
On Tue, 2004-03-23 at 14:06, Philippe Lavoie wrote: > Is this representative of the performance drop we can expect when > going from MS .NET to mono? Anyway, I was just curious. Iâm also > curious to know if Iâm even allowed to discuss performance > comparisons. If you can send us --profile output, or better yet, source + instructions, we could probably reduce that. -- Ben ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] More Mac OS X problems
what do you get on ~/mono> mono --version Mono JIT compiler version 0.31.99, (C) 2002-2004 Novell, Inc and Contributors. www.go-mono.com TLS: normal GC:System Boehm (with typed GC) SIGSEGV : normal Globalization: none and you should get ~/mono> mcs --version Mono C# compiler version 0.31.99.0 when making mono using autogen.sh you should see: ~/mono/mono> ./autogen.sh --prefix=/usr/local/ --with-gc=boehm ... config.status: executing depfiles commands GC: boehm ICU: no, if you want full i18n support download it from: http://oss.software.ibm.com/icu/index.html NPTL:yes SIGALTSTACK: no Engine: Building the JIT, defaulting to the interpreter Now type `make' to compile [note I'm not using ICU, but that should have no effect] - Urs On Mar 23, 2004, at 12:11 PM, Abe Gillespie wrote: Thanks to the help of this list I finally got Mono compiled. Now, though, I get "Bus Error" every time I run mcs. (And yes, "mcs" is actually a script that runs mcs.exe via mint as described in the Mac OS X write-up.) I can do "mcs --help" and "mcs --about" w/o problems. But I can't compile anything due to said error. Thanks. -Abe ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] About performance
Simple inquiry here, I have a program which takes 20 seconds with .NET from Microsoft and it takes 28 seconds on mono (both run are made inside a Windows 2000 laptop). So it’s about 30% slower to run it on mono. The code does multiple least square fit of data points to generate an array of NURBS curves, it also use log4net to write log information to a file and it uses XML deserialization to load all the input data (about 2Mb worth). So it’s heavy on maths (lots a loops) with some IO tasks thrown in. Is this representative of the performance drop we can expect when going from MS .NET to mono? Anyway, I was just curious. I’m also curious to know if I’m even allowed to discuss performance comparisons. May the source be with you. Philippe Lavoie Cactus Commerce eBusiness. All Business. Tel 819.778.0313 x302 • 888.CACTUS.0 • Fax 819.771.0921www.cactuscommerce.com [EMAIL PROTECTED]
[Mono-list] More Mac OS X problems
Thanks to the help of this list I finally got Mono compiled. Now, though, I get "Bus Error" every time I run mcs. (And yes, "mcs" is actually a script that runs mcs.exe via mint as described in the Mac OS X write-up.) I can do "mcs --help" and "mcs --about" w/o problems. But I can't compile anything due to said error. Thanks. -Abe
Re: [Mono-list] bootstrapping mono with free software?
Instead of going outside of the project, why don't we just ask to have the distribution files include a PGP signed MD5Hash? This is pretty much standard practice for many projects. rob Noa Resare wrote: Hello friends I had a look at mono again yesterday for about a year away from it, and you guys have really been productive. One thing however that I think is a bit frustrating with mono is that to bootstrap it you distribute quite a lot of binary files (in the mono/runtime directory). This is maybe convinient, but from a security standpoint it means that you need to "blindly" trust whoever has control over the distribution path of the binaries. (Modifying mcs.exe that makes string comparisons always succeed if compared with the magic string "LawrJj4joR6c" and adding code that makes mcs.exe compiled with that "tainted" mcs.exe do the same thing without the source code for it is left as an exercise to the reader. If such a binary was ever included in the mono distribution someone would have a magic password that worked here and there and detecting the backdoor would be non-trivial.) A solution to this problem would be to have the ability to bootstrap the mono environment from a verifiable source. I immediately come to think about Portable.NET, since the cscc compiler is written in c and the system bootstraps from a standard c environment without any binary code. I just tried to this, with mixed success. A trivial patch to mcs/decl.cs to work around a bug in enum initialization in cscc made mcs.exe compile. Some more kluges applied to to the mcs sources made mcs.exe work in the Portable.NET environment for simple test cases, like compiling a runnable HelloWorld.exe. Trying to compile mono's mscorlib.dll however is a completely different experience. Exceptions from Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over the place. So I was hoping that someone with deeper understanding than me of the mono internals could do an estimation on how much work it would need to get mono's corlib to compile with mcs.exe executed from the Portable.NET runtime. These are the non-trivial stuff that fails right now: error CS0518: The predefined type `System.Char*' is not defined or imported the same goes for 'System.Void*' Method SetCorlibTypeBuilders is missing from System.Reflection.Emit.AssemblyBuilder (btw, isn't there a better way to do this than adding non-standard methods to the corlib?) cheers /noa ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] bootstrapping mono with free software?
Noa, > A solution to this problem would be to have the ability to bootstrap the > mono environment from a verifiable source. Or even easier, install from a verified source like red carpet ;-) Simplicity is security's friend. > since the cscc compiler is written in c and the > system bootstraps from a standard c environment without any binary code. Let's get recursive... - your C compiler is (most) probably in binary code, if not - you must compile/assemble your C compiler from source using ... - using physical switch to input binary data; - damn I forgot I don't have the source to my BIOS, nor the plans for my CPU :-( Security is based on trust. Somewhere you must either (a) draw a line where you begin to trust the system (and you're free to choose where to draw it); or (b) use a "wireless brick"(tm) as your computer. Personally I fear a lot more about "honest bugs" that cause security problems. Sebastien Pouliot http://pages.infinit.net/ctech/poupou.html ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
Noa Resare wrote: Trying to compile mono's mscorlib.dll however is a completely different experience. Exceptions from Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over the place. How about running the newly compiled mcs.exe against PNET's corlib to compile Mono's? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
fdOn Tue, 2004-03-23 at 12:34, Noa Resare wrote: > A solution to this problem would be to have the ability to bootstrap the > mono environment from a verifiable source. I immediately come to think > about Portable.NET, since the cscc compiler is written in c and the > system bootstraps from a standard c environment without any binary code. How did you get gcc on your system? Did you compile it from source? With what, another gcc compiler? How did you get that gcc compiler? Did it come with your operating system? I am betting that somewhere along the line, you got a gcc compiler from somebody else. Ok, so lets assume you did not, there is probably enough documentation on how people went from punch card computers to gcc that you would be able to replicate the steps and verify your results. What kind of cpu are you running? Intel? AMD? Did you make the chip yourself, where you there to see it made? Have you inspected it for a backdoor? How about your RAM? Did you see it being made? Is it possible that there is some back door hidden in there? I doubt there is one person in the world who can say that he has traced the creation of his computer environment from square one and is the only person who was involved in creating his computer system, from the mining of the metal (I am sure that there is a way to make the metal corrupt or invalid so that it is a backdoor) to the creation of the CPU to the writing of the compiler. The creation of today's technology has taken a very long time, it is more man-years than one person's lifetime -- by far. Compared to something like, say a CPU, the mcs/corlib binary that you get is pretty inspectable. A dedicated person could probably hand-inspect the output of monodis/ildasm/whatever pnet has in a reasonable amount of time. Monodis is written 100% in C, so that meets your trust requirements. The other two implementations could serve as verification that monodis does not have a backdoor. In short, the verification of mcs is probably the least of your problems. There are much bigger things you would really need to verify, and mcs is easy in comparison. Or, in essence `We all need somebody to lean on'. Be it the distributor of your operating system, Intel, AMD, whoever makes your ram (Who does make ram?), you are going to be relying on something. So, what makes distributing binaries secure? There are a few factors that help out: * Who is in charge of the creation process -- the monocharge tarballs are cooked up inside Novell. This gives you alot of security. If there were to be a backdoor inside the tarball, you would have a clear target for blame. This is different than, say, some random project on SourceForge where there is no clear path back to the origionator of the binaries. Somebody cant do a `hit and run' * How wide of distribution there is -- There are many people using monocharge binaries. That means that there are more people that could notice if there was a backdoor. Real life example: if you are going to murder somebody, where would you do it, in a dark alley or in the middle of a busy street with cars and people. Am betting the first, because fewer people to observe the crime. In the same way, if many people use monocharge, inserting a backdoor has a high risk of getting caught > I just tried to this, with mixed success. A trivial patch to mcs/decl.cs > to work around a bug in enum initialization in cscc made mcs.exe > compile. Some more kluges applied to to the mcs sources made mcs.exe > work in the Portable.NET environment for simple test cases, like > compiling a runnable HelloWorld.exe. The correct way to go about this is to fix up cscc. MCS's source is valid, it can be compiled with csc. > Trying to compile mono's mscorlib.dll however is a completely different > experience. Exceptions from > Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over > the place. > > So I was hoping that someone with deeper understanding than me of the > mono internals could do an estimation on how much work it would need to > get mono's corlib to compile with mcs.exe executed from the Portable.NET > runtime. > > These are the non-trivial stuff that fails right now: > > error CS0518: The predefined type `System.Char*' is not defined or > imported > > the same goes for 'System.Void*' > > Method SetCorlibTypeBuilders is missing from > System.Reflection.Emit.AssemblyBuilder (btw, isn't there a better way to > do this than adding non-standard methods to the corlib?) System.Reflection.Emit was never designed to compile corlib. Remember, csc.exe is written in C++, it uses Microsoft's internal C++ interface to metadata. To enable mcs to be written in c#, extensions were needed. So, if you really want to do this, you would need to replicate the Mono `magic' methods. Also, you can just compile our corlib with cscc, (that is how it was crea
Re: [Mono-list] bootstrapping mono with free software?
I dunno about you, but whenever I'm coding important password routines, I
never use a direct string comparison. In fact, I've never used a straight
comparison outside of testing. I don't like storing raw passwords on disk,
so I store a hash and compare the hash. The exact method in which the hash
is computed is something a hax0r of the MCS binary would not be able to
predict, which leaves only the weakly-coded password systems susceptible :-)
MD5 md5 = new MD5CryptoServiceProvider();
byte[] pwd_hash = md5.ComputeHash("SECRET" + pwd);
for (int i=0; i < 16; i++)
if (pwd_hash[i] != stored_pwd_hash[i])
return Result.AuthenticationFailed;
or whatever. Not to say that your concerns are completely without cause.
I'm sure many programmers don't think too hard about this particular aspect
of security.
Just to be safe, let's add an item to System.String's unit tests to ensure
that not all strings compare as equal to "LawrJj4joR6c" ;-)
Jonathan
At 06:34 PM 23/03/2004 +0100, you wrote:
>Hello friends
>
>I had a look at mono again yesterday for about a year away from it, and
>you guys have really been productive.
>
>One thing however that I think is a bit frustrating with mono is that to
>bootstrap it you distribute quite a lot of binary files (in the
>mono/runtime directory). This is maybe convinient, but from a security
>standpoint it means that you need to "blindly" trust whoever has control
>over the distribution path of the binaries.
>
>(Modifying mcs.exe that makes string comparisons always succeed if
>compared with the magic string "LawrJj4joR6c" and adding code that makes
>mcs.exe compiled with that "tainted" mcs.exe do the same thing without
>the source code for it is left as an exercise to the reader.
>
>If such a binary was ever included in the mono distribution someone
>would have a magic password that worked here and there and detecting the
>backdoor would be non-trivial.)
>
>A solution to this problem would be to have the ability to bootstrap the
>mono environment from a verifiable source. I immediately come to think
>about Portable.NET, since the cscc compiler is written in c and the
>system bootstraps from a standard c environment without any binary code.
>
>I just tried to this, with mixed success. A trivial patch to mcs/decl.cs
>to work around a bug in enum initialization in cscc made mcs.exe
>compile. Some more kluges applied to to the mcs sources made mcs.exe
>work in the Portable.NET environment for simple test cases, like
>compiling a runnable HelloWorld.exe.
>
>Trying to compile mono's mscorlib.dll however is a completely different
>experience. Exceptions from
>Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over
>the place.
>
>So I was hoping that someone with deeper understanding than me of the
>mono internals could do an estimation on how much work it would need to
>get mono's corlib to compile with mcs.exe executed from the Portable.NET
>runtime.
>
>These are the non-trivial stuff that fails right now:
>
>error CS0518: The predefined type `System.Char*' is not defined or
>imported
>
>the same goes for 'System.Void*'
>
>Method SetCorlibTypeBuilders is missing from
>System.Reflection.Emit.AssemblyBuilder (btw, isn't there a better way to
>do this than adding non-standard methods to the corlib?)
>
>cheers
>/noa
>
>--
>And the lions ate the christians and the christians burned the witches,
>and even I am out of explanations -- Ola Salo
>gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09
>
>___
>Mono-list maillist - [EMAIL PROTECTED]
>http://lists.ximian.com/mailman/listinfo/mono-list
>
>
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] bootstrapping mono with free software?
Hello friends I had a look at mono again yesterday for about a year away from it, and you guys have really been productive. One thing however that I think is a bit frustrating with mono is that to bootstrap it you distribute quite a lot of binary files (in the mono/runtime directory). This is maybe convinient, but from a security standpoint it means that you need to "blindly" trust whoever has control over the distribution path of the binaries. (Modifying mcs.exe that makes string comparisons always succeed if compared with the magic string "LawrJj4joR6c" and adding code that makes mcs.exe compiled with that "tainted" mcs.exe do the same thing without the source code for it is left as an exercise to the reader. If such a binary was ever included in the mono distribution someone would have a magic password that worked here and there and detecting the backdoor would be non-trivial.) A solution to this problem would be to have the ability to bootstrap the mono environment from a verifiable source. I immediately come to think about Portable.NET, since the cscc compiler is written in c and the system bootstraps from a standard c environment without any binary code. I just tried to this, with mixed success. A trivial patch to mcs/decl.cs to work around a bug in enum initialization in cscc made mcs.exe compile. Some more kluges applied to to the mcs sources made mcs.exe work in the Portable.NET environment for simple test cases, like compiling a runnable HelloWorld.exe. Trying to compile mono's mscorlib.dll however is a completely different experience. Exceptions from Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over the place. So I was hoping that someone with deeper understanding than me of the mono internals could do an estimation on how much work it would need to get mono's corlib to compile with mcs.exe executed from the Portable.NET runtime. These are the non-trivial stuff that fails right now: error CS0518: The predefined type `System.Char*' is not defined or imported the same goes for 'System.Void*' Method SetCorlibTypeBuilders is missing from System.Reflection.Emit.AssemblyBuilder (btw, isn't there a better way to do this than adding non-standard methods to the corlib?) cheers /noa -- And the lions ate the christians and the christians burned the witches, and even I am out of explanations -- Ola Salo gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Error while installing mono-0.31
Hi, I get the following error while installing mono-0.31. [ When I run configure under mono ] [ I am using Redhat-9.0 ] -> .. creating mint.pc input file mint.pc.in cannot be found . <- What may be the problem? Can anyone please help me? Regards, Deepak.
[Mono-list] Unable to build Mono 0.31
I am using Mandrake Linux 9.2. I hd had a look at the configure options and I cannot find a USE="nptl", how do I go about fixing this problem? The concept of 'USE' flags is pretty unique to Gentoo and is related to the package management system it uses, hence the 'correct' solution above was correct in that it was the Gentoo way to fix it. With Mandrake, the 'correct' way is less obvious to me (I don't use it myself) but, assuming it doesn't ship with the 2.6 kernel + NPTL, you probably want to specify --without-nptl to configure. Thanks, that seems to work, I will test it in the morning. MDK 9.2 uses 2.4, MDK 10 will use 2.6, -- Regards Tracy Barlow Phone: 07 4124 5092 Mobile: 0146 00 38 61 mail: [EMAIL PROTECTED] Website:www.tracyannesoftware.com ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Unable to build Mono 0.31
On Monday 22 Mar 2004 17:01, Richard Torkar wrote: > On Mon, 2004-03-22 at 11:40 +, Rich Wareham wrote: > > On Monday 22 Mar 2004 09:04, Tracy Barlow wrote: > > > I get the following errors when attempting to make Mono 0.31 > > > > ... > > > > > /usr/lib/libgthread-2.0.so /usr/lib/libgmodule-2.0.so -ldl > > > /usr/lib/libglib-2.0.so -licui18n -licuuc -licudata -lnsl -lpthread -lm > > > -lrt -Wl,--rpath -Wl,/usr/local/lib > > > ./.libs/libmono.so: undefined reference to `___tls_get_addr' > > > collect2: ld returned 1 exit status > > > > I had this error crop up when I made an ebuild for 0.31 from the 0.30.1 > > version in Gentoo. It appears that Mono now does different things if it > > thinks NPTL is enabled. Calling ./configure --without-nptl fixed it for > > me. > > The "correct" way to "fix" this problem is to compile glibc using the > nptl flag, i.e. Ta, I actually ended up modifying the ebuild so the presence or absence of the nptl USE flag either triggered or suppressed nptl in Mono, still booting between 2.6 and 2.4 so don't want any overtly 2.6-isms just yet. OTOH 2.6 is pretty stable for me so I might just bite the bullet... -- Rich ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Unable to build Mono 0.31
On Tuesday 23 Mar 2004 10:06, Tracy Barlow wrote: > > On Monday 22 Mar 2004 09:04, Tracy Barlow wrote: > > > I get the following errors when attempting to make Mono 0.31 [ >8 ] > > > > I had this error crop up when I made an ebuild for 0.31 from the 0.30.1 > > version in Gentoo. It appears that Mono now does different things if it > > thinks NPTL is enabled. Calling ./configure --without-nptl fixed it > > The "correct" way to "fix" this problem is to compile glibc using the > nptl flag, i.e. > > USE="nptl" > > and then use the 2.6.* kernels in Gentoo. > > Maybe put this in the FAQ or something, Paolo? [>8] > I am using Mandrake Linux 9.2. I hd had a look at the configure options > and I cannot find a USE="nptl", how do I go about fixing this problem? The concept of 'USE' flags is pretty unique to Gentoo and is related to the package management system it uses, hence the 'correct' solution above was correct in that it was the Gentoo way to fix it. With Mandrake, the 'correct' way is less obvious to me (I don't use it myself) but, assuming it doesn't ship with the 2.6 kernel + NPTL, you probably want to specify --without-nptl to configure. -- Rich ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Unable to build Mono 0.31
> On Monday 22 Mar 2004 09:04, Tracy Barlow wrote: > > I get the following errors when attempting to make Mono 0.31 > > ... > > > /usr/lib/libgthread-2.0.so /usr/lib/libgmodule-2.0.so -ldl > > /usr/lib/libglib-2.0.so -licui18n -licuuc -licudata -lnsl -lpthread -lm > > -lrt -Wl,--rpath -Wl,/usr/local/lib > > ./.libs/libmono.so: undefined reference to `___tls_get_addr' > > collect2: ld returned 1 exit status > > I had this error crop up when I made an ebuild for 0.31 from the 0.30.1 > version in Gentoo. It appears that Mono now does different things if it > thinks NPTL is enabled. Calling ./configure --without-nptl fixed it for me. The "correct" way to "fix" this problem is to compile glibc using the nptl flag, i.e. USE="nptl" and then use the 2.6.* kernels in Gentoo. Maybe put this in the FAQ or something, Paolo? /Richard I am using Mandrake Linux 9.2. I hd had a look at the configure options and I cannot find a USE="nptl", how do I go about fixing this problem? Usage: ./configure [OPTION]... [VAR=VALUE]... To assign environment variables (e.g., CC, CFLAGS...), specify them as VAR=VALUE. See below for descriptions of some of the useful variables. Defaults for the options are specified in brackets. Configuration: -h, --help display this help and exit --help=shortdisplay options specific to this package --help=recursivedisplay the short help of all the included packages -V, --version display version information and exit -q, --quiet, --silent do not print `checking...' messages --cache-file=FILE cache test results in FILE [disabled] -C, --config-cache alias for `--cache-file=config.cache' -n, --no-create do not create output files --srcdir=DIRfind the sources in DIR [configure dir or `..'] Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] By default, `make install' will install all the files in `/usr/local/bin', `/usr/local/lib' etc. You can specify an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. For better control, use the options below. Fine tuning of the installation directories: --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --datadir=DIR read-only architecture-independent data [PREFIX/share] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIRmodifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIRC header files for non-gcc [/usr/include] --infodir=DIR info documentation [PREFIX/info] --mandir=DIR man documentation [PREFIX/man] System types: --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --disable-sanity-checks really do not use threads (should not be used except in special situations) [default=yes] --enable-shared build shared library [default=yes if GNU ld & ELF] --enable-profilebuild profiled library [default=yes] --enable-omitfp build undebuggable optimized library [default=no] --enable-boundedbuild with runtime bounds checking [default=no] --disable-versioningdo not include versioning information in the library objects [default=yes if supported] --enable-oldest-abi=ABI configure the oldest ABI supported [e.g. 2.2] [default=glibc default] --enable-add-ons[=DIRS...] configure and build add-ons in DIR1,DIR2,... search for add-ons if no parameter given --disable-hidden-pltdo not hide internal function calls to avoid PLT --enable-static-nss build static NSS modules [default=no] --disable-force-install don't force installation of files from this package, even if they are older than the installed files --enable-kernel=VERSION compile for compatibility with kernel not older than VERSION --enable-all-warnings enable all useful warnings gcc can issue Optional Packages: --with-PACKAGE[=ARG]use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --wit
