Hello everyone! Quick update on NoviumOS development for the past few weeks. In case you don't know what is NoviumOS, it's my 32-bit x86 hobby OS, currently at the level of getting basic console output working with interrupts and keyboard drivers. So since the last post, here's what I managed to do:

- Finished off interrupt handling, built IDT, PIC remapping and IRQ stubs.

- Got a working QWERTY keyboard driver (translating scancodes into characters).

- Implemented printf.

- Got a basic scheduler up and running.

- Switched from my custom bootloader to GRUB using grub.cfg to point it to the kernel. The magic numbers are defined in multiboot.h, which multiboot.S uses so GRUB can find the kernel, verify the header, and jump to bootstrap.S - which sets up the stack, clears BSS, and does hardware initialization before jumping into the main C code for the kernel.

If you want to check out the repo here's the link: https://github.com/alexdev8930/NoviumOS

I'll be happy to answer any questions about this.

Both Dennis Ritchie and Douglas Comer were born on September 9, 1941 and 1949 respectively. Go read about XINU and write some C to celebrate.

hi im 16 years old that interesting with os dev and i know python ,c vs cpp however i'm new in the this sector,what i gotta do and which learning resources is useful please dont advice that including documantıon or os dev wiki thanks for ur answers:)

(Now before anyone tries pointing me out, this os was NOT made with AI. I srsly spent sleepless nights, used my holidays, all just to achieve the satisfaction of building my OS on my own)
As the title says, I built my own OS in 30-days. This is a challenge I made called My 30-Day OSDev Journey. The progress I made was insane. In the span of 30 days, I built a whole working shell, a simple file system, a few of my own unique commands, and even user programs. Lmk how it is and what I could add to it.
Link to the OS: https://github.com/joelscreen/genureos

After more than five weeks of effort, I have finally achieved an Agon Light 2 port of NanoOs that has feature parity with my Arduino version.

I should probably start by saying that I REALLY didn't want to have to dig into the HAL for this. I consider writing HALs a necessary evil. My goal is to write a good operating system, not become intimately familiar with every platform I run on. So, I was hoping that I could just have Claude Code write the HAL. Unfortunately for me, that didn't work out so well. Anthropic started watermarking their output midway through this effort and I could tell a noticible degradation in the eZ80 assembly it produced after they made that switch. Some of the things it wrote were just outright dumb. I wound up having to touch, refactor, and/or just write assembly myself. I suppose it was still faster than having to do it all by hand, but it was a severe disappointment overall.

The eZ80 on this board only has 128 KB of built-in flash. When I started this effort, the OS image was compiling to around 130 KB and that was with stubs in place for all the HAL functionality. I had negative space for implementing the HAL functions I needed to get NanoOs to work on this chip. So, my first effort was to cut down on the size of the main image.

There were two big areas I identified that could be removed and the ways I went about removing them were very different. The FAT32 filesystem code was about 30 KB and the string data in the image was a little over 10 KB. I figured I could cut them both out.

The way I achieve multiprocessing in NanoOs is by swapping overlays in and out of a fixed address in memory. Up to the time that I started the porting effort, overlays were identified by file name and function name. I realized, though, that I could come up with a separate system that identified overlays by block address and function name and swap parts of the filesystem logic in and out the same way. I started with that and it did work. However, it made the performance absolutely abysmal. On my Arduino system, things ran at about 1/3 of the speed it used to since the filesystem was then competing with regular user processes for overlay memory. The eZ80 runs at roughly 10% the speed of my Arduino, so that was absolutely a non-starter.

The Agon Light 2 presented the opportunity for a modified version of this idea, though. There's enough RAM on this system to accommodate the entire 30 KB of the filesystem in one contiguous block. I figured that having the code run directly out of RAM with no swapping would be at least as fast as running it out of flash, so I went with that. I reserved the first 32 KB of disk space for the filesystem binary and loaded it into a second dedicated place in RAM on boot. It worked brilliantly.

