It's good to have support for real networking hardware, but consider virtio-net as well. A lot of VMs support it and it's more streamlined. 32-bit x86, bios boot means doing a lot of things for compatibility with systems that were old enough to drink before you were born... skipping to simplified virtualized interfaces wherever possible makes a lot of sense; even if your OS can run in 16 MB of ram, you're probably not going to run it on a 486 with 16 MB of RAM and a real parallel IDE drive ... at least not at first. You can always come back and make that work if you want... deferring tricky things until later so you can work on the fun stuff keeps you having fun and engaged with your project.
Also, consider trying to get your OS running on v86. It's fun having your hobby OS work in a browser. The biggest limitations I've run into are 32-bit x86 only, single processor only; but those might not be that big of a deal... looks like your OS is also 32-bit x86 only, and I don't see anything about SMP in your project. If there's anything missing from v86 that you depend on, I've had a wonderful experience with submitting PRs; copy often reworks my patches to be much better before applying them, which I always appreciate rather than a back and forth attempt to get me to make it better :) I've also seen copy (and others) take reported issues and fix them, if you've got a problem that you can't write a patch to resolve.
> Real hardware support is still a work in progress.
I ran into a fair amount of issues with 16-bit code; qemu doesn't check segmentation limits but real hardware does. Real hardware would crash, but it worked fine in qemu. My kernel is multiboot and I use 3rd party bootloaders, but I do SMP, on x86, that involves starting the Application Processors in 16-bit real mode and then moving them into 32-bit modes, but you have to do the segmentation dance correctly until you get there; doesn't help when qemu just lets you do whatever. :P
PS 12 hour days are a lot; hope you're getting all your other stuff done :P
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.
Everything in that account has appeared in the last 6mo. Very unnatural commit activity, and clearly contradicts the claim that this is their first OS project. Is linked to a faceless YT channel.
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!
> The commit activity might look unusual because I worked in very intense 12h/day sprints over 14 days.
That's a weird way to put it.
The commit activity looks unusual because it's a completed project whose files were individually committed in alphabetical order. There's no development history.
How did you decide between assembler and C for various parts of the kernel? Some choices are very different from what I would have picked, so I'm curious about your thought process.
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!
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.
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?
No offense, and God forbid I sound like a "fanboy" but I'd highly recommend using Rust or Zig instead of c for the rest of your project. I appreciate C and assembly and am pretty "conservative" in my choices of PL but both rust and zig, despite having their own disadvantages, and also a slightly unpleasant community based on where you come from, are actually plain better than C in every respect. The abstractions are 0 cost and often pretty "transparent" so you know exactly what's happening behind the scenes.
I disagree. Rust and Zig bring millions of lines of code of dependencies and complexity in their toolchains. We can hope for a relatively simple Zig compiler someday, but probably not Rust. If you care about portability (now and in the future), C is a much better choice.
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.
> RTL8139 network driver (WIP)
It's good to have support for real networking hardware, but consider virtio-net as well. A lot of VMs support it and it's more streamlined. 32-bit x86, bios boot means doing a lot of things for compatibility with systems that were old enough to drink before you were born... skipping to simplified virtualized interfaces wherever possible makes a lot of sense; even if your OS can run in 16 MB of ram, you're probably not going to run it on a 486 with 16 MB of RAM and a real parallel IDE drive ... at least not at first. You can always come back and make that work if you want... deferring tricky things until later so you can work on the fun stuff keeps you having fun and engaged with your project.
Also, consider trying to get your OS running on v86. It's fun having your hobby OS work in a browser. The biggest limitations I've run into are 32-bit x86 only, single processor only; but those might not be that big of a deal... looks like your OS is also 32-bit x86 only, and I don't see anything about SMP in your project. If there's anything missing from v86 that you depend on, I've had a wonderful experience with submitting PRs; copy often reworks my patches to be much better before applying them, which I always appreciate rather than a back and forth attempt to get me to make it better :) I've also seen copy (and others) take reported issues and fix them, if you've got a problem that you can't write a patch to resolve.
> Real hardware support is still a work in progress.
I ran into a fair amount of issues with 16-bit code; qemu doesn't check segmentation limits but real hardware does. Real hardware would crash, but it worked fine in qemu. My kernel is multiboot and I use 3rd party bootloaders, but I do SMP, on x86, that involves starting the Application Processors in 16-bit real mode and then moving them into 32-bit modes, but you have to do the segmentation dance correctly until you get there; doesn't help when qemu just lets you do whatever. :P
PS 12 hour days are a lot; hope you're getting all your other stuff done :P
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 :)
Very cool! Would suggest https://oshub.org/explore if youre interested in hobby operating systems.
Thanks! I'll definitely check out oshub.org, looks like a great resource.
Good to see more hobby OS projects. I'm almost due to start another round of learning this stuff.
What have been the most helpful reference materials so far?
What's the most memorable challenge you overcame?
What's the coolest or most surprising thing you learned?
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?
AI Account.
Everything in that account has appeared in the last 6mo. Very unnatural commit activity, and clearly contradicts the claim that this is their first OS project. Is linked to a faceless YT channel.
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!
> The commit activity might look unusual because I worked in very intense 12h/day sprints over 14 days.
That's a weird way to put it.
The commit activity looks unusual because it's a completed project whose files were individually committed in alphabetical order. There's no development history.
I worked on AurionOS locally, and pushed it to GitHub when it was finally ready.
Author here! Happy to answer any questions about the implementation.
How did you decide between assembler and C for various parts of the kernel? Some choices are very different from what I would have picked, so I'm curious about your thought process.
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!
How much was built with the AI? An OS is definitely a fun project and the classic x86 is a pretty good platform for that!
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.
That's an ambitious project!
What was your inspiration for the filesystem?
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?
I have no particular expertise there, I'm afraid!
No problem at all, thanks anyway!
https://github.com/Luka12-dev
sigh
What's the point of your comment?
probably to highlight how this isn't genuine account?
No offense, and God forbid I sound like a "fanboy" but I'd highly recommend using Rust or Zig instead of c for the rest of your project. I appreciate C and assembly and am pretty "conservative" in my choices of PL but both rust and zig, despite having their own disadvantages, and also a slightly unpleasant community based on where you come from, are actually plain better than C in every respect. The abstractions are 0 cost and often pretty "transparent" so you know exactly what's happening behind the scenes.
I disagree. Rust and Zig bring millions of lines of code of dependencies and complexity in their toolchains. We can hope for a relatively simple Zig compiler someday, but probably not Rust. If you care about portability (now and in the future), C is a much better choice.
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.
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!