Re: [Mono-devel-list] Operating System in C# Project
I had a brief look around on similar work, such as JNode which is an OS written entirely in Java, when I pondered writing an OS like this a while back. The only way I can see this being done is that you build the kernel in C# with unsafe code, a few extra value types for Interupt handling, and a CLR and JIT in managed code. Then to make the thing boot you use the JIT compiler to compile both the JIT, CLR and Kernel into native code (using highest optimisation settings) and use that as an image for GRUB or your own favourite boot loader. JNode have a good framework for drivers and are working on a graphics subsystem which could be used but I think .NET would be faster as it has better access to datatypes and pointers. I also have some space on sourceforge for it if you would like to use it. Iain Jackson Alejandro Serrano wrote: Hi, Is anyone interested in starting a project for doing an operating system completely in managed code, à la Singularity that is being done in Microsoft? I don't know much C or C++, but I'm very knowledgeable on C# and MSIL. So the idea would be to start implementing the CLR in a way that it executes completely by itself, then porting GTK# and something more to make it usable. A far long project!! Thanks in advance, Serras ___ 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-devel-list] Operating System in C# Project
This discussion seems to be a play with words.:) From: Richard Matthias [EMAIL PROTECTED] They have a C# compiler that creates native code directly which helps of course. If this is true then the operating system will not be implemented in managed code it will be only in C#. An operating system can be written in BASIC as well if you have good compiler (with some extra feautes:). From: Elliot Paquette [EMAIL PROTECTED] At some level there will be some unmanaged code, sure, but I think that the environment which you just described, Kornél, could be considered an integral part of an operating system, if not for simplicity's sake the operating system itself. .NET Framework is said to be an integral part of Windows Server 2003 altought I think it is a part and not an integral part of it. But I'm sure that .NET Framework will be an itegral part of Windows Longhorn as it is said to have functionality that will be available through managed code only. From: Elliot Paquette [EMAIL PROTECTED] If you add the extra contraint that only IL code will be executed (as in Singularity), then the unmanaged requirements are further reduced. But saying that an operating system can be implemented using managed code only in a nonsense. Of course the answer depends on what do you mean on managed code. Usually it means something that is based on the CLI and is in IL code. A less extensive interpretation could be if you mean managed code on something that uses the garbage collector. But in both situations the operating system cannot be implemented in managed code as neither CLI nor GC can be based on itself. The lowest level where the CLI can be implemented is the kernel. As a result the kernel itself and the CLI cannot be based on themselves so they cannot be in managed code. And depends on what do you mean on an operating system. If you don't consider the kernel to be part of the operating system then as all the user mode code can be in managed code you can say that the operating system is written entirely in managed code. But the kernel is an important part of the operating system, for example if you use an inefficient kernel the whole operating system will be inefficient. In the world of Unix/Linux it's normal that the kernel and other componets are from different vendors but this doesn't mean that any of these comonets alone are operating systems, this means that the system built from this components is the operating system. An operating system is a complex system that has the ability to run on a computer without any other systems. This means that anything that is required to run integral parts of the operating system has to be integral part as well and if it's removed the operating system is not an operating system anymore. From: Richard Matthias [EMAIL PROTECTED] ...just as skeptical as Kornél manages to take up pages and pages of posts with their complete failure to understand how an OS written in C# could be possible. I am not sceptical. I belive and know that an operating system can be written in C# as it is a language. I only said (because I know) that it cannot be implemented entirely in managed code as it requires a CLI that cannot be implemented in managed code. As of the CLI has to be part of the operating system if you want to run it the operating system itself cannot be implemented entirely in managed code even if it's only unmanaged part is the CLI. As a conclusion an operating system can be implemented entirely in managed code if and only if the native code that the underlaying hardware understands and can execute is IL in other words when the CLI is implemented at hardware level. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Corecompare/Buildbot not working correctly
Could somebody please look into this issue? You can easily see it is not correct if you look in the System.Runtime.InteropServices. In both 1.1 and 2.0 of corecompare lots of the _* Classes are missing, however in SVN all Classes are there. The same is also true for several other changes (e.g. Attribute Class) Perhaps it would be sufficient to force a complete checkout on the buildbot machines? A.Nahr Hi, Gonzalo commited a huge patch for System.Runtime.InteropServices last weekend which should have made corecompare a whole lot happier, however until now none of the changes actually show in corecompare. A.Nahr ___ 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-devel-list] Operating System in C# Project
This depends on what you call managed code. Obviously you need a HAL (because you can't express some direct hardware access in C#) written in another language. Then you need a kenel, which (at least partially) needs to be compiled to processor specific instructions (which can also be done from IL). You still can have code verification and garbage collection at that level even if you compile down to native. Singularity has several other aspects that seem interesting. Especially using exclusively verifyable code and with that they don't need kernel/user mode anymore and they can operate without any hardware context switches which potentially could make a very-high perfomance kernel. Then you have device drivers which singularity reportedly implements in verifyable managed code. And last you have some shell oder execution mechanism, which can obviously be done entirely verifyable managed. A.Nahr - Original Message - From: Kornél Pál [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Friday, May 20, 2005 11:13 PM Subject: Re: [Mono-devel-list] Operating System in C# Project Is anyone interested in starting a project for doing an operating system completely in managed code, à la Singularity that is being done in Microsoft? An operating system cannot be written in managed code. If you will create something like an operating system using managed code it will be only a subsystem on the top of the underlaying operating system and other subsystems like Mono. An operating system is based on the hardware. I think I am not the only person who think so: http://www.google.co.hu/search?hl=enq=define%3Aoperating+system Kornél ___ 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-devel-list] Operating System in C# Project
I only said (because I know) that it cannot be implemented entirely in managed code as it requires a CLI that cannot be implemented in managed code. As of the CLI has to be part of the operating system if you want to run it the operating system itself cannot be implemented entirely in managed code even if it's only unmanaged part is the CLI. Well Kornél, you just said the _very_ same thing as I did. I think the case rests. Oh and by the way, to help clarify my definition of an operating system: Debian is a free operating system (OS) for your computer. An operating system is the set of basic programs and utilities that make your computer run. Debian uses the Linux kernel (the core of an operating system), but most of the basic OS tools come from the GNU project; hence the name GNU/Linux. Anyway, this conversation is rapidly diverging from its poster's intent. What Alejandro proposed is quite possible, and if he wants to do it, he should be able to try without being told he can't. I think it's an interesting project, but I don't know enough about operating system coding to really contribute. Elliot Paquette ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] How to find a bad referenced assembly?
Hi all, I've just stated working with Mono and am trying to use a Java class library. I've converted the Java jar file into a .Net assembly using ikvmc with no errors reported. When I try to reference the generated assembly in Mono (by adding an assembly reference to the dll using Edit References - .Net Assembly in MonoDevelop), I get an error that a referenced assembly file cannot be found. However, the error only tells me that the unfound reference is Assembly 0 -- it does not show me the missing file path. The same error is generated whether or not the solution also has an explicit reference to IKVM.GNU.Classpath.dll (ikmvc reports that it has added this reference to the generated assembly for the Java class library). How can I discover what the missing assembly file path is so the issue can be addressed? I'm running MonoDevelop version 0.7 and Mono version 1.1.6 on Debian Linux. Thanks for any help. Here is the exception reported in MonoDevelop: Error while executing command: AddReference Exception ocurred: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --- System.IO.FileNotFoundException: Assembly 0 referenced from assembly /home/chuck/MetaLINCS/MLCSharp/PlayTest/lucene-1.9-rc1-dev.dll not found in 0x0 unknown method in (wrapper managed-to-native) System.Reflection.Assembly:GetReferencedAssemblies () in 0x0029a MonoDevelop.Services.AssemblyCodeCompletionDatabase:.ctor (System.String baseDir, System.String assemblyName, MonoDevelop.Services.DefaultParserService parserService) in 0x00151 MonoDevelop.Services.DefaultParserService:GetDatabase (System.String baseDir, System.String uri) in 0x00012 MonoDevelop.Services.DefaultParserService:GetDatabase (System.String uri) in 0x000d9 MonoDevelop.Services.DefaultParserService:OnProjectReferencesChanged (System.Object sender, MonoDevelop.Internal.Project.ProjectReferenceEventArgs args) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs (object,MonoDevelop.Internal.Project.ProjectReferenceEventArgs) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs (object,MonoDevelop.Internal.Project.ProjectReferenceEventArgs) in 0x0001d MonoDevelop.Services.ProjectService:OnReferenceAddedToProject (MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in 0x00011 MonoDevelop.Services.ProjectService:NotifyReferenceAddedToProject (System.Object sender, MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs (object,MonoDevelop.Internal.Project.ProjectReferenceEventArgs) in 0x0001d MonoDevelop.Internal.Project.Combine:OnReferenceAddedToProject (MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in 0x00011 MonoDevelop.Internal.Project.Combine:NotifyReferenceAddedToProject (System.Object sender, MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs (object,MonoDevelop.Internal.Project.ProjectReferenceEventArgs) in 0x0001d MonoDevelop.Internal.Project.Project:OnReferenceAddedToProject (MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in 0x00040 MonoDevelop.Internal.Project.Project:NotifyReferenceAddedToProject (MonoDevelop.Internal.Project.ProjectReference reference) in 0x0003a MonoDevelop.Internal.Project.ProjectReferenceCollection:OnInsertComplete (Int32 index, System.Object value) in 0x0007f System.Collections.CollectionBase:System.Collections.IList.Add (System.Object value)--- End of inner exception stack trace --- in 0x00107 System.Reflection.MonoMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) in 0x00017 System.Reflection.MethodBase:Invoke (System.Object obj, System.Object[] parameters) in 0x00015 MonoDevelop.Commands.CommandHandlerInfo:Run (System.Object cmdTarget) in 0x002ea MonoDevelop.Commands.CommandManager:DispatchCommand (System.Object commandId, System.Object dataItem) Chuck ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] How to find a bad referenced assembly?
Hi, Try setting the MONO_LOG_LEVEL env variable to 'debug'. Then the runtime will print out various informal log messages which include which the names and locations of assemblies it tries to load. See the 'mono' man page for more info. Zoltan On 5/21/05, Chuck Williams [EMAIL PROTECTED] wrote: Hi all, I've just stated working with Mono and am trying to use a Java class library. I've converted the Java jar file into a .Net assembly using ikvmc with no errors reported. When I try to reference the generated assembly in Mono (by adding an assembly reference to the dll using Edit References - .Net Assembly in MonoDevelop), I get an error that a referenced assembly file cannot be found. However, the error only tells me that the unfound reference is Assembly 0 -- it does not show me the missing file path. The same error is generated whether or not the solution also has an explicit reference to IKVM.GNU.Classpath.dll (ikmvc reports that it has added this reference to the generated assembly for the Java class library). How can I discover what the missing assembly file path is so the issue can be addressed? I'm running MonoDevelop version 0.7 and Mono version 1.1.6 on Debian Linux. Thanks for any help. Here is the exception reported in MonoDevelop: Error while executing command: AddReference Exception ocurred: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --- System.IO.FileNotFoundException: Assembly 0 referenced from assembly /home/chuck/MetaLINCS/MLCSharp/PlayTest/lucene-1.9-rc1-dev.dll not found in 0x0 unknown method in (wrapper managed-to-native) System.Reflection.Assembly:GetReferencedAssemblies () in 0x0029a MonoDevelop.Services.AssemblyCodeCompletionDatabase:.ctor (System.String baseDir, System.String assemblyName, MonoDevelop.Services.DefaultParserService parserService) in 0x00151 MonoDevelop.Services.DefaultParserService:GetDatabase (System.String baseDir, System.String uri) in 0x00012 MonoDevelop.Services.DefaultParserService:GetDatabase (System.String uri) in 0x000d9 MonoDevelop.Services.DefaultParserService:OnProjectReferencesChanged (System.Object sender, MonoDevelop.Internal.Project.ProjectReferenceEventArgs args) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs (object,MonoDevelop.Internal.Project.ProjectReferenceEventArgs) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs (object,MonoDevelop.Internal.Project.ProjectReferenceEventArgs) in 0x0001d MonoDevelop.Services.ProjectService:OnReferenceAddedToProject (MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in 0x00011 MonoDevelop.Services.ProjectService:NotifyReferenceAddedToProject (System.Object sender, MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs (object,MonoDevelop.Internal.Project.ProjectReferenceEventArgs) in 0x0001d MonoDevelop.Internal.Project.Combine:OnReferenceAddedToProject (MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in 0x00011 MonoDevelop.Internal.Project.Combine:NotifyReferenceAddedToProject (System.Object sender, MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs (object,MonoDevelop.Internal.Project.ProjectReferenceEventArgs) in 0x0001d MonoDevelop.Internal.Project.Project:OnReferenceAddedToProject (MonoDevelop.Internal.Project.ProjectReferenceEventArgs e) in 0x00040 MonoDevelop.Internal.Project.Project:NotifyReferenceAddedToProject (MonoDevelop.Internal.Project.ProjectReference reference) in 0x0003a MonoDevelop.Internal.Project.ProjectReferenceCollection:OnInsertComplete (Int32 index, System.Object value) in 0x0007f System.Collections.CollectionBase:System.Collections.IList.Add (System.Object value)--- End of inner exception stack trace --- in 0x00107 System.Reflection.MonoMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) in 0x00017 System.Reflection.MethodBase:Invoke (System.Object obj, System.Object[] parameters) in 0x00015 MonoDevelop.Commands.CommandHandlerInfo:Run (System.Object cmdTarget) in 0x002ea MonoDevelop.Commands.CommandManager:DispatchCommand (System.Object commandId, System.Object dataItem) Chuck ___ 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-devel-list] Corecompare/Buildbot not working correctly
Fixed. On 5/21/05, Andreas Nahr [EMAIL PROTECTED] wrote: Could somebody please look into this issue? You can easily see it is not correct if you look in the System.Runtime.InteropServices. In both 1.1 and 2.0 of corecompare lots of the _* Classes are missing, however in SVN all Classes are there. The same is also true for several other changes (e.g. Attribute Class) Perhaps it would be sufficient to force a complete checkout on the buildbot machines? A.Nahr Hi, Gonzalo commited a huge patch for System.Runtime.InteropServices last weekend which should have made corecompare a whole lot happier, however until now none of the changes actually show in corecompare. A.Nahr ___ 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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Arguments with spaces when starting external program through System.Diagnostics.Process
Hello everybody,
I try to use the System.Diagnostics.Process class on Debian with Mono
1.1.6, to execute an external program, which takes as first parameter
an absolute pathname. As I do not know anything about the pathname
except that it is a valid file, it may contain spaces.
I use Process.StartInfo.Arguments, which is of type string, to pass
the arguments. However, I discovered that the Mono implementation of
the Process class seems to act like a shell in that it splits the
arguments on whitespaces. I tried to escape spaces using '' and \
, with no success. (The attached program illustrates the problem.)
Hence, my question:
Is it possible to explicitly escape the arguments, or - alternatively
- a way to explicitly set each argument vector on its own? (like
argv[1], argv[2], etc.)
Regards,
Sebastian Nowozin
using System;
using System.Threading;
using System.Diagnostics;
public class
TestProcess
{
public static void TestUseShellFalse ()
{
Process proc = new Process ();
proc.StartInfo.FileName = exampleScript;
proc.StartInfo.Arguments = argument with spaces;
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.UseShellExecute = false;
proc.Start ();
while (proc.HasExited == false)
Thread.Sleep (1000);
Console.WriteLine (TestUseShellFalse: {0}, proc.ExitCode == 0);
}
public static void TestUseShellTrue ()
{
Process proc = new Process ();
proc.StartInfo.FileName = /tmp/exampleScript;
proc.StartInfo.Arguments = argument with spaces;
// In case UseShellExecute is true, we cannot redirect the standard
// output.
proc.StartInfo.RedirectStandardOutput = false;
proc.StartInfo.UseShellExecute = true;
proc.Start ();
while (proc.HasExited == false)
Thread.Sleep (1000);
Console.WriteLine (TestUseShellTrue: {0}, proc.ExitCode == 0);
}
public static void Main (string[] args)
{
TestUseShellFalse ();
TestUseShellTrue ();
}
}
exampleScript
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
