I know programming, obviously, however I don't know much about the operating system. Most people can make apps within an environment, but most of us don't know anything beyond that

I want to deeply understand how the computer I'm using works, even just the software part

If you go on a virtual tour of your computer, like browsing the file system, or even looking at the plain old desktop, there's so many endless things in front of you, that most people have no idea how to make

How do I make a Windows desktop app? Why does it run on Windows? Same for MacOS

How do tab sizes work?

What is the desktop "screen" and why can I click and drag my mouse to highlight the icons? Where are those icons stored?

I can code a website, but I don't know a clue about how the browser works

How do I make a file system? I mean, isn't it just a large data structure, and I know data structures, so I'm sure I can learn it

Why does my task bar pop up when I drag my mouse all the way to the bottom of the screen?

What does it mean to turn on a computer?

Why / how does my physical mouse control my cursor? Is there a way I can "hack" my mouse? How do I code the firmware in my mouse?

How does the OS accept and eject USBs?

How do you allow your OS to connect to wifi?

What really is a .txt, .pdf, .rar .zip? Why can some OS's open them, some cannot?

Stuff like that

Can most of you point to any part of the screen and know how it works?

repo: https://github.com/NoTheIdiot/WindogeOS
finally no more page faults when making programs, oh yeah v0.2.2 but thats not relevant

ignore the elephant in the room

(no ai)

bits 16
org 0x7c00
mov ax,0x13
int 0x10
push 0xa000
pop es
xor di,di
mov cx,64000
mov al,1
rep stosb
jmp $
times 510-($-$$) db 0
dw 0xaa55

Hi everyone. I am currently an undergrad Computer Science student, and I am putting together a proposal to use OS development for my final degree project. I would love to get opinions and advice from anyone in the community, whether you are a hobbyist, a veteran, or someone who has taken a similar academic route.

For context, I have been building a custom 64-bit kernel in C++ and *a little* Assembly, but mostly Limine doing the abstraction for the bootloader. It currently has a shell (a previous project I integrated in), working compositor, basic window management, and double buffering. To fit the academic requirements of a final project, I am trying to narrow down a specific research or engineering angle. I have two main ideas right now:

1. Rust vs. C++ in OS Development (Speed & Safety) I have recently fallen in love with Rust and its memory safety guarantees. This angle would involve porting core components of my C++ kernel to Rust and evaluating the two languages side-by-side. The focus would be on development velocity, memory safety outcomes, and the friction of implementing low-level systems in both environments.
2. A Predictable Memory Admission Architecture Alternatively, I am considering focusing the project on the policy side of memory management. The core idea is an OS where applications declare hard, page-granular memory budgets upfront. Instead of relying on reactive termination when RAM gets full, the OS would use strict admission control to guarantee that admitted apps always fit. This would explore arbitrary minimum granularity for apps rather than rigid tiers, ensuring strict system predictability.

I would really appreciate your thoughts on a few things:

• Which of these two angles (language comparison vs. memory architecture) feels like a better scope for a university project?
• For those who have tackled OS dev in an academic setting, what were the biggest pitfalls in defining your project scope?
• General thoughts or advice on shaping a hobby kernel into a gradable thesis?

For further context, I'm actually neurodivergent (predominantly inattentive ADHD), so I tried getting into a boring project earlier but failed. As such, I'm looking for something that'll keep me steady like the kernel did...

Link to my kernel project: https://github.com/Powerisinschool/swish_kernel/

Thanks in advance!

Hi r/osdev. ranix is my hobby kernel. I wrote the first asm and C by hand; later Claude (the AI) joined as a pair programmer, and every commit it touched carries a Co-Authored-By line, so you can see exactly which parts are whose.

What works so far (690 commits, ~95% C):

• aarch64 (QEMU virt, Raspberry Pi 4 boot files) and x86_64
• a vDSO good enough for glibc's AT_SYSINFO_EHDR parse, UTS namespaces, tmpfs/ramfs, devfs with mknod(2)
• doomgeneric runs
• latest milestone: pacman -U / pacman -S installs an Arch Linux package from a file:// repo

The goal is to run ordinary Linux distro binaries unchanged, not to clone Linux's driver ecosystem.

Code is public and readable without an account: https://grove.metastaz.org/rasi/ranix (our own self-hosted git forge; if you're already writing your own kernel, renting someone else's forge felt a bit off).

