How about a CIL Operating System Standards Organisation? I have created a mailing list at http://groups.google.com/group/cosso for anyone who is interested.
On 04/02/2008, Bruce Markham <[EMAIL PROTECTED]> wrote: > On Feb 4, 2008 12:10 AM, Jonathan Dickinson <[EMAIL PROTECTED]> wrote: > > > Some solid ideas bruce. I think the intptr stuff is crucial, because > > that would make us future compliant (think 128-architectures). You > > could always hardwire the compiler to uint* or ulong* etc. if > > performance is an issue (or at least inline all the intptr methods). > > IntPtr is always void* (it wraps it) . And void* is always a native pointer. > But since the IntPtr wraps void* in a struct, it requires extra overhead to > be "converting" all the time. > > > I also think it is crucial that we agree on a driver arch, nvidia etc. > > wont bother writing drivers for two c# operating systems, we have to > > make sure we both take advantage of what we are given. > > > > I personally agree with you very much on that. Cooperation will save alot of > people alot of work for both our projects. > > > We also have to be careful to what extent we box in drivers, we dont > > want to go over-the-top with safety: some drivers may land up being > > impossible to write! I think drivers will always remain low-level > > beasts of dark code-ninjaness. Abstractions are awesome, but for the > > same reason m$ provided p/invoke we should supply a/invoke (arch > > invoke). > > > > Thats a vague statement, and I guess part of this conversation is > determining how specific we can make the abstraction. For example, I'm > personally under the interpretation that in the end, all drivers are pretty > much doing writes to/from I/O ports. > > "a/invoke" is an interesting colloquialism, but I have an earnest hope that > with the right abstraction, it won't be necessary. But we need more > discussion before that can be evaluated. > > > > > I like to keep a lazy eye on you guys, and i must say, good progress! > > > > > > > > > > Cosmos, as well, has made good progress, in its short existence. Since > SharpOS is the easier of accessibility of our two mailing lists, I would > recommend that you and your comrades do more than "keep a lazy eye" if we > want to work together on this. ;-) > > > ------------------------------------------------------------------------- > 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 > > -- Jonathan ------------------------------------------------------------------------- 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
