Bruce wrote: > 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. >
Getting there, obviously. Have to keep poking ourselves to move along. :D > 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.) > This almost sounds like some type of endianness issue, though I don't see how considering it's all built on the same platform. > 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...) > Yeah, this is definitely VM / runtime area. Same with scheduling and such else. Was hoping we'd finish other discussions before we got into the VM and such. But I'll start posting up other threads about this if we're there. Just don't want the list to get diluted with too many topics at the same time. :) > * 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...) Again, didn't want to dilute the list with too many discussions at once. I've got ideas for a driver framework, VFS layer, etc when we get there. One thing I might caution is whether additional stubs to the AOT *really* need to be made, or if such hardware access can be accomplished with a simple wrapped private unsafe method and a pointer. Remember we've also currently got X86.Asm.* and friends for direct assembly writing. > * 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... I once had a discussion years back with some other programmers about a textual non-prompt-type command interface. A shell that is something along the lines, vaguely, of Smalltalk's object explorer, and the Factor programming language's interactive editor (http://www.factorcode.org). It gets hard to explain, but it's something more interactive and useful than just a simple prompt, which even PowerShell is. It's a command interface, an object explorer, etc. Still accessible over SSH and purely text / curses, so it's still accessible via those means. But maybe like a souped-up version of Midnight Commander meets PowerShell meets... err... The old (but cool) database management and manipulation systems of AS/400 and such? ------------------------------------------------------------------------- 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
