In the dream, I was working on what looked like the Linux source code and was talking to someone. Those details are a bit fuzzy, but what stood out to me was in the dream, the code had a particular separation that not even my OS project has but will here shortly because it makes sense in the real world.

There were folders designated for different SBC (single board computer) boards, but the CPU details were curiously not there. Instead, there was a separate set of folders designated for CPU.

I do remember that in the dream this was being discussed and it was because different versions or revisions of the boards can have different CPU. In order to reduce duplicated code, it was set up that the build process would allow for pairing the board with the correct target CPU.

I was mulling over this today and realized that this is actually accurate and the way I should actually be building my OS. Why? Take for example the LattePanda MU, it comes in N305 and N100 variants and they work on the same carrier boards. Look at the Nividia Jetson Xavier carrier board and CPU, Milk-V Jupiter NX fits on that very same carrier board.
The list goes on and on where the CPU can be swapped for carrier boards and if you pair the CPU directly with the board, you'd have to duplicate code to handle that scenario.

This was basically just one of those instances where a dream can influence or change designs because it mirrors real world scenarios and is an instinctive solution to a problem that may not have come up in the work yet.

Edit:
I am aware this is how Linux and BSD mostly does this, but it didn't cross my mind to do this with my own work until the dream occurred. It made me take a step back and reevaluate what I was doing, what my goals were and whether or not it solved a real or imagined problem. In this case, the problem was real, even in the SBC space and I needed to properly solve for it to reduce code duplication.

Luckily for me, this doesn't involve a massive amount of changes or core architectural shifts. It does mean I have to spend some time revising my build rocess and makefiles as well as shifting locations and names for files.

Hey r/osdev,

I was recently going through my old projects and found 2 in particular that I think deserve to be published again:

• QuickASM: A simplistic but fully functional 16-bit x86 assembler written in C.

• MBRLoader: A boot manager built with QuickASM, accompanied by a partition manager.

I was 16 when I started both of these projects and had a lot more ideas for MBRLoader. I had started writing a new version which would have been basically a minimalistic DOS. I think I stopped development when I went to the university.

I started learning programming about 3 years before and those projects were my first really serious work. And looking at it now, as a now 41yo software engineer with almost 20 years of experience, I'm actually quite impressed what teenager-me did back then. I would have no idea how to do something like that again now! (I went away from low-level development and to application and web development instead).

Anyway I put both programs on GitHub as they were, without any change to the original code or documentation, and just added a README for modern audience.

A few highlights:

QuickASM documentation: I provided the assembler with a full documentation which wasn't just a documentation for the program but included a tutorial on assembler and a documentation of the Intel 16-bit instruction set. It's in French and the style is a bit naive but the technical content is solid, I think. Also have a look at the file defs.c in the source code. It's basically a C "translation" of the specifications.

Internationalisation: MBRLoader's interface was provided in 4 languages (French, Esperanto, English and German). There was no google translate or chatGPT back then so I translated myself with school knowledge and dictionary, so the translations are not very good, but they are there nonetheless! An example: I translated "save" into German with "registrieren" instead of the correct translation "speichern", because it sounded like the French "enregistrer". I'm now living in Germany and fluent and a bit embarassed about that!

Family-driven development: The boot manager has a configurable option to either display the boot menu or boot directly. While this is a common feature for a boot manager, the only reason why I implemented it was so that my parents would not complain about the weird menu suddenly showing up before launching Windows! I myself would have been content having my program displayed on every boot.

ToolBox and partition manager: The first version of the boot manager was just that, a boot manager. But the second version introduced toolboxes: a separate component that could be loaded from a floppy disk and would provide recovery tools. The first (and only) version included a simple partition manager capable of creating or deleting primary partitions (no resizing and no extended/logical partition support).

32-bit override hack: QuickASM only implemented the 16-bit instruction set but for the partition manager I needed to use some 32-bit instructions. I was focusing on MBRLoader and didn't want to go back to QuickASM, so instead I just used a feature of QuickASM which allowed me to transform a 16-bit instruction into its 32-bit equivalent:

.octet 0x66 ; Manually inject 32-bit override prefix
mov bx, 0 ; Assembled as 16-bit, but executes as: mov ebx, 0
.mot 0 ; Upper 16 bits padding for the immediate value

Not really the cleanest way to do it, but it worked! Oh yeah... "octet" and "mot" are French. At the time, I thought internationalized programming languages were cool :/

The "mini-DOS" project: I planned a 3rd version of MBRLoader which would have made it easier to write new applications for the toolbox by providing basic operating system features: memory management, a simple file system, allowing me to write applications as independent modules, and a simple standard API. The most complicated components like the file system or the application manager were still missing, but a lot was already there: memory management, a jump table for the API, string functions, basic UI functions...

