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.

Screenshot (Taken In-OS)

Screenshot (Taken In-OS)

Boot Screen

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

Всем привет, я пишу здесь об этом так как не знаю что добавить. Я делаю собственное ядро на VoidLang основанном на C++, но оно немного кривое, пока что работоспособных прототипов нет (кроме Linux дистрибутива созданного мной 2 месяца назад, в самом начале проекта основанного на спор), вот некоторые изменения файловой системы:

***.vx (ранее .void, это исполняемые файлы по типу .exe)***
***.vkr (новые файлы, модули ядра)***
***.vsec (системы безопасности)***
***.vdat (контейнеры данных вместо .vd)***
***.varc (ранее .xsr, разница в том что новые не сжимают файлы, как можно понять является архивом)***
***.vcfg (файл конфиги)***
***.vme (ранее .vud, файл пользователя)***
***.vsav (файл сохранений)***
***.vth (файл темы)***
***.vlog (файл для логов системы и приложений)***
***.vfn (файл для шрифта)***
***.vsh (скрипты)***
***.vai (файл для ИИ модулей на будущее)***

Дополнительно:

Спасибо всем, кто даёт обратную связь. Чтобы сразу снять возможные вопросы и избежать путаницы, поясняю главные технические моменты, которые уже всплывали в других обсуждениях:

1. Мой VoidLang (HolyVoid) — это не LLVM-проект и не клон C.
   Я не использую сторонние компиляторы для продакшена. Мой язык базируется на синтаксисе C++, но это самописный транслятор, который я называю HolyVoid. Сейчас для прототипирования он конвертирует код (.vc) напрямую в чистый C++, который потом собирается GCC. Это временная мера, чтобы отладить синтаксис. В финальной версии транслятор будет генерировать сразу готовый .vx-файл (мой исполняемый формат) напрямую в байт-код, минуя GCC и LLVM. Никакой LLVM на целевом железе не нужен.
2. Почему не GCC, не Clang и не общепринятые форматы.
   Я пишу не просто софт, а закрытую экосистему. Каждый файл в ней (.vx, .vkr, .vdat) имеет не только расширение, но и вшитую цифровую подпись. Ядро просто не запустит код, если он не подписан моим ключом разработчика. Использование чужих открытых форматов (ELF, PE) ломает эту модель безопасности на корню. Поэтому все форматы свои.
3. «Всратость» форматов — это осознанный архитектурный выбор.
   Новые форматы (.vx, .vkr, .vdrv, .vfeel, .vsoul, .vdat, .varc, .vcfg, .vme, .vsav, .vth, .vlog, .vfn, .vsh, .vai) — это не рандомный список. Каждый тип имеет свою структуру заголовка с магическим числом и своё место в системе. Драйверы разделены на классы (.vdrv для стандартных устройств, .vfeel для сенсоров, .vsoul для ИИ-ускорителей), чтобы ядро могло их изолировать. Это не неудобно, это дисциплина.

Если у вас есть технические вопросы по архитектуре микроядра, по системе объектов Void или по модели безопасности — задавайте. Я отвечу, когда смогу. Интернет нестабилен, но проект жив.

https://i.redd.it/sv0w5efvh32h1.gif

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.

Every 3rd post is an AI slop post. Like the AI blue color just gives it away. How does someone feal pleasure from showing off stuff that they didnt even make???? Its so annoying there should be a new rule saying NO AI. These 15 year old kids need to stop posting ai slop.

Im actual aboutta crashout.

when i am swithcing to 32 bit protected mode before the far jmp i am doing [bits 32] but it is giving me error on qemu if i put after the far jump then it is working fine , i want to ask why is this happening

[bits 16]


switch_to_pm:
    cli
    lgdt[gdt_descriptor]
    mov eax , cr0
    or eax , 0x1
    mov cr0 , eax


    [bits 32]


    jmp CODE_SEG:init_pm
    


init_pm:
    mov ax , DATA_SEG
    mov ds , ax
    mov ss , ax
    mov es , ax
    mov fs , ax
    mov gs , ax


    mov ebp , 0x90000
    mov esp , ebp


    jmp BEGIN_PM[bits 16]


switch_to_pm:
    cli
    lgdt[gdt_descriptor]
    mov eax , cr0
    or eax , 0x1
    mov cr0 , eax


    [bits 32]


    jmp CODE_SEG:init_pm
    


init_pm:
    mov ax , DATA_SEG
    mov ds , ax
    mov ss , ax
    mov es , ax
    mov fs , ax
    mov gs , ax


    mov ebp , 0x90000
    mov esp , ebp


    jmp BEGIN_PM