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

[ComputerFido]

This is my OS so far, I have a basic file manager which can't really do much except execute programs and I have written a CHIP-8 emulator (mostly working except the input is broken) as well as a snake game.

[deleted8917]

Finally added support to FAT32 filesystem. Currently I can only read files with short name,longer that a sector but less than a cluster. Having some problems,for example says that the file doesn't exists but actually it does. :/ But that can be fixed.

[Planetary]

This OS is called 'Planetary'.
GUI mode currently just boots you in to a 1024x768 24 bit color blank screen. Mouse support and double buffering is being worked on.
All commands work as described, but GUI mode is very incomplete.

[nuclear]

Here's a special-purpose system I'm hacking currently. It's purpose is to allow booting off a USB stick and watching 256byte intros (which are demoscene productions written for DOS), on modern(-ish) computers without the need to go through the hassle of installing DOS anywhere, and without having to rely on emulators. I started with the text-based UI (pictured), and I'll also make a VGA low-res and a VESA high-res GUI mode for it later.



Repo: https://github.com/MindlapseDemos/256boss

[thumble]

It's basic, but it's protected mode!!!

Finally picked up bootloader project after nearly 2 whole years. It feels good to be back on the metal.

[SpyderTL]

Not sure if I posted this already, but I've been working on some UI stuff! Yeah the BMP file is inverted, I don't really know why

It turns out that most BMP files are actually stored with the bottom row, left-most pixel first. At some point, this changed, and you now have to check the BMP file header to determine whether the image is flipped vertically or not. If the height field is positive, then the pixels are flipped, and stored bottom row first. If the height field is negative, then the top row is stored first. So, no, you are not crazy. The BMP file specifications are crazy.

[qookie]

Recently, I've been contributing to some small things to Managarm. One of which include a VMWare SVGA driver. Over the past few days I, with the help of Korona, ported kmscon to Managarm.

[Octacone]

January: "Hmm, I should really work on my OS, it shouldn't take a while", so I did
February, March: constantly working on it, hardware bugs crippling my progress (thanks to Ben for helping me out!)
Mid April: "There is no hope for this to work...", lost all my motivation + real life events
July: Here I'm
Does this ever happen to you?

Anyways,
Added a proper PATA/PATAPI driver (even works on broken hardware with bugged firmware)
Added support for MBR and GUID partitions (+ CD type partition)
Laid the foundations for my VFS framework, Windows like (uses C:, D:, A:, B: for devices)
Why did it take me 6 months to complete all that?

[eekee]

@ Octacone: For one thing, taking time off a project is healthy. For another, getting buggy hardware to work takes a lot more creativity than it should; you have to think your way around the problems. Ever heard of artist's block?

[Lionel]

It's been a long while since I've posted on these forums. I started getting interested in kernels when I was 11 and while it's taken a lot of trial, error, and understanding, I think I'm ready to actually make a functioning kernel and OS again. Mostly because I'm 20.
Here's my OS running in 1024x768 using the BGA: It's not doing anything complex but I do have the GDT, IDT, and am parsing the memory map. The log and the screen are decoupled; there's a boot log renderer that actually renders the logs and is able to scroll around.
Now onto the PIT and the Physical Memory Manager. I'll keep y'all posted.

[zity]

Last year I started working on an AML interpreter and worked on this for about a month before leaving it for other projects. Recently I restarted my effort and over the last weeks I have made significant progress.

The screenshot does not really do the effort justice, but I am successfully parsing the DSDT on my workstation, evaluating the _STA/_INI methods, the _PIC method, and finally calling the _PRT method for all PCI root buses to get the interrupt routing information (on the screenshot I only print the first 10 entries).

I am really happy about the progress so far! However, I will need time to clean and improve the code before it is truly useable.

[qookie]

Since the last time I posted a screenshot of quack, quite a lot has changed. First of all, I implemented x86_64 support (which now is the main architecture). I also implemented ACPI support with the help of LAI (which I also contributed some code to). The x86_64 port is still missing a lot of things the previous i386-only version had, like userspace processes etc. The port also has many improvements, like SMP, previously mentioned ACPI support, or the use of the LAPIC and IOAPIC instead of the old PIC.

Recently I implemented PCI IRQ routing with the help of LAI, as can be seen by this photo(click for full size):


Here's quack running on both of my x86_64 computers(click for full size):


quack of course still works in emulators/virtual machines. It successfully boots in: QEMU, Bochs (with some odd bugs), VirtualBox, VMWare.
quack running in QEMU, showing SMP, PCI enumeration, and PCI IRQ routing

[Thunderbirds747]

Working on 64 bit version and (@klange) usermode window manager.

Looks quite impressive.

[eekee]

All the posts in this thread make me smile. Now I understand the work that went into each one, I recognize the feeling of accomplishment.

[pvc]

@TimothyWilliams I'm glad you like it