I know that CIL can contain unsafe code constructs, but these would of course be forbidden on the system (or restricted to some system libraries).
Why should I make my OS Posix compatible, if I allow running .NET code only, which does not care about Posix compatibility? Since the mono I/O layer seems to be just a wrapper to emulate windows api functions, I plan to make my library functions look more like windows, so that implementing the IO-Layer gets easy. For the parts of mono that do directly depend on a specific api (glib, signal, or whatever), I will wrap or implement the necessary functions where needed. I did not say that I won't implement glib functions or anything POSIX related. I only said that I won't implement these completely. I will implement as many functions as needed by Mono, but not many more. Thanks, Thomas Krause -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paolo Molaro Sent: Friday, August 12, 2005 4:22 PM To: [email protected] Subject: Re: [Mono-list] Mono port to other OS On 08/10/05 Thomas Krause wrote: > This architecture makes some things very easy. For example I don't need to > implement context switching (kernel mode / user mode), because direct memory > access will never occur in the CIL, but only in the jitted code, which (as > long as the jitter works correctly) will not corrupt any kernel memory. CIL also defines unsafe code and the jit correctly executes it and it can be used to compromise your system. > I do not intend to be POSIX compatible in any way. Libc is partly > implemented already, but sometimes with different names / parameters. Doesn't sound like a good idea to me. > Are the libc-calls wrapped through the I/O layer or are they directly used? They are used directly and there is no plan to wrap them inn any way, it would make the code ugly for no benefit. > Are these the only dependencies to build a basic mono runtime (libc and I/O > layer) or is there anything else? (I assume that some parts of the framework > have other dependencies (System.Drawing, System.Data, ...), but for the > beginning I should not need these). We use signals, GLib as well as the GC and some sysv features as it has been pointed out: most of this stuff has interfaces that should allow easy porting. But if you won't implement basic libc correctly, I guess you have already your shares of issues than dealing with the high-level libraries and assemblies. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ 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
