This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
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):
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.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
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.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
neon wrote: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.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
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.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
neon wrote: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.
User mode -- Am i crazy to use kernel mode for that!?
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.
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)
Last edited by Ycep on Thu Aug 25, 2016 7:33 am, edited 1 time in total.
