Page 111 of 262

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

Posted: Sun Aug 31, 2014 5:21 pm
by Peterbjornx
Image
Image

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

Posted: Mon Sep 01, 2014 2:22 am
by max
Hey Peterbjornx! Really awesome progress, looks great. [-o<

P.S.: it would be imho nice if you added your screenshots as smaller images, maybe with a link to the big image :)

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

Posted: Fri Sep 05, 2014 10:32 am
by Roman
Now my VM supports calling and returning, plain uselessness.
Test code for VM:

Code: Select all

func testB {
	return 0
}

func testA {
	testB:
	return 0
}

func main {
	testA:
	return 0
}
Byte-code:

Code: Select all

0D F0 0D 80  1B 00 00 00  00 00 00 00  E4 00 00 E3  0C 00 00 00  00 00 00 00  E4 00 00 E3  0F 00 00 00  00 00 00 00  E4 00 00
EDIT: the red number in the top right corner is the current opcode.
EDIT2: status code is yellow, when it's not 0.
EDIT3: on the second screenshot you can see a yellow status code. All return codes are 16-bit.

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

Posted: Tue Sep 09, 2014 8:36 pm
by sortie
I spent some time implementing POSIX regular expressions (<regex.h>) in my libc, so I could use them to implement the regexp matching operator (:) in expr(1):

Image

It's not a time-efficient implementation yet, but it'll do. The main reason is that configure scripts do a lot of expr calls with regular expressions. Well, I implemented this and did a few odd adjustments and hacks, and I got configure scripts running on my OS. I managed to build some simple GNU packages like libiconv and grep fully on my OS. I then looked into the bigger packages like binutils and gcc. With a bunch of effort, I actually just managed to compile binutils and gcc on my OS and install them, and then build a hello world program with the new compiler.

Some screenshots that might be too big to link here inline? (1280x1024):

https://cs.au.dk/~sortie/sortix/screens ... sortix.png
https://cs.au.dk/~sortie/sortix/screens ... lzkthx.png

Yep. I'm going self-hosting big-time. :D

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

Posted: Tue Sep 09, 2014 9:10 pm
by klange
I ported SirCmpwn's z80e (TI graphing calculator emulator) and gave it a native inteface, so here's Phoenix running on KnightOS running under z80e on top of ToaruOS (which is itself running in Qemu on Linux):

Image

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

Posted: Tue Sep 09, 2014 9:17 pm
by SirCmpwn
Here's a screenshot of my OS :wink:

Image

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

Posted: Tue Sep 09, 2014 11:47 pm
by TorakTu
....REMOVED FOR AN UP COMING IMPROVED SHOT....

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

Posted: Wed Sep 10, 2014 7:17 am
by Peterbjornx
sortie wrote:I spent some time implementing POSIX regular expressions (<regex.h>) in my libc, so I could use them to implement the regexp matching operator (:) in expr(1):

Image

It's not a time-efficient implementation yet, but it'll do. The main reason is that configure scripts do a lot of expr calls with regular expressions. Well, I implemented this and did a few odd adjustments and hacks, and I got configure scripts running on my OS. I managed to build some simple GNU packages like libiconv and grep fully on my OS. I then looked into the bigger packages like binutils and gcc. With a bunch of effort, I actually just managed to compile binutils and gcc on my OS and install them, and then build a hello world program with the new compiler.

Some screenshots that might be too big to link here inline? (1280x1024):

https://cs.au.dk/~sortie/sortix/screens ... sortix.png
https://cs.au.dk/~sortie/sortix/screens ... lzkthx.png

Yep. I'm going self-hosting big-time. :D
Holy ****, that's amazing!

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

Posted: Thu Sep 11, 2014 6:10 pm
by b.zaar
Here's a few screens of BoxOn using the Simple Multiboot boot loader.

This shows the boot loader with a tiny Multiboot kernel, just uses jmp $
Image

This shows the Multiboot specification example kernel and output. The data overview in the debug window shows the Multiboot info block at 0x8000.
Image

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

Posted: Sat Sep 13, 2014 3:40 pm
by max
thats awesome sortie. :)

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

Posted: Mon Sep 15, 2014 3:19 am
by mallard
I don't have anything that I'd really call a "user interface" yet, but I expect this screen will become somewhat familiar to any future users of my OS...

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

Posted: Mon Sep 15, 2014 5:46 am
by max
mallard wrote:I don't have anything that I'd really call a "user interface" yet, but I expect this screen will become somewhat familiar to any future users of my OS...
Classic BSOD :mrgreen:
Why don't you kill the process and let the rest go on?

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

Posted: Mon Sep 15, 2014 5:50 am
by sortie
Probably NULL pointer dereference!
You don't know for sure?

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

Posted: Mon Sep 15, 2014 6:12 am
by mallard
max wrote: Why don't you kill the process and let the rest go on?
If an error occurs in userspace, I do. The BSOD only happens if kernel code causes the fault.
sortie wrote: You don't know for sure?
Well, the message really just means that a page fault has occurred on page 0, which is left unmapped specifically to catch NULL pointer errors. So, while there's a high probability that it's a NULL dereference, it's not certain. (Although the bug I deliberately triggered to take the screenshot was.)

Also, if anyone's wondering what the "Stored EIP" is, it's the EIP at the time of the last interrupt or context swtich. So, for processor exceptions, it's the location of the faulty code, for other errors it might not be.

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

Posted: Mon Sep 15, 2014 12:50 pm
by sortie
mallard wrote:Well, the message really just means that a page fault has occurred on page 0, which is left unmapped specifically to catch NULL pointer errors. So, while there's a high probability that it's a NULL dereference, it's not certain.
You can be certain it's a null-pointer access if the exception was a page fault and cr2 is set to 0.