Page 66 of 262
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 18, 2011 9:40 pm
by Chandra
Hello Everyone,
Finally, I thought to release some snapshots of my Operating System. Here are few of them
1. Desktop
2. Start Menu
3. Explorer
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 18, 2011 9:46 pm
by Chandra
Continued...
4. E-Photo (The Built-in Image & Photo Editor)
5. E-text (The Built-in Text Editor)
6. Right Click Menu
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 18, 2011 9:54 pm
by gzaloprgm
Woah, looks like a really nice clean UI... I would only change the font to one a bit more readable (maybe bolder?)
Re: What does your OS look like? (Screen Shots..)
Posted: Tue Jan 18, 2011 10:13 pm
by Chandra
gzaloprgm wrote:Woah, looks like a really nice clean UI...
Thanks.
gzaloprgm wrote:I would only change the font to one a bit more readable (maybe bolder?)
For Sure. Recently, working on 'Crystal Clear' font. Let's see, if I will be able to implement this on my next release.
Regards,
Chandra
Re: What does your OS look like? (Screen Shots..)
Posted: Wed Jan 19, 2011 9:50 am
by CWood
nicely done, Chandra! Things I was impressed with, with your OS (some of them require logical deduction to see where I got them from):
USB support - this seems to be the one thing that alludes me to date. I have tried time and time again... Very well done.
Fully fledged API - one thing I have to ask, is the API interrupt based, or dynamic library based?
Clean looking GUI - One of the things that is often most sought after by end users, and can sometimes be quite difficult to achieve. Love it!
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Jan 24, 2011 1:16 am
by Chandra
death2all wrote:Fully fledged API - one thing I have to ask, is the API interrupt based, or dynamic library based?
Basically, the programs you saw are the Kernel Space Programs and hence run in ring 0. They come with their own embedded library never requesting for any of the kernel service.
All of my Kernel Space Programs are interrupt based. During execution, they replace the original mouse handler with their own handler and hence for every mouse interrupt generated(including but not limited to mouse clicks, mouse movements), they perform some sorts of test to see if next state can be entered.
When they exit, they simply replace the original handlers.
I think this should make things clear.
Best Regards,
Chandra
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Jan 24, 2011 1:28 am
by Chandra
Well, I missed some of screenshots in my previous post.So I'm continuing...
7. The Bootscreen
8. Wallpaper Support (Latest Addition)
9. And my latest concept of 'Crystal' font (Notice the transparency in the font itself)
Still alot to go...
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Jan 24, 2011 1:57 am
by f2
Wow! I'm really impressed. Very good work.
Waiting for the public release...
Re: What does your OS look like? (Screen Shots..)
Posted: Mon Jan 24, 2011 11:03 am
by hidnplayr
Nice project you have going there.
But please, if you use code from other projects, give the original author some credit..
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Jan 28, 2011 11:20 am
by Graham
I've just passed a significant milestone in my project by getting a user mode process running so now I think I can actually consider my code a proper kernel
Here is a screenshot of it running in QEMU (works in Bochs and on real hardware too):
The code that is running is just some simple assembly code compiled to a flat binary which is loaded into memory - no ELF support or C library yet:
Code: Select all
[bits 32]
[org 0]
start:
mov eax, 0
mov ebx, hello_str
int 0x80
jmp $
hello_str:
db "Hello, World!", 0x0A, 0x00
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jan 29, 2011 10:57 am
by mariuszp
Photon Operating System?!
My operating system is called System Photon. I think we might have a problem
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jan 29, 2011 3:05 pm
by Graham
mariuszp wrote:Photon Operating System?!
My operating system is called System Photon. I think we might have a problem
It's just a temporary name/codename until I can think of something better
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jan 29, 2011 4:01 pm
by mariuszp
And how did you get a flat binary to relocate properly? I mean, it uses memory, so it should be loaded at a SPECIFIC place, right? So how come your program works if you load it anywhere?
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jan 29, 2011 4:10 pm
by Tosi
mariuszp wrote:And how did you get a flat binary to relocate properly? I mean, it uses memory, so it should be loaded at a SPECIFIC place, right? So how come your program works if you load it anywhere?
The "org 0" directive tells the assembler to assume everything starts at 0x00000000. Then when the kernel loads it as a module, it just creates a page directory for the process and adds a PTE mapping 0x00000000 to whatever physical address it was loaded at. To the process, it appears as if it is running at 0x00000000.
As for the kernel itself, it is either identity mapped, which makes things easy, or is a higher-half kernel. From the looks of the screenshot, I would guess it's an identity mapped kernel.
Re: What does your OS look like? (Screen Shots..)
Posted: Sun Jan 30, 2011 1:43 am
by Graham
Tosi wrote:mariuszp wrote:And how did you get a flat binary to relocate properly? I mean, it uses memory, so it should be loaded at a SPECIFIC place, right? So how come your program works if you load it anywhere?
The "org 0" directive tells the assembler to assume everything starts at 0x00000000. Then when the kernel loads it as a module, it just creates a page directory for the process and adds a PTE mapping 0x00000000 to whatever physical address it was loaded at. To the process, it appears as if it is running at 0x00000000.
As for the kernel itself, it is either identity mapped, which makes things easy, or is a higher-half kernel. From the looks of the screenshot, I would guess it's an identity mapped kernel.
The program is indeed loaded in virtual memory at 0x00000000 and mapped to wherever GRUB loads the module in physical memory (which is 0x07F3F000 in the screenshot).
It is in fact a higher half kernel. I know it says setting up paging way after all that other stuff but paging is actually set up in my assembly code before C is ever called - that code is just preparing things which are easier to do in C like setting up the page fault interrupt.