What does your OS look like? (Screen Shots..)

Chandra · **Joined:** Sat Jul 17, 2010 12:45 am **Posts:** 487

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

Chandra · **Joined:** Sat Jul 17, 2010 12:45 am **Posts:** 487

Well, I missed some of screenshots in my previous post.So I'm continuing...

7. The Bootscreen

Attachment:

bootscreen.PNG [ 50.7 KiB | Viewed 6096 times ]

8. Wallpaper Support (Latest Addition)

Attachment:

wallpaper.JPG [ 117.35 KiB | Viewed 6096 times ]

9. And my latest concept of 'Crystal' font (Notice the transparency in the font itself)

Attachment:

cystal_font.JPG [ 118.18 KiB | Viewed 6096 times ]

Still alot to go...

f2 · **Posted:** Mon Jan 24, 2011 1:57 am

Wow! I'm really impressed. Very good work.
Waiting for the public release...

hidnplayr · **Joined:** Sat Aug 09, 2008 5:07 pm **Posts:** 23

fatih wrote:

ELERA 0.1.6
http://eleraos.brinkster.net/

Nice project you have going there.
But please, if you use code from other projects, give the original author some credit..

Graham · **Posted:** Fri Jan 28, 2011 11:20 am

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:

[bits 32]
[org 0]
start:
  mov eax, 0
  mov ebx, hello_str
  int 0x80
  jmp $

hello_str:
  db "Hello, World!", 0x0A, 0x00

mariuszp · **Joined:** Sat Oct 16, 2010 3:38 pm **Posts:** 587

Photon Operating System?!

My operating system is called System Photon. I think we might have a problem

Graham · **Posted:** Sat Jan 29, 2011 3:05 pm

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

mariuszp · **Joined:** Sat Oct 16, 2010 3:38 pm **Posts:** 587

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?

Tosi · **Posted:** Sat Jan 29, 2011 4:10 pm

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.

Graham · **Posted:** Sun Jan 30, 2011 1:43 am

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.

mariuszp · **Joined:** Sat Oct 16, 2010 3:38 pm **Posts:** 587

I stopped working on Asmadian (my old, crap OS), and now I'm making System Photon (as I mentioned above), and i'm sort-of close to finishing the kernel, look at this amazing screenshot:

Comment please!

Coty · **Joined:** Thu Feb 12, 2009 5:12 pm **Posts:** 286

mariuszp wrote:

Comment please!

gods thats over whelmingly pink and bright! :shock:

mariuszp · **Joined:** Sat Oct 16, 2010 3:38 pm **Posts:** 587

Coty wrote:

mariuszp wrote:

Comment please!

gods thats over whelmingly pink and bright! :shock:

gods that's only the bootup screen, in the finished OS you'll see this for less than a second!!! :shock:

P.S. you magenta, not pink

andymc · **Posted:** Tue Feb 01, 2011 6:38 pm

Visopsys

Attachment:

index-screenshot.jpg [ 82.02 KiB | Viewed 7813 times ]

f2 · **Posted:** Wed Feb 02, 2011 12:30 am

Hi Andy, and welcome to the OSDev forums.

Your OS is very good and I know it since a while (The first version I tested is 0.2_PRE

).
Anyway, I'm very impatient to test the next version 0.7. Hope it will be available in a few
days

...

f2

OSDev.org

What does your OS look like? (Screen Shots..)

Who is online