i would suggest to providing an iso or co-operating / looking into copy.sh which provides a large number of iso files which you can boot/play around with in the browser itself!
I was just today tinkering around with the ibm iso (exploring ibm) and others too, its always fun seeing new operating system!
I would love if you could, as I said, co-operate with copy.sh/v86 team to also include your iso and also provide iso files in github releases if possible
Well done to you both. I'm only a 1/4 way down your useful TODO list after 12 months. I got bogged down in setting up IRQ vector tables on armv8 and took a huge detour to refresh my assembly skills. So I feel some of the journey you have been on. It takes a lot of patience, but can be very rewarding. Congrats!
This is quite amazing. I'm not anything like a serious C coder and haven't tried ASM. I've written "filesystems" in higher level languages (stuff that imposed a directory structure and metadata on what were just bins of data), so I was just looking at parts of your code at random. I think that triple pointer dir_entry_t*** is where my head exploded. Pretty amazing code, you should be very proud.
Thank you so much!
I also made a few years ago an high level filesystem, which helped me during I made this one.
I think the main difference is just that you need to work with drivers here for every disk operation.
This feels like a fresh breath of air after all "I vibe coded this in 4 hours with Claude". Don't get me wrong, vibe coding had its own place, but it feels that projects like this one have become a rarity.
Thank you so much! That’s great to hear :)
I feel like vibe coding projects like this, where the whole idea is to learn, vibe coding only makes it harder
On the other hand, for future employers you might wanna simply showcase the creation. They don’t have all the knowledge to appreciate the technicals or even the time to sit through it.
One of the biggest headaches for me is memory bugs when codebase grows large. So I 'm very interested: is this a headache for you too and how do you deal with this?
You can read about how NASA writes their code, I remember reading an article about it, which includes some great tips with how to avoid these kind of bugs.
And I think also as other commenter said, new languages like Rust really help with avoiding bugs like that.
Yes it is playable, I made an API for window graphics which gives every window the ability to render stuff on it’s surface.
Then I used DoomGeneric to port my graphics API to Doom.
wrongfully assuming 128MB for the whole OS was enough
If I were you I'd investigate why it needs so much. Keep in mind how much functionality older OSs had, and how much computing power they needed. Always good to see more OS projects nonetheless, but always remember that efficiency is important.
I had to just go find the details for the original 386 Unix server [1] I was running ~1995 because I thought it was running just fine on 8MB RAM, running an EFnet IRC node, FTP, MUDs and some early web apps. And... yep, 2 x 4MB SIMMs. Wild times. A single photo from my phone is three times that size.
(I later took that PC home and used it as the test machine for my own hobby OS, which had to run from a 1.44MB floppy because there was no other sane way to transfer the dev images from my desktop)
I named it Tinkerbell for some reason. It was kinda neat, it would boot directly into a windowed GUI. It lived at tinkerbell.org back in the 90s, but it seems it got missed by archive.org :(
Eh, I tend to do the same (significantly over-estimate RAM requirements) since it's hard to know just how much RAM you'll need to begin with. Though usually for something like the stack I start with 256-512K.
This is really great work! Always impressed to see hobby OS projects that get this far, well done.
That said, I’m once again reminded that we sorely need some updated resources for aspiring OS developers in 2025. Targeting 32-bit x86 and legacy devices that haven’t been “the norm” for decades suggests to me a heavy influence from resources like the osdev wiki which, while occasionally useful, are increasingly outdated in the modern world and lead to many questionable choices early on.
I have come to believe (through multiple iterations of my own OS projects) that there’s more value in largely ignoring resources such as osdev and focusing instead on first-principles design, correct layering, and building based on modern platforms (be that x86_64 or something else) and ignoring legacy devices like the PIT and PS2 etc.
I just wish we had good introductory documentation resources to reflect that, and that outdated resources weren’t overwhelmingly surfaced by search engines and now AI “summaries”.
None of the above is intended to take away from OPs achievement, which is fantastic, or from the work done over the years by the osdev community, who I’m sure largely do the best they can with what they have.
Yes. This stuff needs to be retargeted at x86_64 (on EFI, too) and ARM.
Of course, also supporting i386 with legacy BIOS is OK, but it doesn't really get into the meat of what computers are doing now when you power them on.
trying to write about x86_64 (uefi, aslr, message signaled interrupts, lapic, acpi, iommu etc. etc.) and how to do platform init etc. to get ready for OS to execute. its a mess. its also hard to find someone who can proof read it and give meaningful feedback. (not many ppl enjoy this stuff i suppose :()
It is hard, and things are messy in some areas. But in my experience it’s less hard than writing a lot of the existing documentation would’ve been (because good datasheets and documentation are more available now) and actually less messy (with some exceptions) than things were back in the days of the legacy hardware most existing wikis etc focus on.
Finding people with the knowledge, time and willingness to proof-read is also hard - but surely not insurmountable if we collectively decide it’s an endeavour we want to pursue.
I did this (worked on an OS) from 2019-2022 or so, during college. Didn't get to user mode sadly. Did it in Rust because back then Rust was what I was really into. It was really fun! :) OS dev has always been fun/interesting :)
That’s your call to make but I think it’ll be easier to write tests for the trickier parts and avoid the memory safety issues you flagged as being your biggest annoyance by isolating into unsafe that’s better unit tested (+ maybe cover with Miri to double check the unsafe code is still sound)
I’ll flag one thing which is that the page table stuff mentioned is unlikely something rust can protect you against - if you set up the wrong memory mapping that’s a higher level logic bug that would make rust unsound and result in weird failures. Rust can only protect you within the bounds of the memory model it defines for its abstract machine.
There's probably a lot of other memory bugs though. The first thing I looked at was the shell, and almost immediately I spotted an out of bounds write (input[n] = '\0' where n could be sizeof(input)).
For sure. I’m highlighting the nastier parts of the system that Rust can’t help with. I love Rust but it’s important to understand its limitations, particularly for something like OS development. There’s a similar way to make Rust unsafe using 100% safe Rust where you poke /proc/self/mem to violate memory safety using safe IO :).
Hey, what an amazing project, bravo!
i would suggest to providing an iso or co-operating / looking into copy.sh which provides a large number of iso files which you can boot/play around with in the browser itself!
I was just today tinkering around with the ibm iso (exploring ibm) and others too, its always fun seeing new operating system!
I would love if you could, as I said, co-operate with copy.sh/v86 team to also include your iso and also provide iso files in github releases if possible
Source: https://copy.sh/v86/ Their github page : https://github.com/copy/v86
Thanks! I’ll look into it
Well done to you both. I'm only a 1/4 way down your useful TODO list after 12 months. I got bogged down in setting up IRQ vector tables on armv8 and took a huge detour to refresh my assembly skills. So I feel some of the journey you have been on. It takes a lot of patience, but can be very rewarding. Congrats!
Thank you and good luck!
Damn man, this is awesome. This should land you a job damn near anywhere.
I really hope so! :)
This is quite amazing. I'm not anything like a serious C coder and haven't tried ASM. I've written "filesystems" in higher level languages (stuff that imposed a directory structure and metadata on what were just bins of data), so I was just looking at parts of your code at random. I think that triple pointer dir_entry_t*** is where my head exploded. Pretty amazing code, you should be very proud.
Thank you so much! I also made a few years ago an high level filesystem, which helped me during I made this one. I think the main difference is just that you need to work with drivers here for every disk operation.
This feels like a fresh breath of air after all "I vibe coded this in 4 hours with Claude". Don't get me wrong, vibe coding had its own place, but it feels that projects like this one have become a rarity.
Thank you so much! That’s great to hear :) I feel like vibe coding projects like this, where the whole idea is to learn, vibe coding only makes it harder
Wow! Looks great! Id suggest checking out https://oshub.org/ it has a lot of hobby operating systems similar to this one.
Would recommend making a good youtube video with demo.
Yes, you are right. Do you think I should make the video technical or just a showcase?
I'd go for something more technical, it feels like your target audience are hackers and not people shopping for an OS.
But as always, it's your project done for yourself, so whatever feels like more fun recording.
On the other hand, for future employers you might wanna simply showcase the creation. They don’t have all the knowledge to appreciate the technicals or even the time to sit through it.
Do both :-)
One of the biggest headaches for me is memory bugs when codebase grows large. So I 'm very interested: is this a headache for you too and how do you deal with this?
Yes, I think most of the time working on the project was working ob fixing memory bugs. GDB did a great job for me, have you tried to use it?
Yeah, it's kind of annoying to fix these bugs for me, even though GDB is a great debugging tool.
I always wonder if there are any techniques to avoid these kind of bugs in huge projects like OSes and browsers, otherwise it can be a nightmare
You can read about how NASA writes their code, I remember reading an article about it, which includes some great tips with how to avoid these kind of bugs. And I think also as other commenter said, new languages like Rust really help with avoiding bugs like that.
Pretty interesting, starred the repo for further checking at home, congrats on the project
How did you handle the graphics stack? Is DOOM playable on just software rendering?
Yes it is playable, I made an API for window graphics which gives every window the ability to render stuff on it’s surface. Then I used DoomGeneric to port my graphics API to Doom.
> ... and the Qemu not having enough (wrongfully assuming 128MB for the whole OS was enough).
Interesting that 128 MB was not enough. What did you do to find this issue and how are you measuring memory usage?
It was only doing problems when running things like Doom or videos, so I guess my rendering system isn’t optimized enough.
Double buffering a 4K 4bpp framebuffer itself is 64mb
wrongfully assuming 128MB for the whole OS was enough
If I were you I'd investigate why it needs so much. Keep in mind how much functionality older OSs had, and how much computing power they needed. Always good to see more OS projects nonetheless, but always remember that efficiency is important.
I had to just go find the details for the original 386 Unix server [1] I was running ~1995 because I thought it was running just fine on 8MB RAM, running an EFnet IRC node, FTP, MUDs and some early web apps. And... yep, 2 x 4MB SIMMs. Wild times. A single photo from my phone is three times that size.
(I later took that PC home and used it as the test machine for my own hobby OS, which had to run from a 1.44MB floppy because there was no other sane way to transfer the dev images from my desktop)
[1] One of these: https://www.computinghistory.org.uk/userdata/images/large/75...
Wow 8MB of ram… that’s really amazing! Which hobbyOS did you made?
I named it Tinkerbell for some reason. It was kinda neat, it would boot directly into a windowed GUI. It lived at tinkerbell.org back in the 90s, but it seems it got missed by archive.org :(
Hey, it was enough for most basic stuff, but only running Doom or more advanced things would need above that.
Doom was released in 1993. 128MB of RAM wouldn't even fit in the typical mobo of the time.
http://www.dosdays.co.uk/topics/1993.php
Yes you are right, could be a memory leak somewhere, I’ll need to take a look at it
It only supported 320x200 as resolution at the time though.
Eh, I tend to do the same (significantly over-estimate RAM requirements) since it's hard to know just how much RAM you'll need to begin with. Though usually for something like the stack I start with 256-512K.
Why VGA? I thought that protocol was particularly complicated
No not at all, it’s really simple and high rewarding (in terms of usage)
What an amazing project! They don’t know what they missed.
This is really great work! Always impressed to see hobby OS projects that get this far, well done.
That said, I’m once again reminded that we sorely need some updated resources for aspiring OS developers in 2025. Targeting 32-bit x86 and legacy devices that haven’t been “the norm” for decades suggests to me a heavy influence from resources like the osdev wiki which, while occasionally useful, are increasingly outdated in the modern world and lead to many questionable choices early on.
I have come to believe (through multiple iterations of my own OS projects) that there’s more value in largely ignoring resources such as osdev and focusing instead on first-principles design, correct layering, and building based on modern platforms (be that x86_64 or something else) and ignoring legacy devices like the PIT and PS2 etc.
I just wish we had good introductory documentation resources to reflect that, and that outdated resources weren’t overwhelmingly surfaced by search engines and now AI “summaries”.
None of the above is intended to take away from OPs achievement, which is fantastic, or from the work done over the years by the osdev community, who I’m sure largely do the best they can with what they have.
Yes. This stuff needs to be retargeted at x86_64 (on EFI, too) and ARM.
Of course, also supporting i386 with legacy BIOS is OK, but it doesn't really get into the meat of what computers are doing now when you power them on.
trying to write about x86_64 (uefi, aslr, message signaled interrupts, lapic, acpi, iommu etc. etc.) and how to do platform init etc. to get ready for OS to execute. its a mess. its also hard to find someone who can proof read it and give meaningful feedback. (not many ppl enjoy this stuff i suppose :()
It is hard, and things are messy in some areas. But in my experience it’s less hard than writing a lot of the existing documentation would’ve been (because good datasheets and documentation are more available now) and actually less messy (with some exceptions) than things were back in the days of the legacy hardware most existing wikis etc focus on.
Finding people with the knowledge, time and willingness to proof-read is also hard - but surely not insurmountable if we collectively decide it’s an endeavour we want to pursue.
wow, just wow
i did something similar when i was 18. got to the point of filesystem and mouse driver.
This is beautiful.
Thank you!
I did this (worked on an OS) from 2019-2022 or so, during college. Didn't get to user mode sadly. Did it in Rust because back then Rust was what I was really into. It was really fun! :) OS dev has always been fun/interesting :)
Absolutely, I learned so much from this project! Do you think I should make a new version in Rust?
That’s your call to make but I think it’ll be easier to write tests for the trickier parts and avoid the memory safety issues you flagged as being your biggest annoyance by isolating into unsafe that’s better unit tested (+ maybe cover with Miri to double check the unsafe code is still sound)
That’s a great idea, could’ve really improved the overall project structure
I’ll flag one thing which is that the page table stuff mentioned is unlikely something rust can protect you against - if you set up the wrong memory mapping that’s a higher level logic bug that would make rust unsound and result in weird failures. Rust can only protect you within the bounds of the memory model it defines for its abstract machine.
There's probably a lot of other memory bugs though. The first thing I looked at was the shell, and almost immediately I spotted an out of bounds write (input[n] = '\0' where n could be sizeof(input)).
For sure. I’m highlighting the nastier parts of the system that Rust can’t help with. I love Rust but it’s important to understand its limitations, particularly for something like OS development. There’s a similar way to make Rust unsafe using 100% safe Rust where you poke /proc/self/mem to violate memory safety using safe IO :).
מגניב ממש אחי, תמשיך ככה
Awesome. Should take a look at TempleOS as well.
Thank, I’ll do!