Page 1 of 1

HFMOS 0.0.0

Posted: Mon Jan 16, 2006 12:10 am
by Kevin McGuire
Here is a demo of the kernel. This demo contains a:
1. 1.44MB Floppy Image
A. Contents
???-----------------------------------------------------------
???- GRUB
??????- \boot\menu.cfg
?????????Contains:
????????????timeout 0
????????????title hfmos
???????????????kernel /kernel/kernel
???????????????modulenounzip /firstapp.dll
???????????????modulenounzip /firstapp.dll
???????????????modulenounzip /firstapp.dll
???????????????modulenounzip /tuis.dll
???????????????modulenounzip /ks.dll
?????????The OS has no floppy driver. So I make do.
???-----------------------------------------------------------
???- kernel
?????????Supports/Features:
????????????- non-paged kernel
????????????- pagged processes
????????????- memory managment
????????????- processes/thread
????????????- simple round-robin scheduler
????????????- IPC using packet scheme
???-----------------------------------------------------------
???- firstapp.dll
?????????1. Establishes connection to TUIS, for VGA buffer.
?????????2. Establishes connection to KS, for keyboard buffer.
?????????3. When VGA buffer is active on screen. Echos keys typed.
?????????This program is loaded as three different processes to demo
?????????the TUIS.
???-----------------------------------------------------------
???- tuis.dll
?????????1. Establishes connection to KS, for buffer/screen switching.
?????????Use F1 - F10 to change buffers/screens.
???-----------------------------------------------------------
???- ks.dll
?????????1. Waits for connections.
--------------------------------------------------------------------
B. About
The kernel uses a implementation that will allow distributed processing across networks, and local processing using a high speed large thoughput architecture using packets for process communication. This demo is to show the network architecture in use with local processes.
C. Future Fixs/Features/Additions/Replacements
???1. [Fix+Addition] The scheduler uses a *too* simple round robin design.
???This causes the kernel to have very bad performance.
???Threads have no sleep abilitys. So polling is constantly done.

???2. [Replacement] The demo uses TUIS and KS.
???These are not actual planned componets for the final design.
???They are only for a demo purpose.

???3. [Addition] The kernel has no function to destroy processes or threads. I really did not need them.

???4. [Fix+Addition] The kernel creates processes as ring 0 by default. I would like to extend this to
???support the creation of ring 3 processes for actual usercode.

???5. [Addition] The kernel does not recognize layers at the moment. The support data-types are there, and
???are accessed but ignored. Layers are what will support distributed processing, and distributed users/data.

???6. [Fix+Addition] The kernel does not fully utilize error recovery in situations involing memory allocations.
???Most functions from the subsystem support return types with errors, but no large amount of kernel code actually
???checks these returns for errors.

???7. [Addition] The kernel needs a private text buffer, that can be accessed via the net subsystem. This can be used
???for boot-up logging and error tracking when debugging is enabled at compile time.
???
???9. [Feature+Addition] The kernel supports loading PE32 *non-relocatable* DLLs. I want it to support loading
???relocatable PE32 and COFF formats.

???10. [Addition] I would like the kernel to support small ISR routines written in a safe language to run in kernel
???space when a IRQ occures. These routines would be able to handle hardware enough to allow data to be passed back
???to the actual driver or service to be processed. The removal of actual ISR routines and hardware I/O from non-kernel
???processes.

2. Source code
???The source includes the kernel, application, and services written using MSVC Express.

I have posted a new disk image. This fixes the super laggy performance. I did not realize the frequency of my PIT was so low. You can access the latest disk image at:

floppy.hfmos.0-0-1.img
http://mcguire.sytes.net:6080/

Re:HFMOS 0.0.3