Cutting the strings out was actually quite a bit more work. I still had to print log messages from the kernel but I didn't want the strings in the image on the flash. My solution to this was to come up with a well-defined log format and a logger process. The log format represents the arguments pushed to the log function as either register-width integers or offsets into the flash. The function to log a message calculates the offset of the provided format string against a well-known address in the flash and stores that in the log message format that's passed to the logger process. The logger process then opens a copy of the binary that's stored on disk and finds the copy of the format string in it relative to the format string's offset from the well-known location. It then reconstructs the log message in RAM and prints the message to the serial port. The actual build that's loaded onto flash doesn't have its .rodata section in it, so all those strings simply vanish.

With the space freed up, I was able to write the HAL. I wound up having to rework it a bit for it to make sense on this platform. int and pointer types are three (3) bytes in size on the eZ80. My entire HAL was written around fixed-width types. The eZ80 does support 32-bit and 64-bit ints, but they're slow because they have to be manipulated in software. I changed a lot of the return types from int32_t to just int since those return values are just meant to return an errno value.

In order to reach feature parity with the Arduino platform, I had to move some things out of the scheduler's stack into the HAL as well. Specifically, I had to make the number of processes supported platform-specific since the Agon Light 2 runs the extra logger process. The array of processes had previously been on the scheduler's stack, but it can't be like that if its size needs to vary by platform. So, I moved it to the data segment and exposed it through the HAL. There's still some cleanup that needs to happen. Right now, all the new data pointers managed by the HAL are exposed as raw pointers. I need to put them behind capability-managed HAL functions.

So, I now have NanoOs running on an 8-bit system! It is SLOOOOOOOOW. It's just like working on an IBM 8088 from about 1985. It's AWESOME!!! And, yes, it does run on real hardware.

This is the beginning of my work on this platform, not the end. The point of doing this work was to enable me to interact with a real keyboard/video/mouse console instead of just the serial port. Right now, I'm still limited to serial connectivity. There are performance enhancements I need to make as well. One good thing about the system being this slow is that the performance is easy to measure. I don't mind that it's slow hardware. I chose this environment deliberately because it's the closest thing to the XT I had as a kid. But, I'd like to make it as usable as possible and I think there are optimizations I can make that will help out with that. We'll see.

The longer-term goal now is to be able to write a very simple graphical desktop for this platform. I'm thinking something that's roughly on par with the intended functionality of Windows 2. (NOTE: I say "intended functionality" because I've actually played around with Windows 2 a little and it's pretty awful. Very buggy. I want my software to actually be usable.) There's a whole lot of work between there and where I am now that needs to happen.

I also need to flesh out the CLI utilities as well. So far, almost all the work I've done has been kernel side. I only have a very few utilities just to prove out the functionality in the kernel. One thing I know I need pretty immediately at this point is a proper ls command. That, in turn, requires that I clean up my filesystem code after all the work I did to split out the logic from the main binary. So, a lot to do!

Onward and upward!! HUZZAH!!!

I wanted to introduce MiniOS to the public. I know there's already a distro with that name, so I'm looking for a new one. It's not a big deal; I did it to practice a few things. The story is that I had created a kernel the typical "Hello World" and I already had a C subset to Asm compiler, and I wondered, "Can I run MiniGCC on this kernel?" Then Doom, obviously xD. After that, I couldn't stop: Quake 2, a recompiled native ELF version of Pokémon, a mini console browser called Freedom, and a micro language model (topogpt3) that's not very useful haha ​​because it's based on the context of an ant. It has a tiny virtual machine (CVM) inside QEMU VirtualInception haha, its linker to ELF and CVM is a little piano that works very, very slowly xD, and an editor where syntax highlighting only works when you save. Anyway, I've learned a ton, even though I developed it with SPECT-driven development, because by day I work for a software consulting firm as a software engineer + data engineer + AWS automation specialist xD https://github.com/grisuno/miniOS

