OSDev.org

Hi, i finally uploaded my operating system. FDC makes my system freeze and switcher to real mode do not work, so, it can't load GUI shell. If anyone wants to check it, there is old image of that GUI:

I renamed my OS to Blue Desert yesterday, and because this is old version it have old name (ParticleOS):



Anyways, there is image of current version:



Also, there is boot screen:



And memory viewer:



Want to try it?
Download it:
Website link : http://bluedesert.netai.net

Why's no one replying? Is there something wrong with my OS!?

I don't mean any offense by this, but probably by the kind of questions you have been recently asking, people can see you are not experienced, and therefore do not expect much of your work.

It looks nice

I might recommend printing memory addresses in hex. It may prove to be more readable - especially when viewing a large list of them.
But that's just my 2 cents.

Didn't see this one until now -- its a good start. Wouldn't call it 0.0.1 just yet though. Are those programs running in user mode or is the entire console running in the kernel? You should be able to boot the graphics shell by just setting the mode during boot and accessing the LFB in protected mode. I didn't try it yet, will try it when I can and let you know how it runs here. Nice start.

Second using hex in the memory viewer -- so much easier to read then base 10. Who uses base 10 anyways?

For the calculator, one possible approach you might want to try in the next release is to have it so the user types in a whole expression and it gets computed. One easy way to do this is converting infix to prefix notation [e.g. 2 + 3 into + 2 3] and then using a stack to evaluate it.

Or you could write a recursive equation parser - something which I've been meaning to try for a while.

Actually runs pretty well on VMWare. The shell command crashes it with a #GPF but that was expected. Typing "1=2" in the add command of calc produced -4110468 rather then an "invalid syntax" handler. The unknown option 6 produced weird results (hard to explain what happens, but it does not crash), apparently 2/9x10^36 = 26, who knew? (I didn't use scientific notation on input, just using it here for my sake. I was watching for overflow detection.) Doesn't appear to support doubles/floats. It accepts "no number" as "zero" (i don't know if this was the intent or not.) Typing "3" in "exit" command displayed a different character.

So, pretty much only problems I found were in the calc program. Besides the expected #GPF, the system ran quite smoothly. Nice work

Using a proper parser (like recursive descent) would probably be the best long term goal for the calc program (write it in user mode and port it - always easier that way.) I just mentioned the stack method cus I figured it would be easier - but tbh both methods aren't too hard, its just that the recursive descent method might be hard if you haven't done much of formal language theory.

User mode -- Am i crazy to use kernel mode for that!?

Thanks
Calculator was just test for itoa and atoi. It will be reimplemented for some amount of time.
Hex output was already implemented and plot into memview.
Big amount of code were entirely rewriteen (keyboard driver, PIT driver (partially), GDT driver, etc.)
FAT12 in progress (but i still can't get floppy driver working xD)

I think it's opposite. Because i'm "unexperienced" it should be interesting to see what newbie wrote.