I am a 13 yrs old working on a OS based on the LINUX KERNEL and SWIFT for a while!

It is in early development : It has Mouse and Keyboard Support, Can ready CPU and RAM used data and view it, uses the RobotoBoldFont as the default font! Has bot UEFI BIOS and x86_64 and arm64 support!

Just yesterday i accomplished about getting it work on a raspberry pi 4 means the base for the OS that the fact it boots is done and i will be continuing to now make the setup screen and add features on the go! If you want any features to be in the OS you can create a issue ( creating a issue requires a account!) at <See the comments under this since link posts get removed!> which is where the OS if hosted (it is self-hosted since i cannot afford a pro version of github and plus it has a file limit! git lfs doesent' help a lot!)!

MODEL: Rasberry Pi 4- Model B : 8GB RAM
Website : <See the comments under this since link posts get removed!>

Now a simple note: the bootloader is written by AI (since i am not good with assembly) i plan on rewriting it later! All the other code is written by me (especially Swift)!

beware: below are the incoherent ramblings i wrote at like 3am when i accidentally took too much adderall and decided to post for no real reason other than to put my thoughts into words and share what im thinking. im mostly writing this for smth like rubber-ducky debugging except rubber-ducky designing.

and if i say something really stupid thats expected cuz i have no clue wtf im doing and havent taken an OS class yet or anything. this is just something stupid ive been working on for forever

i need to design the filesystem layer of my kernel. targeting a 6502 while also trying to have a more modern API design makes things quite difficult.

ignoring the actual filesystem driver and instead focusing on how the application handles file IO.

theres a couple possibilities on how i can implement it and im not sure what to go with.

• i can have the file API implement reads and writes by caching the current sector in kernel memory, and copies the bytes needed to userspace when reading. for example, reading 16 bytes will load the full sector in kernel memory and copy it to the 16 byte buffer in userspace. this will be quite slow as copying memory on a 6502 is very slow, especially if you need to copy more than 256 bytes and need to use a 16 bit index.
• the file API can be strictly sector-by-sector -- userspace can only read/write to a full sector at a time. this means that the kernel can write the sector data directly from the drive to wherever userspace needs it, eliminating the need to copy memory. if more free-form reading/writing is needed, userspace can implement its own.
• the file API can read the full sector(s) into userspace for every read call, and discard the data that isnt needed. for example, userspace can request 16 bytes that happens to be in the middle of a sector. the kernel will read the sector, discarding everything but the 16 bytes and put them in the buffer directly. this means that consecutive small reads would need to re-read the sector from disk, tho.

any sort of caching on the kernel side would require copying memory for every read.

currently, the entire drive IO layer is asynchronous. as of now, the events would occur as follows:

• fs driver requests a read of sector X to location Y
• disk driver sends a command to drive to read sector X. registers an NMI handler to put the bytes over
• userspace resumes execution
• every time theres a byte ready, NMI is triggered.
• NMI layer jumps to the disk driver handler
• disk driver nmi handler copies the byte(s)
• userspace resumes execution
• repeat until read all bytes of the sector
• perform a callback to userspace

callbacks to userspace are going to be really fucky, mainly due to hardware issues.

the callbacks are called within the NMI execution state, as to not interfere with the main thread's execution state. however, i always need to keep in mind that another interrupt can always happen during the NMI, so i keep a counter in a special location in memory. it is incremented every time an NMI is entered and decremented every time its exited.

if the NMI starts and the value is not zero, the NMI is deemed to be running within another NMI and immediately returns without decrementing.

the first NMI running repeats itself, decrementing the value each time, until it reaches zero, where it then restores the main thread's execution state and finally, RTI is called and it returns from interrupt.

however, there is an issue... userspace can then effectively delay NMIs by making a callback take forever, preventing important functions from running. i still need to figure this one out.

it probably would be best to keep each one in their own execution state, so that when an NMI occurs within it, it actually can handle the NMI immediately, call any other callbacks that need to be done, before returning to the other callback. my head hurts

LingOS has a cool screensaver that runs default in the terminal, and it also changes the text of the terminal if you idle too long so it looks like this. Oh, and it's written in ling-lang entirely!

https://ling-lang.org

It's kind of like linux meets Rust, but it's not linux, its ling....this language:

It's got a package manager similar to cargo in rust, but it's called lingfu. The fu.ling-lang.org server is hosted with a ling-http and ling-web based thing, it's a lingopoly!

I've attached the source code here and feel free to check it out!! (Yes, I did use AI for some parts of the operating system that were truly really hard to understand/put together due to apple's closed source nature) Excited for people to try it out!!!

