Here is my best impression on where the project stands. I encourage everyone
to jump in and comment if you know something, or have suggestions, about the
relevant topics. (New threads would be best, right here I'm just trying to
spark it up.)

Everything here that is directly related to coding, will get made into tasks
based on the input that is provided, so that the group can function once
more, now that the long outage of the trunk kernel being near useless, is
over. Hurray for Chriss fixing it! (Did everyone poke xfury enough?
Remember, we still need him, so don't poke him too hard. ;-P ) (For the
record, I attempted to fix the kernel, and completely skipped over what
ended up being the culprit. Thats what *I* get for being sloppy...)

Governance Issues
We still need to work out licensing. We are rather split on whether or not
we should license different components differently, so that particular
discussion has definitely not matured yet - though it has stagnated.

I can't recall directly, but I think there are other outstanding governance
issues, that the governance board has stagnated on. Remember, if you read
the sharpos-board archives, and you aren't a member of the board, you can
still submit opinions and requests to the respective list, its just
moderated first.

Kernel Bugs
It appears that somewhere between Foundation.Convert.ToString(...) and
TextMode.Write(int), that integers are being printed in reverse. At least,
for the timer display they are. (I have no way of telling, when it comes to
the memory addresses, but since the code paths meet at TextMode.Write(int),
I believe they are affected as well.) All the loops appear to be going in
the right direction, but it prints the digits backwards, and it adds a
couple zeroes to the front (of the end result). Obviously, I can reverse the
printing loop, and it prints mostly correctly, with the exception of the
mysterious trailing 0's (always two, no matter how big the number seems to
get.)

KeyMap functionality is still not in a functioning state. Hopefully xfury
will take a peek, *wink wink*, and if not, I'll look into it eventually,
though I can't promise anything because I'll basically have to read through
every piece of code that he has written that centers around that
functionality. If we can't get it working soon, we will have to hard-code
US-101 into the kernel, as actual C# code, so that we can temporarily bypass
the issue, and proceed forward with other things, like console support.

xfury has informed us that paging doesn't work, and that it is disabled for
now. We can avoid it for now. I think its a safely avoided issue for now.
Anyone that wants to take a look is most welcome to.

Kernel/AOT Runtime Bindings
I think we also need to work out a definition of what runtime objects look
like on the stack, and in memory, and work out - even if its just basic and
simplistic - vtable storage and lookup code. Then we would be a hop and a
skip away from actually beginning to *use* some of that korlib code... ;-)
I suggest, since the IRC channel has been completely dead for nearly two
weeks, (not counting a couple lurkers - and to them, I apologize, we are
normally more interesting than that), that we open that discussion up here.
I don't think it would be to much work - we will have to compare notes with
Mono, and verify that memory management focuses on at least a basic level.

One of the issues involved with this has to do with garbage collection. I
believe some preliminary work has been done on this, but nothing has been
suitable for integration into the trunk, as of yet. I think, that we might
be able to set up a low-level kernel system that uses a timer to make the
sweeps, but most of the GC algorithm stuff is currently beyond me, so I'd
prefer not to touch it myself...

Preliminary Korlib Work
It appears some preliminary work has been going on with the korlib. If we
can hash out some of those basic runtime bindings, the AOT can start
handling kernel code that wants to use some basic things from mscorlib.
Interfaces, array lists, bonafide managed strings (with all the strings,
bells, and whistles attached), System.Console, System.IO.Stream (I drool at
the thought), etc. I think we can even pull off System.DateTime. (We can
write an ADC path to retrieve the hardware time. I think I'm having a
nerdgasm just *thinking* about it...)

AOT Test Cases
Also, upon Chriss' suggestion, I've been surveying the Rotor test cases. I
read the (relatively short and simple) license ahead of time, and it is
permissible to learn from the code, and apply gained knowledge elsewhere.
(However, I'm not having much luck determining how to "get started", I guess
I might need to read the ECMA spec for CIL.) Anyone else willing to lend a
hand, let us know. There is a wiki page that loosely covers the basics -
after all, test cases aren't a difficult concept. And if you need
suggestions for test cases to write, I'm sure Chriss can help you out.

other room for AOT work - floating point
Something else, that has been ignored for forever and a day, is the need for
floating point in the AOT. I looked into it once, and got completely
confused by various conflicting terminologies I found on the internet.
However, we definitely need it. (Such as, for the scheduler.)

Chriss has done some amazing work at simplifying the AOT, but there is only
so much that can be done. If you want to help out with this, then you need
to get the code from SVN, and start spamming Chriss with e-mails with AOT
questions. Be heard! Get involved!

Food For Thought
With runtime bindings, console support, and preliminary korlib - we should
be able to look at integrating xfury's command-line shell, "nash". (I hope
he didn't use anything that the AOT can't AOT, or it might be a year or more
before we can seriously consider this...)

Other potential side-projects, more or less useful to SharpOS at present
time:
* there has been experimentation with a Window system, SharpWS. I haven't
personally looked at it, it hasn't been discussed group-wide, so I don't
think we can call it an "official" SharpOS pursuit, but I'm definitely
excited that the preliminary work has been done. If it picks up momentum, it
may manage to get done before the rest of SharpOS is ready for it, and we
will be good to go when we are. Hit xfury up for more information.
* Before we start talking about full-grown graphics, we will definitely need
some text-based UI action. There have been a few attempts to wrap up
ncurses. I don't think there is a fully managed version. Anyone that can
hack something together for SharpOS will help us along a good ways.
* Drivers - anyone that wants to draft up some documentation on a potential
driver abstraction layer and architecture, start talking about it now. The
sooner we can define a model for drivers, the sooner we can start working on
them. (If you expect pretty SharpOS GUI action, this is where you need to
start...)
* nash will be great, but we won't be a good open-source OS unless we have
50 million different shells. Discussion and experimentation with other
options is most welcome. (IronPython shell? PowerShell port?) You could
easily go off on a completely non-SharpOS tangent (and be busy for a *long*
time) with some of these ideas, and still help us out. This isn't all about
x86 and hardware interrupts...
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
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

Reply via email to