OSDev.org

Nelson wrote:Exactly how much is done in Assembly/C? I read somewhere that some code is written in Unsafe C# so I'd imaging they deal with some form of low level things.

According to what they said in the Channel 9 video, it's about 2% asm (for low-level interrupt handling, etc.), 3% C++ (for the debugger stub, which might be re-used from existing MS tools), and 95% C#. Of the C# code, about 18% of the source files contain at least one "unsafe" block. Most of the unsafe code is probably in the memory manager and kernel GC.

After some wikipedia-ing they seem to use a seemingly private project to convert CLI opcodes to x86 opcodes so I guess that none of the C# code is JIT'ed but converted to native code?

That's right. Apps are compiled to native code at installation time. They're currently using the Bartok compiler, which is the result of another MS research project I think.

Well if I can get my kernel working on x86 machines I was going to attempt to do something like this.

You bring up an interesting point.

My original idea for Sensory was to use a programming language called Sylph (which I never released; don't bothing looking for it ) as the language in which all but the very base of the kernel was written. This turned out to be possible, but not pleasant by any means. ;D My many toy languages usually rely heavily on the tricks of C++ and the STL, so converting Sylph (an interpreted language) to run in kernel land without a prewritten libc turned out to be difficult at best. I still believe, however, that this sort of project is the most elegant operating system idea I've yet had. Thoughts?

Yeah that sounds like a good idea.

I'm creating my OS around a framework, in which you arbitrarily link or autolink modules to form a processing network that does something useful for you, in which you can either specify mostly how to make it or just in abstract terms, letting the autolink do it for you. The kernel uses pure autolinking with each specific type of input being processed by only one module (or none of course), with a bunch for the kernel/user layer. The userland stuff uses autolinking for a given conversion, where you specify the source & destination type as good as possible and the autolinker decides what modules with empty transformation should be linked to give you that output from that input. You then proceed to provide the input and receive the output.

The modules would be usable by a specific interpreted UI language that is thread-neutral in that it doesn't understand threading but is implicitly and inherently threaded, with solely thread-safe objects. This latter language would only be intended to do light processing at some pace, so it's mainly for creating UI's around existing UI objects and input/output types.

You create a conversion from mpeg to img-stream, create a UI program that requests a file open dialog for anything that can produce an image stream and dumps the resulting stream to the screen. Done: one movie player that can play DVD movies and streaming internet movies. Add a HD-DVD decoder and you can play them back using the same program without even as much as restarting it.

My OS will use an IL code that is converted to native code at load time. To speed things up, I'll probably cache the native code in the application and check the machine type at load to make sure I'm using the correct native image.

I don't know what IL code I'll use. I tend to be a software maverick, so I might make my own. Java and CIL seem a bit too specialized to me, but I also want something that is easily verified so it might have to be higher-level than I want.

Would it be better to create a stack based IL or a register based IL (which will be better converted to native code, which would be more compact, which would be easier to verify safety, etc...)?