[Mono-list] Mono port to other OS

[Thomas Krause]

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: mono-list-bounces at lists.ximian.com
[mailto:mono-list-bounces at lists.ximian.com] On Behalf Of Paolo Molaro
Sent: Friday, August 12, 2005 4:22 PM
To: mono-list at lists.ximian.com
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

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better
_______________________________________________
Mono-list maillist  -  Mono-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list