[Mono-dev] [Mono-devel-list] Operating System in C# Project
buho-1 at entelchile.net
Mon Oct 30 17:43:29 EST 2006
sorry, what is the main idea??, develop a operating system in C#, sorry
I lost the first post.
If that is the case, I have a prototype OS in C# (for educational
pospuses only), offcourse is very, very, very basic, for the moment only
open one or more "proto-assembler" files (like compiled programs), and
allocate memory for each "proceess", define a PCB for each process and
begin the execution of each assembly line with a implementation of the
"Round-Robbin" algorith, also do "context change" to change from one
process to other "ready" process, and show all the execution information.
Brian Crowell wrote:
> jmacdonagh wrote:
>> Glad to see I'm not the only one interested in ths. I've also toyed around
>> with this idea for some time. I began looking at traditional operating
>> system development to learn a little more.
> What interests me most about this is a C# program as a first-class citizen, or really, every API in the system being not only available, but *designed for* managed programs.
> I think a good example of that can be found in Microsoft's DirectX, which we were just discussing. Compare Managed DirectX to XNA. The differences are big. XNA exposes, for the most part, the very same APIs, but in a much more intuitive and friendly manner than Managed DirectX.
> You could consider fully object-oriented operating systems, where the design of the API is every bit as important as its concept. You could organize the system around safe plug-ins, each providing some service to the whole, such as a windowing system, file systems, etc., but which are most importantly *as easy to write as implementing an interface or an abstract base class.*
> I'd be very interested in participating on design of such a thing. I've been trying to teach myself good object-oriented design over the years, and I think I would have some good input to give past the initial problem of booting such an environment.
> Perhaps the project could be approached in two stages? Half where we boot the managed environment, and half where we assume the managed environment. You could design and implement these independently of each other. You could even design a set of classes to emulate the kernel on top of an ordinary runtime, for the purposes of unit testing. One strategy I've become fond of, especially where components and unit testing come into play, is generous use of the IServiceProvider interface; if components accessed kernel objects this way (or a similar way, where you ask for a base class but not a specific implementation), they would neither need to know or care whether they're using the real thing or not.
> Several thoughts. Exciting stuff.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list