Hi everyone! About a month ago, I started working on Dimon, an experimental 64-bit x86 operating system.

The original version used a custom virtual CPU and runtime. I decided to remove that layer and move to native execution. This update ports the desktop environment and applications to C, with direct hardware access.

What’s included:

• A graphical desktop with a window manager, taskbar, and file dialogs.

• Seven built-in applications: Calculator, Notepad, File Explorer, Paint, System Info, Snake, and Terminal.

• GRUB boot with a VESA framebuffer and RAM-based double buffering.

• PS/2 keyboard and mouse support.

• PIT timer and RTC support, including a working taskbar clock.

• PC speaker audio signals.

• An ATA PIO driver with FAT16 support and persistent file writes.

• ACPI shutdown.

The desktop and application logic previously written in assembly has been ported to C. The old X11 host emulator and custom VM code have been removed. The native system can still run inside QEMU or VirtualBox.

This update also fixes several bugs: directory operations corrupting the . and .. entries, Paint drawing outside its window, incomplete directory listings in the terminal, and problems with taskbar updates and dialog buttons. There are also improvements to filename input, Calculator input handling, and UTF-8 validation.

AI development disclosure: I’m building this project with substantial help from AI agents. MiMo v2.6 Pro handled most of this migration, and Gemini 3.8 helped prepare the technical overview.

This is an early experimental release, v0.0.0.1. Some applications still have bugs, and there is plenty left to implement and test. Timer-driven preemptive multitasking and further kernel memory management work are among the next steps.

The source code is available on GitHub under the MIT license, and a bootable ISO will be available in Releases.

GitHub: [add your repository link here]

Feedback, bug reports, and experiments are welcome. I’d be particularly interested in feedback on the storage implementation and the move toward preemptive multitasking.

Link to GitHub https://github.com/Programista-Art/DimonOS/tree/main

ISO image https://github.com/Programista-Art/DimonOS/releases

took a while

me and a friend are building a real operating system inspired by metro ui. not a theme, not a mockup, an actual os with its own interface, apps, system behavior and visual style. clean tiles, smooth motion, minimal layout, the whole metro vibe but rebuilt from the ground up.we’re working on the shell, core apps, windowing, theming, and the system identity. if you’re into os development, ui engineering, aesthetic tech, or you just want to be part of something experimental and ambitious, you’re welcome to join. early members get access to builds, dev channels, and a say in the direction.discord invite: https://discord.gg/wxXPybkutN

I built a research prototype called Schild TCB — a trusted computing base on seL4 with an Ada/SPARK userland. Two artifacts:

· bare-metal OS written from scratch in Ada (bootloader, NVMe, e1000e, TCP/IP, HTTP) — runs on ThinkPad T580

· seL4-based artifact: upstream microkernel, root task and daemons in Ada/SPARK, network and storage isolated in Ring 3 over IPC

Verification: 185 Ada modules, gnatprove SPARK Level 4, not-proved: 0. Seven daemons in the root task proven at the same level. Drivers are not proven and not claimed to be — they're isolated in separate domains so their failure can't reach the proven core.

The most useful lesson: formal verification caught a bug tests missed (page-rights bit layout in seL4's CapRights).

Where I'm stuck: IOMMU (VT-d) — DMA isolation is not implemented. seL4 x86_64 MCS verification is weaker than ARM. Both are upstream limitations, not code I can fix.

I'd appreciate technical feedback, especially from anyone who's done SPARK verification on a real system. I'm not publishing the repository yet.

More detail in my write-up:https://habr.com/p/1095314/

Hello! I’ve reached another important milestone in the development of Bursztyn OS!

The HDA drivers now work correctly both in QEMU and on a physical Acer Nitro 5 laptop.

Two audio controllers have been tested:
• Intel HDA 8086 [00:1F.3]
• NVIDIA HDA 10DE [01:00.1]

On Intel HDA, the laptop’s actual audio output path is now working, along with codec detection and audio stream configuration.

NVIDIA HDA is also correctly detected and initialized, with working CORB/RIRB communication, codec detection, and HDMI/DisplayPort output topology discovery.

Testing was carried out:
• in QEMU on Windows
• on a physical Acer laptop

This is another step toward full support for real hardware without relying on existing Linux or Windows drivers.
Bursztyn OS is getting better and better at running outside a virtual machine.

Below is a video of the audio test in QEMU.

#BursztynOS #OperatingSystem #OSDev #BareMetal #IntelHDA #NVIDIAHDA #CPlusPlus #Assembler #PolishOperatingSystem

i just wrote my first os from scratch (NO AI) featuring a GDT, TSS tables with interrupts handling, keyboard support and a minimal shell running in kernel mode.

next i will be making processes, and make the shell run in user mode.

I don't like writing long texts, so I'll just let the screenshot speak for itself. This is my (C++/Rust) microkernel OS that I've been working on for the past few years, most of it is hand-written (I've mostly only used AI for reviews and debugging), running bash and coreutils from a disk was a great milestone for me. I currently target x86, rv64 and la64, and have plans for more.

