_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Show HN: MyraOS â My 32-bit operating system in C and ASM (Hack Club project)
MisterTea wrote 22 hours 39 min ago:
> ... 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?
dvirbt wrote 20 hours 24 min ago:
It was only doing problems when running things like Doom or videos,
so I guess my rendering system isnât optimized enough.
zeusk wrote 22 hours 23 min ago:
Double buffering a 4K 4bpp framebuffer itself is 64mb
LarsDu88 wrote 1 day ago:
Why VGA? I thought that protocol was particularly complicated
dvirbt wrote 20 hours 22 min ago:
No not at all, itâs really simple and high rewarding (in terms of
usage)
Levitating wrote 1 day ago:
How did you handle the graphics stack? Is DOOM playable on just
software rendering?
dvirbt wrote 1 day ago:
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.
danielberdit wrote 1 day ago:
What an amazing project! They donât know what they missed.
joexbayer wrote 1 day ago:
Wow! Looks great! Id suggest checking out [1] it has a lot of hobby
operating systems similar to this one.
HTML [1]: https://oshub.org/
whitehexagon wrote 1 day ago:
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!
dvirbt wrote 1 day ago:
Thank you and good luck!
tomjacobs wrote 1 day ago:
wow, just wow
i did something similar when i was 18. got to the point of filesystem
and mouse driver.
noone_youknow wrote 1 day ago:
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.
trollbridge wrote 1 day ago:
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.
sim7c00 wrote 1 day ago:
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 :()
noone_youknow wrote 7 hours 46 min ago:
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.
noduerme wrote 1 day ago:
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.
dvirbt wrote 1 day ago:
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.
iezepov wrote 1 day ago:
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.
dvirbt wrote 1 day ago:
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
liqilin1567 wrote 1 day ago:
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?
dvirbt wrote 1 day ago:
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?
liqilin1567 wrote 1 day ago:
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
dvirbt wrote 1 day ago:
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.
maxpert wrote 1 day ago:
Would recommend making a good youtube video with demo.
dvirbt wrote 1 day ago:
Yes, you are right.
Do you think I should make the video technical or just a showcase?
iezepov wrote 1 day ago:
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.
saretup wrote 1 day ago:
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.
cbdevidal wrote 1 day ago:
Do both :-)
ethin wrote 1 day ago:
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 :)
dvirbt wrote 1 day ago:
Absolutely, I learned so much from this project!
Do you think I should make a new version in Rust?
vlovich123 wrote 1 day ago:
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)
dvirbt wrote 1 day ago:
Thatâs a great idea, couldâve really improved the overall
project structure
vlovich123 wrote 1 day ago:
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.
drougge wrote 1 day ago:
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)).
vlovich123 wrote 22 hours 50 min ago:
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 :).
scuff3d wrote 1 day ago:
Damn man, this is awesome. This should land you a job damn near
anywhere.
dvirbt wrote 1 day ago:
I really hope so! :)
MarcelOlsz wrote 1 day ago:
Awesome. Should take a look at TempleOS as well.
dvirbt wrote 1 day ago:
Thank, Iâll do!
kbbgl87 wrote 1 day ago:
××× ×× ××ש ×××, ת×ש×× ×××
ktimespi wrote 1 day ago:
This is beautiful.
dvirbt wrote 1 day ago:
Thank you!
userbinator wrote 1 day ago:
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.
qingcharles wrote 1 day ago:
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:
HTML [1]: https://www.computinghistory.org.uk/userdata/images/large/75...
dvirbt wrote 1 day ago:
Wow 8MB of ramâ¦
thatâs really amazing!
Which hobbyOS did you made?
qingcharles wrote 22 hours 54 min ago:
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 :(
dvirbt wrote 1 day ago:
Hey, it was enough for most basic stuff, but only running Doom or
more advanced things would need above that.
userbinator wrote 1 day ago:
Doom was released in 1993. 128MB of RAM wouldn't even fit in the
typical mobo of the time.
HTML [1]: http://www.dosdays.co.uk/topics/1993.php
sedatk wrote 1 day ago:
It only supported 320x200 as resolution at the time though.
dvirbt wrote 1 day ago:
Yes you are right, could be a memory leak somewhere, Iâll need
to take a look at it
ethin wrote 1 day ago:
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.
Imustaskforhelp wrote 1 day ago:
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: [1] Their github page :
HTML [1]: https://copy.sh/v86/
HTML [2]: https://github.com/copy/v86
dvirbt wrote 1 day ago:
Thanks! Iâll look into it
DIR <- back to front page