Luka12-dev

Developer here, if you have any question you can ask me now :D

Some tips for trying the demo:

Click inside the screen to interact Open the Blaze Browser from the dock to see HTML/CSS rendering Try typing "help" in the Terminal for a list of 50+ commands The Calculator, Paint, Snake, and Notepad apps are all in the dock Type "python" in terminal for the built-in Python interpreter (python for DOSMODE, for GUIMODE(default), make file and for example run python main.py)

The entire OS is 1.8MB including all apps and the web browser. Everything is written from scratch in C and x86 Assembly, no external libraries.

Happy to answer any questions about the kernel, window manager, browser engine, or anything else!

I worked on AurionOS locally, and pushed it to GitHub when it was finally ready.

Thanks! Happy to share.

Most helpful references: Intel Software Developer Manuals for understanding x86 architecture osdev.org wiki for the basics (GDT, IDT, memory management) Reading source code of other hobby OS projects to understand different approaches James Molloy's kernel tutorial helped me get started

Most memorable challenge: Getting the window manager working with proper overlapping windows and mouse interaction. The z-ordering and dirty rectangle system took me a while to get right, windows kept rendering behind each other or the mouse would interact with the wrong window. Debugging graphics issues without a working debugger in your own OS is... an experience haha.

Most surprising thing I learned: How much modern OSes do that we completely take for granted. Even something simple like moving a window smoothly requires double buffering, proper

careful memory management. Made me appreciate every pixel on my screen.

What kind of OS project are you planning?

No problem at all, thanks anyway!

Fair point on toolchain complexity and portability, C's minimalism there is genuinely hard to beat. But it's a tradeoff: you're trading toolchain simplicity for the burden of manually ensuring memory safety. Depends on whether your priority is long-term portability or correctness guarantees.

Fair question! I understand the skepticism.

The account is newer because I only recently started putting my projects on GitHub. I've been programming in C and Assembly for a while before that, just locally on my machine.

The commit activity might look unusual because I worked in very intense 12h/day sprints over 14 days.

As for AI, I'm happy to do a live walkthrough of any part of the codebase, explain the design decisions, or answer any specific technical questions about the implementation.

I appreciate the scrutiny though it keeps the community honest!

Thanks for the suggestion! I've heard great things about both Rust and Zig for systems programming.

I started with C because most osdev resources and tutorials use C, and I wanted to understand manual memory management at the lowest level first.

Might explore rewriting parts in Rust or Zig in the future, the safety guarantees do sound appealing for kernel code!

I wrote the core architecture and most of the code myself. I used Claude occasionally to help debug tricky issues and understand some concepts, but the design decisions and implementation are mine.

I think AI is a great learning tool when you're trying to understand low-level concepts for the first time.

My general rule was:

Assembly for anything that HAS to be assembly: bootloader, GDT/IDT setup, interrupt handlers, context switching, and port I/O wrappers.

C for everything else: window manager, apps, drivers, GUI rendering.

Some parts I probably could have done in C with inline assembly but I found writing pure ASM for the low-level stuff helped me understand exactly what was happening at the hardware level.

What choices looked different to you? I'd love to hear your perspective always looking to improve!

Thanks!

The filesystem is currently pretty simple - a basic flat structure on the ATA drive. I was inspired by FAT-style simplicity since I needed something working quickly for the Notepad save/load feature.

Planning to implement something more robust, as the project grows.

What would you recommend for a hobby OS filesystem?

Great suggestions, thank you!

virtio-net makes a lot of sense for VM testing - I'll look into implementing that alongside the RTL8139 driver.

v86 is a really cool idea, having Aurion OS run in a browser would be amazing for demos. I'll definitely explore that.

And yeah, the 12 hour days were intense but honestly I was having so much fun I barely noticed haha. School still gets done though :)

Thanks! I'll definitely check out oshub.org, looks like a great resource.

Author here! Happy to answer any questions about the implementation.