Hard criticism welcome, especially on memory management and the user/kernel boundary.

(Post text drafted by Marshall, our AI assistant.)

sped up showcase vid

github repo: https://github.com/chair1842/panuti

hi. im 13 years old.
this is the os i've been working on for ~5 months.
Panuti has its very own shell, a vim/vi clone, and its own coreutils. (All in ring 3)
Panuti also supports VGA text mode, serial output, ps/2 keyboards, CD-ROMs and IDE hard disks (I use PIO mode so it's very slow).

More progress on my OS: Mesa-backed GPU rendering, a native desktop with blur and window animations, HiDPI support, and working system settings.

And, of course, a native Pac-Man port using the original Atari maze and sprites.

For the past few days, I’ve been heavily developing Husarz - the native web browser for Bursztyn OS. The latest changes are among the biggest improvements ever made to its engine.

The most important change: web pages now have their own styling, independent of the system theme.

Previously, changing the Bursztyn OS theme could also affect the colors of the web page itself. Now, the system theme changes only the Husarz browser interface, while the page content keeps its own appearance.

This has been tested directly in QEMU - both a white page and a black page kept exactly the same colors after switching the system theme, while the browser UI changed correctly. ✅

🎨 Much broader CSS support

The Husarz engine now includes support for:

🔸 all 148 named CSS colors
🔸 HEX colors with alpha channel
🔸 rgb() / rgba()
🔸 basic hsl() / hsla()
🔸 more advanced selectors
🔸 nth-child and not
🔸 inline-block
🔸 position: relative and absolute
🔸 an improved box model
🔸 much better lists and tables

🖼️ PNG and JPG directly on web pages

Husarz uses the existing Bursztyn OS image decoders - I’m not creating a separate PNG/JPEG parser just for the browser.

Now supported:

✅ PNG
✅ JPG/JPEG
✅ <img>
✅ background-image
✅ transparency
✅ scaling
✅ repeat
✅ contain
✅ cover

I also added a ResourceCache, which stores resources in RAM, uses an LRU mechanism, and enforces memory limits.

⚡ Page loading should no longer block the GUI

This is one of the most important changes.

A separate Ring 3 process has been created:

husarz-worker.bur

It handles blocking HTTP/HTTPS operations, DNS requests, and image decoding outside of the main browser interface.

Husarz also validates the PID, request IDs, tab IDs, and document generations to prevent delayed results from an old request from accidentally being applied to a newly opened page.

📝 Forms are now interactive

Supported elements include:

🔸 text fields
🔸 password fields
🔸 textarea
🔸 checkbox
🔸 radio
🔸 button
🔸 submit
🔸 select / option
🔸 label

Forms are rendered by the Husarz web engine rather than using native BursztynUI system controls.

The GET method works, while POST is still intentionally disabled for now - the current Bursztyn OS networking API does not yet provide a mechanism that I would consider sufficiently safe for implementing POST properly.

📊 Tables have also received major improvements

Husarz now handles rowspan and colspan much better.

The engine builds a logical table grid and ensures that cells do not overlap incorrectly. I also improved column width calculation and border-collapse behavior.

More realistic margin collapsing has also been added, including support for both positive and negative margins.

🧪 And what about testing?

This part has become serious as well.

The engine has passed hundreds of thousands of automated checks, sanitizer-based tests, and direct QEMU testing.

During one of the latest stages, 397,771 host-side checks were completed without sanitizer errors.

QEMU tests covered, among other things:

✅ images
✅ cache
✅ forms
✅ CSS
✅ tables
✅ rowspan and colspan
✅ margin collapsing
✅ the asynchronous worker
✅ system theme switching
✅ maximize / restore

Not everything is finished yet, and I’m not going to pretend that Husarz is already equivalent to a modern Chrome or Firefox.

Still missing are, among other things:

🔸 float and clear
🔸 fixed and sticky
🔸 z-index
🔸 full nested scrolling
🔸 POST
🔸 WebP, GIF and SVG
🔸 improved HTTP cache revalidation
🔸 multiple parallel TCP/TLS connections
🔸 more complete text selection
🔸 JavaScript

JavaScript in particular will be a separate, major development stage. A parser, interpreter, DOM, events, and security model are practically an entire subsystem on their own, so I don’t want to add JavaScript “quickly” just for the sake of checking another feature off the list.

Another important limitation is that the current TCP stack still uses global state for a single active connection. Before Husarz can truly download multiple resources in parallel, the networking stack needs to be redesigned so that each connection has its own independent state.

Despite these limitations, Husarz has made a huge leap forward.

Not long ago, it was still a very simple browser. Today it already has its own HTML/CSS engine, PNG/JPEG image support, resource caching, forms, a much better layout engine, and a separate process responsible for resource loading.

And all of this runs as a native Ring 3 application in Bursztyn OS. 🇵🇱

This is still only the beginning, but this is exactly how I want to develop Bursztyn - step by step, testing every new layer and not calling a feature “finished” until it actually works. 🧡

#BursztynOS #Husarz #PolishOperatingSystem #OSDev #Programming #BrowserEngine #WebBrowser #Cpp #OperatingSystem #MadeInPoland

Any chance that AIs are able to create new OS? I'm a total noob, maybe you guys have insight if it's possible we get vibe coded Windows copy, without spyware and bloated running apps, something like ArtCraft?

https://sbvrg.github.io subverge is very much still in development and accepts contributions, see

https://sbvrg.github.io/development.html for development and

https://sbvrg.github.io/handbook.html for all the pages of subverge

I recommend seeing the history page first https://sbvrg.github.io/history.html

Let's have a friend write about the ai slop lol

I know I probably will get downvoted to hell, but personally I've been enjoying using AI as a learning tool in addition to manuals and OSDev wiki. It helps me understand some concepts better, explore other OSes design decisions and helps me get my thoughts together so I can make a decision that makes more sense to me at the time.

I think it's a very powerful learning tool if used right, instead of simply telling Claude to make linux 2.0 running DOOM. The code is still written by me (well, mostly, sometimes I ask Codex to do some big mechanical refactors, like move code to other files, or writing doc comments), and I understand all of it.

Hi everyone, my name is joseicaro, I'm 14 years old, and I have level 3 autism. I'm creating my own Frutiger Aero operating system called Glint OS, and this video shows the version I'm currently developing. I'm using Claude AI and ChatGPT for the design because I don't have the money to hire a designer, and I find it easier this way, but it would also look prettier with a designer. I also released the beta for everyone to use, but the development version shown in this video and post is much better than the Glint OS beta. I've been working on Glint OS for 2 months, and the video may show some bugs in Glint OS that I haven't fixed yet, but I'm going to fix those bugs, improve some things, add new features, and more. And please, don't insult me for using AI.

I’m working on a hobby OS called D-DOS (it’s not my first one), and I’d like to hear what you think of the idea behind it rather than the code.

it started with a dream where I had built an OS that let me interact directly with the computer’s hardware, with nothing hiding the machine from me. I decided to try to turn that into something real. The goal is a system where the user can, from a simple shell, read and write memory and I/O ports, browse PCI devices, talk to an HDA audio codec, query a disk with ATA/AHCI commands, read ACPI/SMBIOS tables, and so on. It’s less “an OS to run programs on” and more “a guided tour of the machine you’re sitting at”.

Where it is: very early. A NASM stub with a Multiboot header calls into C, which prints text to the VGA buffer. Everything above is a plan, not something that exists yet.

Why I think it could matter beyond my own curiosity: I wonder if something like this could be useful in computer science courses. Students usually meet hardware through diagrams and abstractions, and OS courses often stop at the kernel interface. A system where you can type a command and actually see a PCI configuration space, flip a bit in a device register, or hear a tone from an HDA codec might make the material more concrete. I’m aware that teaching kernels like xv6, MINIX and Pintos exist and are great at what they do, but they focus on OS concepts (scheduling, virtual memory, file systems) rather than on poking the hardware directly.

What I’d like to know:

• Does the concept sound interesting, or is it solving a problem that doesn’t exist?
• If you’ve taught or taken an OS or architecture course, would a tool like this have helped?
• Is there something that already covers this that I should look at?

TL;DR: A design concept for an OS where every app declares a hard memory ceiling, so the OS can guarantee admitted apps fit in RAM and never thrash. It's about predictability, not smaller pointers. No implementation yet, I'm looking for holes in the idea before I consider prototyping.

The model

• Bounded apps: each gets one contiguous region (e.g. 64 KB, 1 MB, 4 GB). The app sees a flat space starting at 0 and uses 16/20/32-bit offsets. The real address is base + offset, done in the addressing mode (GS-relative on x86-64, or a reserved base register elsewhere). Zero-extended offsets mean the app can't name an address outside its region.
• Thin-client UI: the OS draws, the app declares a retained-mode UI tree and only holds core logic. That's what makes ~64 KB apps plausible (Pebble, Palm OS, early Mac).
• OS-side costs charged at admission: widget trees, handle tables, etc. are computed from the manifest, so no hidden footprint.
• Raw mode: games, local LLM tools and the like get normal 64-bit pointers and the whole machine, but are foreground-only and one at a time. Bounded apps are frozen in place (they're relocatable, pointer-free blobs, so snapshot/restore is a memcpy), then compressed in RAM, then spilled to storage as a last resort.
• Sandboxing: capability-style handles instead of ambient authority, OS-owned UI (no screen scraping or overlay spoofing), and no background execution for most apps.

Prior art I'm drawing on: WebAssembly linear memory, Native Client, V8/JVM pointer compression, iOS jetsam and background suspension, CHERI, console quick-resume.

Weak spots I already know about

• Offsets only confine data. Native code could still issue raw syscalls or touch segment registers, so I'd need bytecode/WASM-style, SFI with a verifying loader, or hardware trapping.
• Toolchain cost: a compiler target and tiny runtime for offset-addressed binaries.
• Side channels between apps sharing an address space.
• Memory caps don't stop CPU spinning, so apps also need time budgets.

What I'd love feedback on

1. Which code-confinement approach fits best here: bytecode, SFI, or hardware trapping?
2. Should a 64 KB budget include code, or is code mapped read-only and counted separately?
3. Are the tier boundaries (64 KB / 1 MB / 4 GB / raw) sensible, and what breaks first?
4. Is a retained-mode UI API too limiting for real apps?

Full doc here: [link]

Disclosure: the idea is mine, but I used an AI assistant (Claude) to help structure the longer write-up.

disclaimer: sorry for bad english

I created my own OS in C from scratch using C and assembly, it has desktop environment and drivers for mouse and keyboard (only PS/2) and it has internet (for now its only http and html 1.0), the comments and readme are in polish for now, the code is opensource (gpl 3.0)

github repository: github.com/kurczatko/tarixenOS

im ready for feedback (the code isnt proffesional because its only hobby)

I'm a mechanical engineering student, and for a while I've been designing SquareOS, a concept OS built around a square main display. To be upfront: there's no kernel or code yet. The plan is a custom Wayland compositor shell on top of Ubuntu Core, not a from-scratch kernel.

Who it's for:
Power users who spend most of their day inside one main application: CAD engineers, developers, designers, video editors. Instead of juggling windows, the OS is built around that one app.

Core ideas:
- One app at a time on center stage: the main app sits in the middle of a large square screen, with movable widgets around it and the wallpaper always visible
- A "Context Box", a command box where typing something like `cad` switches the whole workspace (app + widgets) into CAD mode
- Square primary screen runs only native SquareOS apps; legacy/compat apps (via LXD) live on a secondary 16:9 screen
- Apps ship as Snaps with two layouts (classic 16:9 and adapted 1:1); a SquareSDK defines the layout contract
- Unified maintenance: the store only installs/uninstalls, all updates go through one Update panel, and `dyt` runs quiet background updates
- Separated storage with A/B system partitions and a rollback to a known-good "master" OS

Teaser (2 min): https://youtu.be/McWzEfQSUSY

Questions for people who've actually built this stuff:
1. Is Ubuntu Core + a custom Wayland compositor a sane base, or would you go another way?
2. Is splitting native and legacy apps across two displays realistic, or a dead end?
3. Does forcing every app to support a 1:1 layout kill it before it starts?
4. What would you keep, and what would you kill?

Happy to take feedback.

So I got LingOS to boot on Raspberry Pi5 with Keyboard, Mouse, and HDMI/Audio support. I am going to try to get a qwen 4b model which is 5GB to run locally on it from the SD maybe. If that doesn't work I might set up an x86 server app that can load the model and serve it, and you can give a local network address and port on the Pi and Viola! You have LingStationX running on LingOS!