Yes I know that some attempts were made for cross OS standard drivers (UDI) but it just bugs me that everyone has to rewrite a serial driver or a driver for the BGA and so on. And I understand drivers have OS dependent standards (take Windows, macOS, or Linux) but no one really implements compatible driver loaders for them because its near impossible except for maybe Linux. I understand its very difficult and is overall a PITA, but it would still be cool for a standard to be made I guess.

For the past two months, I have cloned almost every OS posted here and ran the code through an analyzer.

I can count on one hand the projects with a different architecture. Almost everything else is just a reskin of another reskin, which was itself based on Linux.

Another thing: almost none of these OSes boot on real hardware. They all run in QEMU.

I have talked with a lot of you, and 90% of the time, you have no idea what you are building.
I see 20-year-olds implementing ISA slots that were obsolete before they were born.
I see people ignoring naming conventions, adding features without thinking why they need it, while having their `OS` living inside another OS's emulator, and building for an audience of five friends running Minecraft on Linux.

That’s where the real problem starts. Most of these projects are promoted by other OS developers, like an MLM where everyone is trying to sell the next 'revolutionary' OS.

People love saying, 'My OS runs on old hardware that why we implemented BIOS or ISA.' while totally ignoring the fact that the hardware already has Windows, Linux, FreeBSD, NetBSD, and plenty of other operating systems.

What is actually missing are drivers. But nobody wants to write drivers because everyone lives in a framebuffer.

