OSDev.org

Here is mine:
Splash Screen: OS:

This isnt look like this is good os, but I had clean my "monitor" earlier, so it doesnt seem very impressive, but I hope you like this picture from my os:


But anyway im make some like "shell" to there.
But one question, when i had made some program on there, (yes there is filesystem), how i can exec that program from that filesystem in user mode. And I dont know that becoas i had followed "JamesM's kernel development tutorials", so i dont know how i can do that So can you gurus send me some help with PW, im wery pleased if u foks make that, some tutorial, for example.
(And if u take confiused that "kuvakaappaus"-part in the url, here is the answer why that is "kuvakaappaus", im from finland so my language is Finnish)

Here is mine:
And there is also a demo video:

http://www.oshack.net/desktop_record.avi

OrzOs is a 64 bit OS. It's quite simple and crude, but still has some features:

Kernel part:
Paging, timer, RTC, readonly Ext2 fs, PS/2 keyboard, mouse, IDE driver, sync/async device IO, sync/async IPC support.
With a "x86emu" x86 emulator to call vbe functions in long mode.

User space part:
I've ported newlib, libpng, freetype, cairo to it.
It also has GUI framework called "OzUI", in userspace C/S style, which supports window create/move/close, dispatch input events and has label, button, textedit, imagebox widget.
It has basic unicode support and simple handcrafted CJK text layout function(since i don't want to port pango). Thanks to freetype and cairo, it can load ttf font, display Chinese characters, draw png image, complex shapes and even alpha blending.

Source code:
https://github.com/WangHoi/OrzOs
To test it, you need a KVM DISABLED qemu or bochs: BE WARNED it's hard to compile -.=b
There is many hard-coded paths in Makefile and other build scripts. And you need to build a cross compiled gcc first, and use it to port serveral libraries(newlib, libpng etc..) before you can compile the user space part of source code.

Got my boot splash working



It currently finishes so quickly that it's impossible to get a screenshot of it partway through, but once the kernel has more than 5 things to do at boot time it will take a little longer and have a more interesting effect. The cpuinfo_init function is commented for now because it doesn't work properly yet (it's just CPUID stuff).

Source code (FreeBSD licensed) if anyone wants it:
splash.h
http://pastebin.com/5wAmRj9t
splash.c
http://pastebin.com/zib61snz
boot_arch.c (excerpt)
http://pastebin.com/h6iyVC6L

Just rewritten GDT initialization code and look like it's working, yay!

big version here: http://i41.tinypic.com/n18d5h.jpg

GAT wrote:Here is mine:

Dreckig OS sounds familar

Well,after a heap of issues looking for a heap issue, I finally have a bare-bones task switching kernel that does not crash after 3 minutes. This screen has been running for about 20 min, the longest successful exercise to date.

edos (event-driven os) is a pretty lame project name, and until a time is fashionably late, i won't reconvene the minds to arrive at a new name.



just starting out, so here we have a screen (the lower right corner) with a greeting message, and a new-line without line-feed. i'm working on a terminal "driver" of sorts, where the origin point is the lower left (like we were taught in elementary school.. maybe middle school -- it's a bit fuzzy these days (i'm one semester away from graduating uni.. finally!), so bear with me).

goal would be to have a similar setup with the graphical interface, where the lower left is the origin as well; my plan is .. well, to have a test-bed for next semester (my only comp-sci class left is.. os fundamentals! -- yay, but no prize save a big sheet of paper..).

environment (seriously plain jane here..):
- lubuntu (host system)
- nasm (currently assembly only.. haven't decided if i want to add other languages, but if so, C is on the list.. maybe..)
- virtual box (emulator/vm for testing (see Description in the lower-right window in the above screenshot).

yes, i know, the specifications of the vm are .. weird at best, and i really won't explain them... because eh, does it really matter at the moment? (don't say "yes").

[PS: it's been a while since I've been here, but that means I remembered.. what I was suppose to remember... eh, just ... um...]

Here is a new (partial) screen shot of the performance analyser. It shows core 0 load at the top and core 1 load at the bottom. The two load-spikes at the end are when the screen is dumped to a file. The 20-30% load on core 1 is because of some animations that are run.

@rdos: Cool

The above analysis is from a 2-core AMD portable (Compaq Pressario CQ57). The bad thing is that it has an 1.3GHz CPU, and the animations load the processor 3 times as much as on an 500MHz Geode. When they run in the background (against ordinary RAM), the load is half as high on the portable, but still considerably higher than on the Geode. AFAIK, the portable is running at full speed, so that shouldn't be an issue.

Here are the same curves (different animation), but with 250ms sampling time:



Edit: These curves also show that threads that are generally cooperative (like the animation thread) become "bound" to a particular core, while threads that use massive amounts of CPU-time (like the JPEG coder), will get preempted and placed in the global scheduler queue, where any free core will grab them from, and thus they will move between cores.

Finally had it in me to post something here.

Testing stability of task switching over the course of a day:


256-color graphical terminal:


Stack overflow in a user program:


Julia fractal generator:


Freetype:


If there are two cursors in a shot, one of them is mine.

Very nice, indeed, klange. Is your system open source, and if yes, would you mind to post a link that we can take a look?

Makes me more interested in using parts of FreeType in my OS. This is something I really need to do in the near future, as it is more and more problematic to use GFT-fonts.