I'm going to have to respond to this non-sequitor.
The "korlib" exists as a way to map and glue pieces of the runtime together.
Virtual Execution System icall's from the Mono corlib will be glued to
methods we have written in "korlib" - and since these methods will require
access to what would normally be private members, of any corlib type
involved, we have replicated a few of these types in the korlib for that
purpose.
>
> I'm unfortunately in the situation of needing a couple of things in
> Korlib.
> Specifically that is
>
> - System.String.Split
> - System.String.Concat(string, string, string)
> - System.String..ctor(char, int)
> - System.String.Empty
> - System.IO.Path.AltDirectorySeparatorChar
> - System.IO.Path.DirectorySeparatorChar
> - System.IO.FileAccess
> - System.IO.FileMode
Drop them in as you need to, just stick to the patterns we are already
using.
>
> - Object.ReferenceEquals (implementation exists as Object.Equals, but its
> the wrong place for it imho - I made one myself there.)
> - and probably some more I've just missed
>
> Now a couple of questions:
>
> - What is the long term goal for Korlib? Are we going to merge monos
> corlib?
No. We will be AOTing Mono's corlib with our kernel - and the AOT will glue
them together, making Mono's corlib work by using our "korlib" as the
underpinning.
>
> - Shall I implement those functions and provide them as patches?
If you need them right away, go ahead and drop them in - just remember that
most of it will probably be tossed out once we are embedding the corlib into
the kernel.
>
> - Is K(orlib) our K(ernel-Mode) BCL or are we going to use one BCL for
> all?
We had actually talked, for the longest time, about having a seperate,
kernel-mode corlib, hence the name "korlib". But the present attitude is,
one single korlib, that the Mono corlib is AOTed to use.
Since our korlib will actually sit on top of some managed systems (hardware
resource manager, driver system, virtual filesystem, network stack, etc.)
the korlib will eventually have to be aware of these systems - and any
subset of it that happens to be attempted to be used, by higher-up code,
before involved systems are fully started, we will just bubble an exception
up.
>
> - How strict do we want to adhere to Microsofts implementation and types
> in
> those namespaces?
>
Its not an issue since we are using Mono's corlib for 95% of our combined
effective corlib, and it will all only be exposed as just the Mono/Microsoft
corlib to userspace processes.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