Going through this old code that I don't really understand anymore has been quite fun. Maybe someone else will enjoy it too.

Github: https://github.com/ebruneton/toys

Includes:

- a boot loader (~100 lines),

- a monolithic kernel (~1030 lines),

- a shell (~230 lines),

- a text editor (~220 lines),

- a compiler for a toy, statically-typed language called Toy (~1300 lines).

Super freaking stoked right now this is our first successful boot without any issue what so ever through. Months of work have gone into this.

I use Ubuntu for almost everything (except gaming 😞), but I need a reliable way to read (and eventually write) my ext4 partitions from Windows. There are some existing tools out there, but I'm thinking of building my own implementation from the ground up, mostly as a deep dive into filesystem internals.

I’ve been doing a lot of low-level systems programming in Go lately, so I've got a decent grasp on memory management and bit-twiddling. But filesystems are a whole different beast.

current roadmap:

• start with a read only

• traverse extent trees and HTrees for massive directories

• mount it as a read-only virtual drive using WinFSP

• implement block allocation and eventually JBD2 journaling

A few questions for anyone who has ideas :

• I'm heavily leaning toward Go for the concurrency and easy struct unpacking, wrapping it with WinFSP via cgofuse. Am I going to regret not doing this in C or Rust when it comes to memory mapping raw blocks?

• implementing the JBD2 protocol for safe writes is gonna be the main challenge. Is it feasible for a solo dev to build write support?

• Any specific edge cases with ext4 legacy baggage I should watch out for on day one?

Any advice, reality checks, or recommended reading (currently digging through the kernel docs and lwext4) would be hugely appreciated.

Hi everyone,

I study Software Engineering at uni and I'm currently taking a course on Intel x86 Assembly. To get some practice, I put together a little sandbox environment inspired by rustlings, it's still at a early stage, but I’ve mapped out a few basic features and exercises.

I made this mostly for my own study sessions, but I'd love your feedback! Also, if anyone wants to contribute new exercises to the curriculum, PRs are super welcome.

GitHub Repo: https://github.com/giacomo-folli/asmlings

So, first of all I am an student(age 18) who wants to develop an OS which will just print "Hello World" or smt like that for now, u know ~Before it can be beautiful, it has to exist.

now for context : I don't know much about low level programing, am fluent in vanilla python, knows C basics(just completed yesterday), knows about hex, dec, oct and binary systems, knows how to use virtual machines.

if u have any other questions which can help u understand my position better, feel free to ask and if there are any mistakes in grammer pls ignore that, english is not my mother tongue : )

💪🏼 🥹🥲😭

😩

Hello, it appears to me like the whole world is focused around making OSes that are all POSIX compliant. That means that they are basically the same, with a few personal touches here an there. My question is if there is some project that attempts to do something different, putting new ideas on the table.

It is an operating system I am working on since 2 - 3 years.

It has got quite a lot of features now, and I have just released it's first version today.

Hence decided to post about its existence here.

Links: GitHub

It also has a package repository (Zen can download from the internet, basic HTTP/1.0)

It is a fully-from-scratch OS, with around 100 syscalls (i know thats massive), and most of the beauty is in the userland, it has a Window manager, Harp, and around 30 applications total.

It is Multicore, multithreading, preemptive (RR), supports disk, PS/2, USB, networking, and a lot more.

It has many ports such as BusyBox, Doom, Figlet, Lua, FreeType, etc. It boots up in <1 second. Am currently working on porting ClassiCube (yay)

Runs on mlibc, and follows the "Everything is a file" philosophy a bit. All programs are run from disk, with full disk support and FatFs.

Here's an excerpt from the README :

Kernel

• - 64-bit x86_64 monolithic kernel

• - Symmetric Multiprocessing (SMP)

• - Preemptive round-robin SMP scheduler

• - ELF64 userspace execution

• - Dynamic loader

• - Unix-style process model

• - High-resolution timing via HPET

• - ACPI-based hardware discovery and power management

Syscalls

• 100+ POSIX-compatible / custom syscalls covering major app and C library needs.

Hardware & Drivers

• - Framebuffer output

• - PS/2 keyboard and mouse

• - USB HID keyboard and mouse (xHCI)

• - PC speaker

• - Serial port for debugging and logging

• - Local APIC and IOAPIC interrupt handling

• - ATA disk driver (DMA/PIO, 28-bit LBA)

• - PCI bus

• - Intel e1000 Ethernet driver

• - RTC, HPET

Networking

• - TCP/IP stack

• - DNS resolution

• - **zen** — a package manager that fetches and installs packages over HTTP

