[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)
Mauricio
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