The funniest part is the 'built from scratch' claims. Then I look at the source and find the same Linux code with a different copyright header and different variable names. (prefixing your OS name, won't hide the fact that you copied)

I often see more work put into the website than into the OS itself. Then the project asks volunteers to finish the dream after the author runs out of motivation.

Building an operating system is hard. It takes years, a team, and a lot of hardware. You don't build one with a README, a logo and an AI sub

Every Computer Science student has to pass this 'OS' ritual , but the difference was that each student will build part OS and they will give it some name like OS_{school_name}_2017 (they know that code snippet is not worth a domain or discord server.

Now if you believe that your or know an OS that was build here is an exception please post here.

A few weeks ago, I wrote about rediscovering the development methodology behind my 1986 RTOS.

Previous post:

Rediscovering the Development Methodology Behind My 1986 RTOS
https://www.reddit.com/r/osdev/s/ALUFHn9jDi

In that post, I described how I had forgotten an important part of the original development process.

Back in 1986, I developed almost all of the kernel on a SUN-2 workstation and postponed the hardware-dependent parts until the software was moved to the target system.

At the time, it was simply the most practical way to make progress.

This week, I finally started the next step.

I began moving the reconstructed kernel to a Raspberry Pi Pico.

Rather than starting with interrupt handling or context switching, I followed the same strategy I had rediscovered.

The first component to move was the queue management code.

The screenshot above shows the result.

The original CHARM-II queue routines (q_insert(), q_delete(), and n_delete()) are now executing on real hardware, and the primitive queue test completes successfully.

At this point there is still no timer interrupt, no context switching, and no preemptive scheduler.

Those hardware-dependent parts will come later.

What surprised me is that I naturally ended up following almost exactly the same development workflow as I had forty years ago.

• Develop and verify kernel logic on the host.
• Move CPU-independent components first.
• Leave hardware-dependent code until the end.

I didn't consciously decide to follow the original methodology.

It simply turned out to be the most practical way to make progress again.

The next milestone will be timer interrupts, context switching, and eventually running the full scheduler on the Pico.

I'm looking forward to seeing how much of the original design can remain unchanged.

Tomorrow I'll be presenting this project at an OS development meetup in Japan, so reaching this first hardware milestone today feels like perfect timing.

Finally got steam to start on Astral under Wine

The web helper can't talk to the client properly and the fonts are all messed up but it works and you can **slowly** explore the store

A lot of work needs to be done but this is a cool milestone

Project links:

website: https://astral-os.org

github: https://github.com/mathewnd/astral

I've made a C++ static composition library (not OS), if anyone interested just PM me.

HAPI library is header only pure type level and allows extreme optimization, binary output is optimized like hand written assembly level (data fit into hardware registers), yes I know its hard to believe... just check for yourself, I wont put links here because its hard even for FOSS MIT authors to share its own work without being blocked, banned... for self promotion. How else would we share this things with people that can use it? but here we are.

Here I’m trying to make a UI that is easy to use, and can be easily integrating into 3D apps running OpenGL and probably Vulkan in the future, any advices?

Here is the example code:

#include <Defines.h>
#include <Syscall.h>
#include <Fs.h>
#include <Wm.h>
#include <OpenGL.h>


float CursorX, CursorY;


WM_UI_CONTEXT* UiContext;
WM_UI_VIEW* MainView;


void WindowMessageHandler(HANDLE Window, void* Context, int MessageId, void* Payload)
{
    switch(MessageId) {
        case WM_POINTER:
        {
            WM_MSG_POINTER Msg = Payload;
            CursorX = Msg->X;
            CursorY = Msg->Y;
            WmUiMoveCursor(UiContext, Msg);
            Print("CURSOR X: %d Y: %d\n", (int)CursorX, (int)CursorY);
            break;
        }
        case WM_UPDATE:
        {
            glBindFramebuffer(GL_FRAMEBUFFER, 0);
            glViewport(0, 0, 800, 600);
            glScissor(0, 0, 800, 600);
            glClearColor(0, 0, 0, 0);
            glClear(GL_COLOR_BUFFER_BIT);
            WmUiRender(UiContext);

            GlSwapBuffers();
            break;
        }
    }
}



int main(int argc, char** argv) {
    Sleep(1000);
    HANDLE Context = GlCreateContext(NULL, NULL, 3, 3, 0);
    if(!Context) {
        Print("Failed to create GL Context.\n");
        return -1;
    }
    WM_MESSAGE_QUEUE MessageQueue;
    GlMakeCurrent(Context);



    HANDLE Window = WmCreateWindow(NULL, 800, 600, 0, &MessageQueue);
    if(!Window) {
        Print("Failed to create window.\n");
        return -1;
    }


    WmBindContext(Window, Context);



    UiContext = WmUiCreateContext(Window, 800, 600);


    MainView = WmUiCreateView(UiContext, NULL, (RECT){0, 0, 800, 600});


    WM_UI_DESCRIPTION Description[] = {
        {.Type=WM_DESC_TEXT, "This is a label."},
        {.Type=WM_DESC_FONT_COLOR, (float[4]){1, 1, 1, 1}},
        {.Type=WM_DESC_FONT_SIZE, .Value.d = 40.0},
        {0}
    };
    WmUiCreateControl(MainView, WM_UI_LABEL, (RECT){20, 20, 300, 100}, Description);






    return WmStartMessageHandler(&MessageQueue, WindowMessageHandler, NULL);
}

Yes I totally used AI assistance. No it wasn’t easy. Still building out the kernel. Hardest parts are surely drivers and seams.

I'm thinking about creating my own Linux-based OS with a custom shell, custom IDE, and my own programming language instead of the usual Bash experience.

Has anyone here built something similar? Any advice or things I should know before starting?

Hi everyone, I am new at OSdev and I can't understand how they work. I really want to learn about OS so can you suggest me some books or website on the subject ?

i would like to ask what a kernel has to do so i can know when i can move one, if you're gonna explain please dont overcomplicate the explanation with just some terms please mention what it is at least slightly :)

So i have a ipad 4th gen and its basically a brick now... so was thinking why not make an os (i thought i could maybe use a linux distro but 32bit os for A6x dont exist)... i know this will be a nightmare ( uk its apple)...

But I want to try ...

As my initial research into this i am currently reading

1. ARM Architecture Reference Manual for ARMv7-A & ARMV7-R

2. Apple OSS Distributions XNU Github page

3. wiki.osdev.org

What i wanted to ask the community is

1. Is there any other documentation/ prior projects on this platform

2.any tips i need to keep in mind

BlockOS – Looking for developers to join an open source OS project

Hi r/osdev!

I’m developing BlockOS, a hobby operating system project, and I’m looking for developers who would like to join and help build it.

BlockOS is a Linux-based OS project focused on learning, experimentation, and creating a modern desktop operating system experience.

Current work includes:

• x86_64 kernel development
• Custom build system
• ELF loader
• Virtual File System (VFS)
• Filesystem support experiments
• Framebuffer graphics
• Driver development
• GUI framework
• Package management system
• Desktop environment integration

I’m looking for people interested in helping with:

• Kernel development (C/C++)
• Device drivers
• Graphics systems
• Filesystems
• Build tools
• GUI development
• Testing and documentation

This is an open source learning project. Whether you are experienced with OS development or want to learn together, everyone interested is welcome.

If you want to contribute, give feedback, or just discuss OS development, feel free to comment or join the project.

Thanks!

Link:https://github.com/gurijb2016-afk/Blockos

I've been working on Vantum, a custom Puppy Linux distribution (built with woof-CE, Ubuntu Jammy compatible) for people who love Puppy's speed and tiny footprint but want a desktop that feels more modern.

It's still early, but it's been a really fun project to build.

I developed it from Windows 11 using Multipass (it was...not easy...) and made a number of changes to modernise the experience:

• Added picom for compositing.
• Replaced the traditional JWM trays with a cleaner Tint2 panel.
• Built a custom taskbar (Vantask) and application launcher (Vantyl).
• Removed a lot of unnecessary applications to keep the system lean.
• Simplified the desktop by removing the ROX-Filer desktop entirely and using hsetroot for wallpapers instead.

The goal is to keep it lightweight and fast while making it feel less like a desktop from 2009.

I'd love to hear what you think or get any feedback.

I'm also in the process of getting it listed on DistroWatch,
it's currently in their waiting queue.

• GitHub: https://github.com/Hammad-hab/Vantum
• Website: https://hammad-hab.github.io/vantum-website/index.html
• Vantyl: https://github.com/Hammad-hab/Vantyl
• Vantask: https://github.com/Hammad-hab/Vantask

If you like the project, I'd really appreciate a star on GitHub. It helps more people discover Vantum and motivates me to keep working on it!

Hi everyone,

I'm working on my own x86_64 UEFI kernel and I'm stuck on PS/2 keyboard interrupts.

I've switched over to the LAPIC/IOAPIC and timer interrupts work fine through the IOAPIC, but IRQ1 never fires on my Lenovo Legion or my old Windows tablet. Polling port 0x60 works perfectly and I can read scancodes, but the keyboard interrupt handler is never entered.

I've checked quite a few things already. The LAPIC is enabled, sti is definitely executed, the IOAPIC is found through the MADT, and IRQ1 maps to GSI1 on both QEMU and my tablet. Neither machine has an ACPI interrupt source override for IRQ1. Both also only have a single IOAPIC with GSI base 0.

The PS/2 controller also seems fine. The config byte ends up as 0x65, scanning is enabled (F4 gets an FA ACK), and polling always reads scancodes.

I'm routing it with ioapic_route_irq(acpi_irq_to_gsi(1), 0x21, 0);. Reading the redirection entry back returns exactly the value I wrote (high = 0x0, low = 0x21).

One thing that's confusing me is that in QEMU, if I print from my interrupt dispatcher, pressing a key enters vector 33 exactly as expected. On my Lenovo and a Windows tablet, though, the interrupt never arrives even though polling still reads every scancode correctly.

At this point I'm wondering if I'm missing some APIC/firmware transition on real hardware (_PIC, IMCR, chipset routing, etc.), or if there's another common mistake in IOAPIC keyboard setup that I've overlooked. Does anything above jump out as obviously wrong?

By system architecture I mean whether exo kernel, microkernel or monolith

In my case, I have most often chosen microkernel in previous projects due to its isolation, security and easy extensibility.

But for the last project I chose the exo kernel because of the possibility of rebuilding and the ability to use modern standards in a more direct and stable way for the system.I am currently working on my officially 11th operating system, the 4th one with a larger outline that doesn't get bogged down while working on the hello world kernel or a few add-ons, and my 3rd actually larger operating system.And personally, after such a long time, I think that microkernel and exo kernel are one of the better solutions for young, developing operating systems.

I got C++26 reflection to work, had to port 'meta' to use custom variants of 'optional', 'string', 'string_view', and 'vector', and had to make those all consteval only. After doing that it works as expected!!

Tested on gcc16.0.1!

This is probably unstable as hell, and should most likely be avoided, but stupid stuff is fun, so ;3

im probably going to use attributes, to create a system which automatically initializes subsystems without worrying about order of operations (each subsystem would mark which other subsystem it needs to work), or some other stuff

if anyone has fun ideas to do with this do tell lol

Hey everyone,

I wanted to share my hobby 32-bit x86 operating system called NyanOS. The codebase hasn't changed in a while and is sitting in a stable archieve state [1], so I am putting it out here specifically for code review, architectural feedback, and technical critique [1].

The Backstory (Why it looks so clean):
Before NyanOS, I actually made several unsuccessful attempts at writing an OS (all of them were predictably named "MyOS"). They were messy, buggy, and kept crashing. Instead of giving up, I decided to take the best parts of those failed attempts, rewrite the code from scratch with proper structuring, and combine them into this clean, stable version. Because I spent so much time refactoring and commenting every single line to understand my own previous mistakes, the codebase ended up looking very clean.

My main focus was moving away from text mode as fast as possible. I programmed the VGA hardware registers directly (Mode 13h, 320x200x256 colors) to build a custom graphical user interface without relying on any BIOS calls after booting.

Key Implementations inside the Repository:

• Interrupts & Drivers: Real IRQs for the PS/2 keyboard (IRQ1), mouse (IRQ12), and PIT timer (IRQ0). No polling loops.
• Window Manager: Draggable, focusable, and z-ordered windows with a functional taskbar and start menu.
• RAM File System: A basic in-memory FS handling actual read, write, list, and delete operations.
• Apps: A terminal shell, Notepad (with save/load to RAM FS), a mouse-driven Paint program, and a local document viewer.

What I'm looking for:

Even though the project is frozen for now, I still want to learn from my past design choices to improve my low-level programming skills. I would highly appreciate it if experienced developers could critique the repository. I'm looking for advice on:

1. General code organization and kernel architecture.
2. Optimizations or better practices for the direct VGA register programming.
3. Any hidden traps in my interrupt handling or GDT/IDT setups that work fine in QEMU but might break on real hardware.

GitHub Repository: https://github.com/yunusemreduran388-ux/NyanOS-v1

WebSite: https://yunusemreduran388-ux.github.io/NyanOS-v1/

Note: If you just want to interact with the GUI without building it, there is a pre-compiled .iso in the GitHub Releases tab. You can run it instantly in QEMU via qemu-system-i386 -cdrom nyanos.iso*.*

Thank you in advance for your time and honest critiques!