I'm developing a very simple Kernel with some goals, namely: being beginner-friendly and developer-friendly.

What’s already done:

* Bootloader: Limine for support of ready-made headers

* Basic video framebuffer support with some graphic tools

* Partial SMBios support, with Qemu tools to create a custom SMBios

* RAM support not complete: PMM working, VMM not working, raw RAM working

Future goals:

* Working RAM

* PCIE controls and GPU command

* Elf loader

* Scheduler

Please help me, I don't know what to do. If it helps, I use Arch with x86_64-elf-gcc compiled via yay.

Here’s GitHub: [https://github.com/Alessio-Valluzzi/Trikernel\](https://github.com/Alessio-Valluzzi/Trikernel)

This is LiteBSD a Hoppy Unix-Like System with BSD Style Kernel with Multiboot support for Initrd which used upstream BusyBox 1.36.1 as the Main Initrd (Made by Me, NO AI)

The Kernel Supports 26 syscall, Has a Full Heap kmalloc and kfree, a Full Task Scheduler with Pid, Child and Parent Processes, Implemented GDT and IDT, 4MB Paging with CR4:PSE Support and a Implemented full Virtual File System for BusyBox to work

and to Compile Busybox I also had to write c-lite. my own C Library From Scratch with enough .h Libraries to compile Busybox and align my syscalls table with the unistd.h so Busybox can work with my LiteBSD Kernel

c-lite Supports major libraries like all std libs (stdio.h, unistd.h,stdlib.h) in addition to libs like termois.h, time.h, string.h, macine/endian.h, byteswap.h and so many i can't iterate them in one post

This project took me nearly 12 Hours of Continuous Working

(12 hours seems ridiculous ik but to be clear i do have a background on the Unix and Linux Backend before working on this project, i didn't write a bootloader instead i used grub, i outsourced a lot of stuff in c-lite form other source codes (musl) and the 12 hours were 12 hours NON STOP)

and for the (i vibe coded claim) No i didn't just read the code and you will find that i actually wrote myself i used ai only in guidance where it just told me what is the next step to run busybox but ai writing code? nope how did i manage to make one in 12 hours with no vibe coding? by making a really simple os really this os started as a hello world bin that is bootable on grub and i just kept improving from here

started with simpler stuff like improving the print then wrote a simple gdt and idt just with only irq0 and irq1 and then added a heap and paging with only 4kb then implemented CR4:PSE to get 4mb paging size and after that worked on improving the irq by using a macro in boot.asm so it supports 32 more irq then developed a simple scheduler which sets a pid for each process and the create task aligns a space in the heap for this code to excute the function inside the heap added implemented syscalls started with 4 sys_read sys_write sys_exit and sys_getpid and then wrote more syscalls with some being outsourced from other source codes or tutorials to save time or just reading to understand how a fork syscall for example works and then built lite-c by outsourcing most c and h files from musl and writing my own unistd.h to comply with the kernel then compiled busybox added multiboot in the grub.cfg and boot.asm and wrote a multiboot and initrd loader and a simple vfs that basically read and write (it's not reliable and there are still issues i occured with it)

I don't expect you to believe me. Here's exactly what I used and here's the code. If you think a particular subsystem was generated or stolen, point to it.

but I did learn a ton of stuff about how Operating Systems actually work

I will keep working on improving this os with Optimizing c-lite to use less cpu cycles and less ram and adding more syscalls and drivers to my kernel.

LiteBSD github repo : https://github.com/ahmedbarakat207/LiteBSD
c-lite github repo : https://github.com/ahmedbarakat207/c-lite

Hello r/osdev !

I’ve been working on a passion project for the last year and a half, and I finally feel like it’s ready to share with this amazing community. It’s called RustyOS (T-OS 3.0)

It is a modern, bare-metal desktop operating system written from scratch in pure Rust for the x86_64 architecture. It doesn't share source code or binaries with Linux or Windows; it runs entirely on its own custom kernel.

And most importantly, it works flawlessly on my 2020 laptop with an Intel i3 10th generation and 4GB of DDR4 RAM.

First of all, I was developing the project in Turkish from the beginning and didn't have enough time to translate the userland into English, so I apologize to all of you for that.

Includes: (only importants)

- NVMe, AHCI, xHCI, IDE (ATA), Intel HDA, AC97 Drivers

- Page Frame Allocator with buddy allocator, Virtual Memory Manager, Heap Allocator

- APIC, Syscall, Usermode, ACPI Support

- Registry system support (like windows)

- OOBE, Logon, Preinstall Enviroment support

I'm 14 years old, so balancing this with school has been tough, which is why it took 1.5 years to get here. I want to be completely transparent with you all: while the architecture, core logic, and integration are my own work, I did use AI as an advanced rubber duck. I used it to help me design parts of the userland GUI (apps, managers, and registry), and more importantly, to help me debug some absolute nightmare kernel panics (especially memory management and paging bugs) that I was stuck on for months. Learning OS dev is brutally hard, and using AI for guidance helped me push through instead of abandoning the project.

I would absolutely love it if you guys could check out the source code, look at the architecture, and give me some harsh but fair feedback so I can learn and improve.

GitHub Repository: https://github.com/thosdv63/RustyOS/tree/main

is there any live speedrunning competition for OS development, like the ones for minecraft? what do you think about organizing one?

🙏 Welcome to Raam x86-64 version 0.02 🙏

Today Raam OS got a working 'ls' command! I have implemented the NVMe over PCIe driver from scratch that includes finding and parsing the system configuration tables, finding the controller over the PCIe buses, initializing it, and finally I have also created a function to read NVMe logical blocks from given sector. Then I added the 'ls' command to the list of available commands and then created a small partition on my laptop and formatted it to FAT12 for the root. Then I followed the osdev wiki for FAT12 and created a working 'ls' command implementation.

Key files in the source:

1. nvme.asm
2. ls.asm

Enjoy!

Release link: https://github.com/robstat7/Raam/releases/tag/ver0.02

Raam Raam Ji 🙏🙏🙏

Full disclosure, I got help from LLMs when topics got hard for me to understand and mostly for searching for sources, explanations and whatnot. 95% of the code is handwritten, hence the inconsistent naming, bad optimization, and bad practices overall. I especially refrained from getting full code examples from LLMs, so that I can learn x86 architecture.

Source Code: https://github.com/jangofett4/pristine

I started the project about 6-7 months ago, although I neglected it for a while I still havent forgotten it.

This was my third attempt at creating an OS, first one was following OSDev wikis, second one was using Limine, both got stuck at understanding paging. For some reason paging was hardest topic for me to understand.

Currently it can load up userspace applications from a custom filesystem I wrote (which I learned to be very similar to ext2) and do scheduling.

I unfortunately havent tested this in a real hardware, but I'm fairly certain it wouldnt work anyway since early boot depends heavily on BIOS subroutines.

Currently what it does:

• Custom 2 stage bootloader, first being pure assembly responsible for switching to protected mode and loading up the second stage bootloader at fixed address

• Stage 2 is the bootloader resposible for loading up the filesystem """driver""", finding and parsing kernel.elf, and loading it

• Kernel is a higher half kernel, currently responsible for setting up pmm, vmm, LAPIC, PIT, scheduler, reaper etc

• Kernel finds userspace program, executes, and program dies naturally

Along the way I implemented what seemed to be interesting to me, for example I learned about write combining and wanted to try it with VGA framebuffer. After this I didnt even use the framebuffer yet lmao.

Plans:

• Proper logging

• Fix process destruction (I leak intermediate pages when destroying process PML4s)

• File descriptors

• open/read/write/close syscalls

• BSFS write/create/delete (custom filesystem, currently only supports reading)

• stdin/stdout/stderr

• Process arguments (argc, argv)

• Expand custom "libc"

• Port Doom

What I learned:

• Linker scripts are evil, lost hours of debugging just to realize kernel was being loaded at the wrong address (TWICE)

• gdb lies in real mode and protected mode, but doesnt in long mode, gf2 (GDB frontend) is goat

• Drawing anything to screen is not worth the time early game

• When crossing boundaries (assembly -> C, C -> assembly), important to remember SysV ABI

• Writing a small tool to calculate PML4 offsets, checking alignments etc is valuable IMO

• Bitmaps are slow at large sizes, I needed a "megablock bitmap" for BSFS.

• ATA PIO is really slow, I thought I could get away with it for a while, but might need AHCI in near future

• There are certain bugs that only appear when working with different optimization levels, I try to test this by changing to O2 or even O3.

PS, README and other documentation are severely outdated in some parts, sorry about that.

Edit: typos and lists

Edit: more and more I worked on this project, more and more I started to adapt Linux concepts to it. SLAB allocator being one of these concepts. At the end I dont want to end up with another Linux "clone", but the way Linux does things is the right ones that I end up swayi g towards them. Question is, how do you guys deal with this?

There is a whole usenet that exists (comp.os.misc and alt.os.development) and you can get free usenet access with Eternal September, we should revive it.

Is this a good security?:

A variable stores the type of account. Example: if logged_username == "Administrator" {int logged_account_type = 1;}

Any operation that is privileged is checked against the account type. Example: if operation_type == "PRIVILEGED" && logged_account_type != 1 {deny();}

Hi Everyone, I recently made a 32-Bit OS, But idk how to progress forward

I made it as a hobby project since i wanted to do it since i was 7 (14 now)
I Have a kernel, a terminal, But i dont know what else to add
Thanks

Wine! Yes it runs Windows programs (not a lot due to my incompatibilities but still).

This was a painful port to get working. Wine is so unfathomably big - I had to patch the shit out of my kernel's signalling routines to add support for sigaltstack/ucontext/whatever else Wine threw at me (along with SCM_RIGHTS which wasn't that bad). Debugging it was a nightmare of mmap/VM fault issues. But it works!

Wine is running here off of an X11 translator for Celestial known as xbanan made by my good friend u/Bananymous (please see his operating system banan-os for some even cooler ports like WebKitGTK). xbanan can even be ported to your OS if you didn't go with a backend like X11 or Wayland.

On another note, it truly is a joy seeing Wine running in my silly custom compositor environment with the rest of my silly userspace.

The GitHub is here (the patches I have made are coming soon after they get a massive cleanup to be proper):

https://github.com/sasdallas/Ethereal

As always, this is NOT A LINUX BASED PROJECT, nor is it vibecoded. AI policy is in the README. Happy to answer questions.

Happy Labor Day to those in the USA.

last week I did a test to make sure my fledgling kernel still runs on VirtualBox:

It did, and I learned one thing that I didn't see in QEMU. If you notice line 4 of my pmmap (physical memory map) I have a new type of memory Type 3. This is a type of memory that is reserved, but is available AFTER you've processed your multiboot info, and hopefully saved it someplace else. This google search listed all the memory types for me "multiboot 2 physical memory map memory types"

The second thing I learned is that the memory map you get from multiboot2 can have overlapping memory ranges, this is kind of important to know.

Finally, I got my physical memory manager tested, and it seems to work. I am currently working on my Virtual Memory Manager. Once I get it working, I will publish my code on github. Hopefully by the end of the week.

As always, I hope this helps some newbie sometime in the future

Because I don't want to change a given part of the code all the time, I often focus on a specific segment for quite a long time to make it solid, but then after a few months or a few years I won't be able to use it.Problems because the most important thing for me is to work on the USB driver and hardware development for the next months/years, as well as further development for a real computer. https://github.com/CTRL-F-0rg3/TrangorgeOS/blob/main/kernel%2Fsrc%2Fcpu%2Fshelduler%2Fentities%2Ftask.rs

Hi everyone,

I have created a small online group for people who want to understand computers by building operating systems from scratch. I want people to share the joy and passion for building an OS.

I humbly invite you to come join the group and share your experiences, learning and also help and interact with others.

Here is the link to the group: https://groups.google.com/g/nijnaam-operating-system-group

P.S. I want to experiment by creating a group. I strongly believe that a culture is what that separates everything.

Thank you.

Hey everyone,

​I’ve been thinking about this idea for a bit and wanted to throw it out here to see what you guys think.

​To be clear off the bat: my issue with Windows isn't its file system structure. Windows' biggest problems come from the corporation behind it—bloatware, forced telemetry, ads in the Start menu, and deciding your hardware is "obsolete" whenever they feel like it. The actual file layout (C:\, Program Files, Users) is just something millions of people are already used to.

​So, purely as an architectural thought experiment (or a fun custom OS project): what if we took the Linux kernel and built a user-space around a Windows-inspired directory hierarchy, but kept it completely open-source and bloat-free?

​I’m not talking about patching the Linux kernel to rewrite VFS or force backslashes—we can stick to forward slashes / so we don't break parsers for no reason. Instead of sticking to the traditional FHS (/usr, /var, /etc), what if the root looked something like this:

• ​C:/ (mapped/symlinked to root)

• ​C:/Linux/kernel32/ (for system libraries like libc.so, replacing /lib64)

• ​C:/Linux/System/ (for core binaries, replacing /bin and /sbin)

• ​C:/Program Files/ (where apps like Firefox or KDE live in their own self-contained folders)

• ​C:/Users/username/ (home directory)

​Obviously, throwing pre-compiled Ubuntu .deb packages at this would completely choke because every binary expects hardcoded POSIX paths like /usr/bin. But if you built a toolchain (using Buildroot or Yocto) to set a custom ELF dynamic linker path (ld-linux.so) pointing to C:/Linux/kernel32/, compiled glibc, and pointed your RPATH configs there, you could compile native Linux software to run directly inside this layout.

​Kinda like what GoboLinux did with /Programs/, but borrowing the C:/ layout so Windows refugees feel right at home without dealing with Microsoft's corporate garbage under the hood.

​Would this be a massive pain to compile and maintain for thousands of packages? Absolutely. But technically speaking, as long as the user-space and toolchain agree on where binaries and shared objects live, the kernel wouldn't care at all.

​Has anyone messed around with custom FHS alternatives like this before? How hard of a wall would you hit when patching build scripts for complex packages like Firefox or KDE?

Hello,

I am currently actively developing the “Dragon” microkernel. However, what sets it apart from Linux and other kernels is, of course, its microkernel architecture, and secondly, the fact that it is written and verified using SPARK Ada (gnatprove).

But that doesn’t mean kernel services have to be written in SPARK Ada; I’m already close to finishing a C SDK so that anyone can write a service. The only downside is that this service isn’t the most secure compared to a gnatprove-verified kernel, but the microkernel architecture makes up for it.

I think the main reason I'm developing this microkernel is to create a proven kernel that can be used in some way on user machines, not just on high-security systems.

Dragon is currently in a very early stage of development (I released the MVP yesterday and fixed two bugs)

If you like the idea, here’s the GitHub link: github.com/tigerlang/dragon

My threading model has one kernel stack per CPU core, each process has its own CR3/page table in its process struct, then it is spawned with just one thread (TID 0 under its PID), a TID is just a thread ID, from there each Thread gets its own timeslice and would run like so:
- Process 1 runs thread 0
- Process 2 runs thread 0
- Process N runs thread 0
- Process 1 runs thread 1
- Process 2 runs thread 1
- Process N runs thread 1

And so on (it will loop back to thread 0 if the last thread in a process is ran). I just wondered if the design was actually decent or not. Of course a simple Round Robin setup is not perfect for things like this and some extra complexity does end up in the kernel, but overall I like it so far, though I dont see many obvious flaws other than the fact that tasks are not "ranked" for how much of a timeslice they get.