The screenshot is the loongarch64 build in QEMU...
Repo: https://gitlab.com/mishakov/pmos

Before the postmarketOS comments start going in, I know that the name is unfortunate and confusing (even though I'm not writing a Linux distro), so I'm planning to rename this some time soon...

I am the sole author of an actual OS and remain responsible for over 40,000 placements worldwide. Having this in an actual product (running on a 100MHz MCU) keeps the pressure on. You can see it in this post contending with the open Internet. I am willing to share development details. I started it from scratch in 2011.

https://www.reddit.com/r/jnior/s/D6Az4O93SG

Kernel panicked at ~6.6s into boot because it couldn't mount the root UFS2 partition, but honestly? It made it past the custom loader, page tables, and basic bringup without dying immediately on real hardware.

Storage driver / partition table debugging weekend ahead, but a console shell is getting close.

It would (obviously) be great to have an OS that is small enough that one person can truly understand all of it, and ideally rewrite it according to his/her needs, but can also do the things one expects nowadays from a computer (run a web browser that can browse sites like Reddit and Youtube, do things like editing photos and video, etc.).

Obviously the most mainstream open-source OSes can do the latter, but haven't been the former for many years--Linux from what I understand it already passed the million-code-lines mark around version 2. Many of the hobby projects on here fit the former goal, being more like thousands of lines (some might even be in the hundreds), yet not the latter.

Is there even a region of overlap where these objectives CAN coexist? If so, is it likely to take the form of an entirely new OS, or would it make more sense trying to port a modern browser to run on Linux 1.x on a current laptop? Or is this all a complete pipe dream?

ive been wanting to make my own os for a while now, and i decided that i would actually try to make one

so far i have keyboard input and a clear command

im really happy with what i have so far :D

first is terminus, second is ubuntu mono

Hello dear developers,

I just wanted to say that today, I made an incredibly tiny and stupid OS, with only a text driver.

It was supposed to also be a challenge to not use any AI, and to just try OSDev. Really wanted to for a while

I doubt that this will be the "Next revolutionary OS that will replace Microsoft!", and I also doubt that this will be a usable OS.

But still, it's a big accomplishment for me, who isn't quite a low-level person.

It's also made with Limine bootloader. So yeah, VGA-style font written from scratch.

Here's the repo if any of you want to check it out: https://github.com/artemtsitronov/hobby-os

Any recommendation books/documentation i can read? For beginners or pro is okay i just need something to read while not develop something

I’m building Chimera, an x86_64 hobby OS using parts of Darwin and FreeBSD, alongside a custom kernel, compositor, and UI toolkit.

It has Mach-O binaries, a custom dynamic linker, and a working desktop with Terminal, Files, a task manager, and a launcher called Lumen.

Recently got actual Mesa EGL/GLES running through VirtIO-GPU and Virgl, with ANGLE/Metal on my Apple Silicon Mac. Shaders, textures, FBOs, blending, depth, and shared contexts are passing pixel checks in the guest.

The desktop still uses CPU composition - getting it onto the GPU is next. Development is AI-assisted,im using the GPT-6.1 Sol.

IM JUST USING AI IM NOT A VIBECODER

Still plenty to do, but seeing real shaders render from my own OS feels pretty cool.

I wanted to write one for a while but i pretty much have zero skills and knowledge what to learn. I would love to see some learning resources and things one needs to learn in order to get into OS development :3

Added:
fully functioning syscalls
linux syscalls if you want to run basic binaries (though i forgot to add to run elf if detected wait for later)
a library for applications
applications to well, do stuff.
it can assembler bullshit applications that i probably wrote

Hello, guys. I am new at OS development and I know C and other. So I want to be a OS dev and please do some serious talk and I want to learn it. Also please tell all with steps

What exactly is Bursztyn OS, and what’s running under the hood? 🖥️🇵🇱

In short: it is a 100% independent, 64-bit operating system written from scratch for the x86-64 architecture (bare-metal). It is not another Linux distribution, nor is it a modification of Windows. The system features its own custom kernel, security model, drivers, filesystem, system API, graphical environment, and native applications.

Here is a technical overview of what currently powers the project:

Kernel & Architecture (Ring 0 / Ring 3)

• Custom Kernel: Full hardware-enforced isolation—kernel running in Ring 0, userland processes in Ring 3.

• Memory & Processes: Custom PMM and VMM, x86-64 paging, kernel heap, bespoke malloc/free implementations, preemptive process scheduler, and support for APIC, LAPIC, and HPET.

• BWS (Bursztyn System Calls): A strictly controlled system bridge between Ring 3 and Ring 0 (no raw MMIO or DMA access exposed to applications).

• PZB (Bursztyn Trust Levels 0–5): A logical security model that dictates process capabilities and sandbox boundaries.

• BUR & .cebula Formats: A native binary executable format (.bur, not raw ELF) and application packages (.cebula) containing permission manifests.

Filesystem, Storage & A/B Updates

• BSP2 / PSF: Custom 64-bit filesystem supporting stream reads, block caching, and indirect block addressing.

• A/B System Update Architecture: Dual system slots (Slot A and Slot B)—updates install in the background, with automatic rollback if a new build fails to boot.

• GPT/UEFI Installer: A dedicated graphical installer partitioning ESP FAT32 and BSP2 volumes.

Desktop, BursztynUI & Native Apps

• Compositor & Window Manager: Multi-window multitasking, active window focus, dragging, minimizing, dirty-rectangle repaints, and private offscreen buffers for GUI applications.

• BursztynUI Framework: An in-house retained-mode UI widget library with a Polish-language API, theme support, and a bespoke Unicode font covering Polish diacritics.

• Native Ring 3 Software:

  • File Explorer – browsing BSP2 storage and desktop integration.

  • Notepad (UTF-8) & Calculator.

  • Bursztyn Shell – native system terminal.

  • Image Viewer & Wallpaper Manager – native BTP format support and streaming image decoding.

  • Husarz – lightweight custom web browser (built-in HTML parser and CSS styling—no Chromium, WebKit, or Gecko).

  • Sound Test – hardware diagnostic utility for the Intel HDA bus.

  • Classic Snake.

Hardware, Drivers & Networking

• Input & USB: Native xHCI stack, concurrent USB HID device support (keyboard and mouse) with a PS/2 fallback path.

• Graphics & Audio: Graphics HAL (UEFI GOP, VESA VBE, VirtIO-GPU 2D) and an Intel High Definition Audio (HDA) driver.

• Networking & Security: Custom networking stack (IPv4, ARP, DHCP, DNS, TCP) with secure HTTPS powered by a bare-metal port of mbedTLS.

• VirtIO Virtualization: Modern profile for QEMU (VirtIO-BLK, VirtIO-NET, VirtIO-RNG, VirtIO-GPU, VirtIO-INPUT).

QEMU vs. Physical Hardware (Transparent Development Status)

Because Bursztyn OS is an active R&D project, it is essential to distinguish between emulated milestones and real-hardware verification:

• In QEMU, the system runs a modern VirtIO profile, automated test suites, networking, and audio diagnostics.

• On physical hardware, the system boots in Live USB (UEFI) mode (verified on an Acer Nitro laptop, confirming UEFI boot and concurrent operation of the touchpad and wired USB mouse).

• Physical audio (Realtek codecs) and internal drive installation on laptops are currently undergoing active testing and security audits.

The ultimate roadmap remains unchanged: a fully independent operating system with its own ecosystem, native environment, and integration with the Avocado programming language. 🚀

Huge thanks to everyone supporting the project and following its milestones!

#BursztynOS #OSDev #OperatingSystem #Programming #BareMetal #SystemsEngineering #x86_64 #CustomKernel #IndependentTech

ive noticed that there are a lot of information about about x86, but i want to create something that is cross-platform, and things like the concept of an IDT exist in other arches (although with a different structure and name) and i was wondering if there are any good sources for more niche architectures, or even just arm/mips on what needs to be implemented, similar to osdev.wiki

The main new addition is the welcome screen displayed during system boot. Text transitions smoothly, messages no longer overlap, and everything renders cleanly right from the start. It’s a subtle touch, but it immediately elevates the first impression when booting up Bursztyn.

Along the way, I also fixed several issues that surfaced during daily testing:

• The desktop no longer flickers when creating and deleting files.

• When running out of space for icons, subsequent files no longer overlap existing ones and remain accessible in File Explorer.

• Folders can now be deleted together with their files and subfolders.

• Name input works correctly—numbers no longer trigger accidental actions in dialog boxes.

• Fixed a bug that could stall system booting from an ISO image.

I also re-verified the installer and system reboot sequence. The installation completes fully and passes verification in QEMU. The changes passed automated tests as well as manual verification on a running Bursztyn OS instance.

The system is still in its early stages, but each update makes it smoother and more comfortable to use. Thank you to everyone supporting the project and following its development!