[Mono-dev] [Mono-devel-list] Operating System in C# Project

Mauricio Henriquez buho-1 at entelchile.net
Mon Oct 30 20:04:16 EST 2006

all that I mention is in C#, please keep in mind that is a "probe of 
concepts" test code, is not a serious effor as the proposed in this 
thread, I love to work on this proyect, I know about assembler on 
windows, linux and a little IL, I also know a lote of OSs behinds (I'm 
"Operating System" class teacher on my university)


Johann MacDonagh wrote:
> I would love to see what you have accomplished so far. What portion of what
> you mentioned is in C#?
> Mauricio Henriquez wrote:
>> 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.
>> anyone interesting??
>> Mauricio
>> 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.
>>> --Brian
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel.rar
Type: application/x-crossover-rar
Size: 51841 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061030/a4518929/attachment.bin 

More information about the Mono-devel-list mailing list