>
>
>
> Mono is absolutely fantastic; but it was designed, like .Net Framework,
> for
> a classical operating system like Windows\Linux\BSD. We just have to be
> REALLY careful about how much we copy 'n paste from it lest we lock
> ourselves into writing an OS Kernel like Windows\Linux\BSD. I feel if we
> can't make something in Mono (for example, System.IO) work then we ditch
> it
> and re-write it so that it suits our OS. We can always go and abstract it
> in
> a clever way later on in Mono so that we can run .Net assemblies coming
> from
> the Linux Mono world.
>
Well, we've talked alot about having a miniature mscorlib, (we call it
"korlib"). We need some sort of k/corlib to be AOTed in order to support the
JIT (which will be our AOT, AOTed).
Most of OS specific constructs in Mono, are just stubs, that the JIT
intercepts and ties to C/++ code embedded in the Mono runtime.
Theoretically, we would do the same thing - except our support code would be
written in C# and AOTed along with the korlib.
>
> --
>
> Currently the AOT namespace is 'dirty'. We don't find ourselves writing
> against a WindowsXP.Forms.Form class: instead it is tucked away /neatly/
> in
> System.Windows.Forms.Form.
In our defense though, I do have to say that namespace refactoring is
extremely trivial compared to the other obstacles we have to hurtle over.
;-)
> Before our codebase gets really big lets think
> about what the namespaces should really be: i.e. Architecture.Core instead
> of SharpOS.AOT. Obviously it really doesn't matter what we use is the
> Kernel, because no-one ever calls it using 'normal' .Net methodologies.
> Just
> my 2c.
>
Well, actually, some things, such as drivers and other low-level services,
will probably be linked against some part of our kernel. Obviously, the JIT
will use CAS and some sort of identity authentication to enforce that this
is only allowed by trusted modules.
>
> Came up with an temp solution for the JITter. The MS CLR also supports
> precompiled MSIL (create these using the ILASM tool). So shouldn't we? I.e
> .
>
> public static void Load(string file) // Really the wrong sig, but this is
> just a concept.
> {
> String binFile = Path.ChangeExtension(file, ".bin");
> if(File.Exists(binFile))
> {
> LoadBinary(binFile);
> return;
> }
>
> #if JIT
> // TODO: Actually write the JIT.
> JIT.Activate(file);
> #else
> throw new InvalidOperationException("MSIL is not currently
> supported. Please AOT " + file ".");
> #endif
> }
>
> public static void LoadBinary(string file)
> {
> // Execute machine code here.
> }
>
> We've talked about AOTing loads of things, but then we might as well just
be writing another OS. But this still doesn't solve any issues with
generics, and it might present problems with cross-assembly reflection.
*shrug*. Refactoring the AOT to be both an AOT and JIT won't be simple, but
it won't be nearly as complex as some of the things we have to pull off
before and after.
>
>
> Next post on architecture... Didn't want to make this one too long ;).
>
> Great work guys, you guys really have done commendable progress. I am
> really
> impressed: when I first booted it in VMWare I was expecting a lot less.
> Wow.
> Simply amazing. Kudos for all of you.
>
> There have been alot of contributions. Some smaller, (like from me...
*sigh*), and some that consitute most of the project (*eyes DarxKies*).
As far as a scheduling algorithm - as long as we can still expose threading
and appdomains the way the .NET apps expect them, it doesn't matter much how
we write it up under the hood. And like Sander said, its all about the
abstraction. As long as you can abstract out the commonalities, it doesn't
matter what you want - as long as you can code it. ;-P
> Just thinking ahead :). I just think that we don't want to have to write a
> JIT until we actually need it (which is never, really, we could just AOT
> everything every time it is changed). 'nor a JIT compiler' is precisely
> what
> I am getting at: we need to have something in the mean time. When we
> include
> JIT it must fall away by changing/including one line (ideally).
Well, like I said already - AOTing doesn't work when it comes to generics,
and most of the corlib, these days, uses generics - if nothing else but for
interfaces. Not to mention - if we just AOT everything - then we aren't
really solving any problems. This is about having a VMed OS, which we can't
do if we aren't JITing.
But you definitely seem to know what you are talking about, and like Sander,
I encourage you to jump in and get as involved as possible. I'll see if I
can't shoot out some more e-mails to stir up our status quo a bit, so that
we can find something for everyone to do.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
