OSDev.org

Introduction:
Audentia is a x86 micro-objective kernel written in C++ that is designed to be very stable(or semi-stable, depends on the amount of RAM), memory efficient, and very fast. It was started this year, and is being developed on and off.

What is a micro-objective kernel?
A micro-objective kernel is a microkernel that is based around the abstraction of objects. Objects in Audentia store data, and can have functions that they perform. A example is the timer object, which halts execution for a amount of time in ms (wait();).

Status
Key: Planning Developing Done!
Booting (ASM/C++ with ctors and dtors)
GDT
IDT
IRQ
PIT/RTC
Memory Management
VFS
Starting init.
Downloads/Source
If you wish to download the source or the kernel, you can go to Github for the source.
To build the kernel, you need a gcc cross-compiler named i386-elf-gcc with g++ and nasm.
Just run kbuild.sh (To be replaced with a makefile)
The bootable iso is name bootable.iso
Thanks
Thank you for looking at this project, if you have any questions, please post. But nothing too negative,okay?

I have a feeling that his OS doesn't do boundry checks on memory operations.

berkus: Audentia will 'try' to compact the data and or the headers in ram to save space, which might make it slower and possibly less stable (data decompression )

CrypticalCode0: Your instincts are as sharp as a needle. No boundary checks yet, but soon.

~Thanks
~~Lionel

Exactly why paging is not the answer to everything. Out of curiosity, why did you make your kernel object oriented?

berkus wrote:

Lionel wrote:berkus: Audentia will 'try' to compact the data and or the headers in ram to save space, which might make it slower and possibly less stable (data decompression )

Is it designed for systems with very low RAM but very fast processors which usually have nothing to do but re-compress the data all the time? Maybe for systems with a hardware data compression/decompression unit?

If not, I don't see a point - you're still effectively wasting between 2K and 2M on average due to paging.

Maybe he is trying to compress the swap pages to a ram drive? AFAIK some linux does this.

bluemoon wrote:

berkus wrote:

Lionel wrote:berkus: Audentia will 'try' to compact the data and or the headers in ram to save space, which might make it slower and possibly less stable (data decompression )

Is it designed for systems with very low RAM but very fast processors which usually have nothing to do but re-compress the data all the time? Maybe for systems with a hardware data compression/decompression unit?

If not, I don't see a point - you're still effectively wasting between 2K and 2M on average due to paging.

Maybe he is trying to compress the swap pages to a ram drive? AFAIK some linux does this.

I hate when OSes try to do this because I have huge HDDs (approximately 1TB) and virtually no ram (512mb - 1GB). But then its just a hobby OS so I guess its OK.

I was talking about http://code.google.com/p/compcache/, which is a totally different thing.

And in theory you may still use HDD when the ram drive runs out of space.

Yes, compcache was what I was thinking about, and berkus, thanks for pointing that out.
Basically, compcache would be built in, and activate at a threshold, say 70% of Ram.
Paging might be a problem, on very low ram (32mb), but who has an computer that doesn't have at least 256mb?
I'll work on that and get git setup so you can look at the source.

Lionel wrote:but who has an computer that doesn't have at least 256mb?

In this museum? The majority

Never asume anything. Plus the fact that you will test your OS in a VM. I think we do have a spare motherboard lying round at home that is less than 256mb. My school uses 256mb ram computers for desktops, but they have all issued us macs (fuuuuuuuuu...). But that being said, I would enable features based on what the computer can do. i.e. If the computer is capable of PAE then it will enable PAE. I suggest you do the same with comp cache!

ACcurrent wrote:Never asume anything.

Alternatively, never assume anything in your design, but implement for the most common hardware first. Worrying about ancient or low-memory systems at this stage (unless it's a primary goal of the OS) is a form of premature optimization IMO.

Combuster wrote:

Lionel wrote:but who has an computer that doesn't have at least 256mb?

In this museum? The majority

I have a 25MHz, 386 motherboard with 4MB (2MB expansion). Do you think you can run on it? I also have a bunch of 486DX processors I once bought to build something with.

ACcurrent, that is a good idea.
I am trying to do away with "legacy" specs and use more modern specs, though I will still try to make it thin.

Lionel wrote:ACcurrent, that is a good idea.
I am trying to do away with "legacy" specs and use more modern specs, though I will still try to make it thin.

couldn't agree more.. i felt legacy complicated my design too much, and as I've been working on it for well over a year now, by the time i get it usable it might already be legacy

my problem is finding this modern/legacy bar, and keeping ahead of it!

Git is working!
Look at Audentia at GitHub!