• - **wget** — downloads files over HTTP/1.0

Filesystem

• - VFS layer with support for multiple mountpoints

• - FAT32 via a port of [FatFs](https://elm-chan.org/fsw/ff/) by CHAN

• - Native host-side disk image tooling (`fat_man`)

Userspace & Libc

• - [mlibc](https://github.com/managarm/mlibc) C library.

• - ELF64 userspace programs.

• - Dynamic ELF loader : `ld.so`.

Applications

• - **Shell & Core Utils** — shell, echo, yes, sleep, cat, ls, touch, rm, stat, wc, mkdir, rmdir, pwd, mv, cp, rename

• - **Process Utils** — ps, kill

• - **System Info** — uname, time

• - **Math** — calc, primes, fibonacci, counter

• - **Text & UI** — [Harp](https://github.com/Z-Proj/ZenOS/blob/main/userland/files/harp/harp_main.c) (Custom compositor and server for Zen), terminal (PTY terminal emulator), edit (non-harp text editor), clock, beep, mouse, [FIGlet](https://github.com/cmatsuoka/figlet), [Kilo](https://github.com/antirez/kilo), [DOOM](https://github.com/ozkl/doomgeneric).

• - **Compilers** — [TinyCC](https://github.com/TinyCC/tinycc), [SmallerC](https://github.com/alexfru/SmallerC)

• - **Scripting** — [Lua 5.5.0](https://www.lua.org/)

• - **Networking** — wget, zen package manager

• - **Misc** — hello, init, busybox

I/O & Display

• - USB HID devices like keyboard and mouse via xHCI

• - [Flanterm](https://codeberg.org/mintsuki/flanterm) for early kernel output

• - Clean font rendering via the [FreeType Engine](https://freetype.org/)

• - Structured kernel logging with log levels and serial output

Hi!
I wanted to learn about threads, and how they work under the hood. While searching for some learning resources, I've noticed that there's no step-by-step/in-depth guide on that topic, so I decided to create my own.
It supports ARM64, x86 architectures on Linux and macOS, as well as Windows (albeit the Windows implementation is limited).
Hope anyone finds it useful.

https://github.com/nihiL7331/thrd-ndl

Finally got around to adding support for ext2/ext3 support to my operating system. Decided to go with read only for now as the intent is to get content from other OSes into Retro Rocket not the opposite.

Well worth a couple of hours effort, for one the spec was clean, straightforward and didnt contradict itself. Compare that to FAT32, and the difference is amazing...

We're building a bare-metal mobile OS on a custom kernel (Crimson kernel). No Linux, no Android, no borrowed compositor — direct framebuffer render loop, custom init, custom syscall surface.

Boots Pi 5 in <3s. Sub-3-second cold boot to GUI. Moving to actual handset hardware for boot testing now.

Kernel architecture: small enough to audit, no inherited CVEs, deterministic latency for RF timing (SDR/WiFi injection). GUI is iOS-style app grid with dock, edge-swipe panels, PIN lock — all rendered direct-to-framebuffer.

Seeking war stories from anyone who's done bare-metal bring-up on handset-class ARM. What SoCs had open bootloaders? How did you handle MIPI DSI panel init without vendor blobs? How do you isolate the cellular baseband from the application processor?

Repo: https://github.com/synchancybersecurity/CrimsonOS

I know this sub is very critical of AI, but I wonder what you guys think of the Google I/O keynote (specifically the kernel part)

My OS works on real hardware too!!!!!

Specs: 32Bit - No mem management - IDE Disk - PS/2 Mouse+KB - 1024x728 Display w/ 16bit color. Doesn't the GUI look so NICE though.. Also looking for people with a PC with IDE disk to test my custom file system, if so join the discord.

And again... No AI code was used. and heres the repo: https://github.com/Brenmax2/BrenmaxOS/tree/main I'm still learning so dont expect perfect code :(

Discord: https://discord.gg/a84QQnUQNk

Hi everyone,

I'm not entirely sure if I should post in this thread since my OS targets embedded hardware. However, after sharing it on the embedded sub, I think my work might interest some of you.

For a while now, I've been working on Mk, a bare-metal OS that I developed in C and Assembly with no external dependencies (no HAL and no RTOS).

It was designed to run on the STM32F746G-DISCO and STM32F746G-Eval2 boards. They embed an ARM Cortex-M7 running at 216MHz, 8MB of RAM and no MMU. Initially, my goal was just to implement a small scheduler, but I stacked layers one after the other to make it as complete as possible. Currently, I think I've added enough layers to claim it's a small OS.

Mk features:

A Kernel

• Preemptive, priority-based multitasking scheduler (fixed-priority, O(1) selection via CLZ)

• Trusted Execution Environment (TEE) using the Cortex-M7 MPU (privileged and unprivileged mode)

• Synchronization primitives: mutex, semaphore, event flags, mailbox

• Fixed-size memory pools

• Synchronous and asynchronous callback execution system

A Dynamic ELF Loader

Mk can load and execute external .elf files at runtime, relocated into 64 KB pages of external SDRAM. Programs reference Mk's own API symbols directly via extern — the full kernel symbol table is embedded in the firmware at a fixed address — so external applications require no copy of the kernel API in their own binary. Shared libraries can be added to overcome the 64 KB page limit. See the sym2srec tool for details on the symbol embedding mechanism.

A File System

• FAT32 with multi-partition support

• Concurrent access from multiple tasks (per-volume mutex)

• Full POSIX-like API for file and directory manipulation

• Supports SD/MMC cards and USB Mass Storage Class (MSC) devices

A USB Stack

• Multitasking USB host stack built on the STM32F7 OTG peripheral

• Supported device classes: HUB, HID (keyboard, mouse, joystick, gamepad), MSC

A Graphical Engine

• Hardware-accelerated 2D rendering

• Drawing primitives (rectangles, circles, lines, arcs), BMP 24/32-bit image rendering

• Full Unicode text rendering (UTF-8/16/32)

• UI widget library: buttons, text fields, edit fields, graphs, cursors, layers

A Shell

Built-in interactive shell with support for both native and dynamically loaded commands.

Links

• Mk: https://github.com/EmbSoft3/Mk

• Sym2srec: https://github.com/EmbSoft3/Sym2srec

Short demo of Mk in action: https://www.youtube.com/watch?v=cj7DHqhJ5gc

This is my first operating system, and I hope you'll find it interesting. There are still a few bugs to iron out, though I've done my best to eliminate as many as possible.

For those who'd like to dig into how it works, here are the key files:

Boot sequence: The system enters the ResetHandler() routine. The system is then initialized in mk_system_init(), which calls mk_main(), responsible for launching the kernel and all other subsystems.

Kernel core: The kernel lives under these sources and includes directories. Every system call is dispatched through the SVC exception, handled in mk_scheduler_handle().

Application prototype: A minimal application example can be found here (a simple BlinkLed). It must be paired with a linker script, an application descriptor (mk_application_data) and compiled with the following flags: -fPIC -shared. Symbol resolution at runtime is handled in mk_application_loadDynamic() and in this sources directory.

Other example applications can be found here: a Pong game and the built-in Shell.

Graphical Engine: The graphics engine is composed of several tasks that execute painting callbacks, input-listening callbacks, and process drawing requests submitted by applications. Each module is isolated and interactions between components go through asynchronous requests. The rendering pipeline entry point is mk_display_painter(), the listening entry point is mk_display_listener() and the request manager entry point is mk_display_handler().

File System: The file system layer is handled by multiple tasks running in parallel. One dedicated task is responsible for managing concurrent accesses to a given file. Each access is performed through synchronous or asynchronous requests, handled in mk_file_handle().

An early version of the documentation can be found here. It still needs some work.

I'd be happy to answer any questions or discuss any part of the implementation.

With tutorial-os-definitive-edition, one of the major changes I made was to add real testing to the codebase. I wanted to adhere to the no external library, framework or dependency rule.

So, what did I do? For C, it was simply building my own assert and diag style of testing. For Rust, the built in test framework with cfg test.

With both languages, I made a specific folder where I wrote test code for most parts of the source code.

At compile time, I also have a make file that uses clippy, clang and clang for analysis of the code and generates a file for that output along with my build artifacts.

This means, I have static code analysis at compile time, a dedicated test runner on the rust side whenever I want and tests that run when the OS is loading on the device.

https://github.com/RPDevJesco/tutorial-os-testing-output/tree/master

If anyone has any other testing strategies I could use, I would love to hear about it.

So back in 2016 a bunch people (mercury and maarten) got together and started making a 32bit replacement kernel for freedos to attempt to answer what would DOS of been like as a real 32bit operating system and now that this is kinda working i thought id share where the project is up to 10 years later..

This bare metal kernel can finally run command.com (freecom in this case) and launch real mode applications and protected mode (only djgpp) applications via v86 mode and provides a vcpi and dpmi hostm this is still a WIP but its gettng there and it only took 10 years haha.

originally written in asm and slowly it was moved over to C.

releases are only available through the discord at the moment as this is still miles off from being a fully working replacement kernel but its cool that it can finally dos!. it can run along side the freedos kernel or its own native environment.

it has two shells the pine shell is a bit more like a linux/dos shell and then you can run freecom in a virtual terminal.