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

[Peterbjornx]

[max]

Hey Peterbjornx! Really awesome progress, looks great.

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

[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.

[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):



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.

[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):

[SirCmpwn]

Here's a screenshot of my OS

[TorakTu]

....REMOVED FOR AN UP COMING IMPROVED SHOT....

[Peterbjornx]

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):



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.

Holy ****, that's amazing!

[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 $


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

[max]

thats awesome sortie.

[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...

[max]

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
Why don't you kill the process and let the rest go on?

[sortie]

Probably NULL pointer dereference!

You don't know for sure?

[mallard]

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.

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.

[sortie]

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.