Posted: Wed Jan 18, 2006 11:53 pm
by Kevin McGuire
I have changed it up a bit. I changed the kernel to use a private text buffer instead of 0xB8000. I also rewrote TUI(Text User Interface) to include the KS(Keyboard Service). I wrote a process viewer program. It querys the kernel for a list of processes and threads, by pressing A on the keyboard. I also added in the ability to scroll the VGA buffers, and gave TUI the option of showing current clients. The kernel's text buffer can also be accessed using F1-F10, it should be at F3 if you do not change anything. It has a 200 line buffer, compared to 20 line buffers for everything else.

ALL the code, at its current version is posted in HTML format using docygen is at:
http://mcguire.sytes.net:6080/hfmos/Source/Kernel/html/
http://mcguire.sytes.net:6080/hfmos/Source/Apps/html/

A premade floppy disk image is at:
http://mcguire.sytes.net:6080/hfmos/Images/

A moderately detailed journal:
http://spaces.msn.com/members/hfmos/

This was not a minor or major version change. I would have put more, but I am about to rewrite the kernel protocol to make things work MUCH nicer - hopefully.

Tell me what you think, I know it doesn't do much but anything else. :)

1. [Fix+Addition] The scheduler uses a *too* simple round robin design.
This causes the kernel to have very bad performance.

1. Threads have no sleep abilitys. So polling is constantly done.

2. [Replacement] The demo uses TUIS and KS.
These are not actual planned componets for the final design.
They are only for a demo purpose.

2. Expand on text interface, until kernel is fully complete.

3. [Addition] The kernel has no function to destroy processes or threads. I really did not need them.

4. [Fix+Addition] The kernel creates processes as ring 0 by default. I would like to extend this to
support the creation of ring 3 processes for actual usercode.

5. [Addition] The kernel does not recognize layers at the moment. The support data-types are there, and
are accessed but ignored. Layers are what will support distributed processing, and distributed users/data.

6. [Fix+Addition] The kernel does not fully utilize error recovery in situations involing memory allocations.
Most functions from the subsystem support return types with errors, but no large amount of kernel code actually
checks these returns for errors.

7. [Addition] The kernel needs a private text buffer, that can be accessed via the net subsystem. This can be used
for boot-up logging and error tracking when debugging is enabled at compile time.


9. [Feature+Addition] The kernel supports loading PE32 *non-relocatable* DLLs. I want it to support loading
relocatable PE32 and COFF formats.

10. [Addition] I would like the kernel to support small ISR routines written in a safe language to run in kernel
space when a IRQ occures. These routines would be able to handle hardware enough to allow data to be passed back
to the actual driver or service to be processed. The removal of actual ISR routines and hardware I/O from non-kernel
processes.

Re:HFMOS 0.0.0

Posted: Thu Jan 19, 2006 4:01 am
by Pype.Clicker
<download in progress 553/1440KB... watching the green thing that jumps>
<still 553/1440 two hours later -- no i'm no longer watching the green thing, for those who wonder>

oh, btw, "sources/kernel/html" cannot be opened properly here. It says the data are "application/octet-stream" and asks for a helper application to open it... "/man" and "/latex" worked fine, though.

Re:HFMOS 0.0.0

Posted: Fri Jan 20, 2006 4:35 am
by Kevin McGuire
I got it fixed.

Re:HFMOS 0.0.0

Posted: Fri Jan 20, 2006 5:37 am
by Pype.Clicker
hard to tell if it goes correctly since i don't know much what it's supposed to do, but it loads fine, allows me to switch consoles (though F4-F10 seems unresponding), and show the list of running consoles.

(tested on Qemu)

Re:HFMOS 0.0.0

Posted: Fri Jan 20, 2006 6:24 am
by kataklinger
I have tested on Bochs, I haven't FDD on my real computer ;D

Input is very slow.

Re:HFMOS 0.0.0

Posted: Fri Jan 20, 2006 7:00 am
by Pype.Clicker
kataklinger wrote: Input is very slow.
confirming that. it seems that you have an 'idle loop' somewhere that could be using "hlt" ...