Wow, you did it yourself?! This is just wow, as a C/C++ developer I know how to create an OS, but at most I could come up with an idea, but writing all this myself, I have no words.

I had some help for the browser engine

I work on various github projects: 1) Header-only ASCII font renderer for embedded/SDL/terminal https://github.com/Ferki-git-creator/ascii-render

2) TurboStitchGIF: A fast, header-only C GIF decoder without dynamic allocations, ideal for embedded systems and cross-platform projects. https://github.com/Ferki-git-creator/TurboStitchGIF-HeaderOn...

So it's very strange, and sometimes it reminds Gemini that he also doesn't know his version.

Let's stop anthropomorphizing software.

Dude, this is a really cool thing. I dreamed of creating this myself once. Now that you've done it, I can be happy because I always wanted to share the code and not hear the intrusive words "Don't self-promote."

I liked it, but I think they should add the ability to download music to .waw/.mp3 and add a local version to github (your wish).

Thanks! It's open source[0], your contribution would be very welcome :)

[0]: https://github.com/stagas/sound

I did it for nostalgia, I wanted to do it the way they used to do it, for example, such README files are in SDL and Linux.

Totally fair — this pattern can be confusing at first glance. The main motivation is ease of integration: no need to manage extra .c files, no build system tweaks, just drop in one file and go. It’s especially useful for embedded systems, scripts, and small projects where build friction matters. That said, I agree that for larger teams or long-term projects, the classic .h + .c split can be clearer — that’s why the implementation can easily be separated if needed. Appreciate the feedback!

Great question! It works the same way as stb-style libs: you only #define GIF_IMPLEMENTATION in one .c file (one translation unit). In all other files, you just #include "gif.h" without the define. The header uses #ifdef GIF_IMPLEMENTATION to include implementation code only once. So no linker errors — everything compiles cleanly as long as that rule is followed. I’ll make this clearer in the README too, thanks!

Exactly! That flexibility was one of my goals. Making integration smooth for both small embedded projects and larger codebases with unity builds — glad to hear it resonates.

I first encountered the idea relatively recently with Clay [1] and I have been a fan since. Once you get past the “huh, weird” stage it has a lot of benefits!

1: https://github.com/nicbarker/clay

Thanks! Yes, stb-style header-only libs were definitely an inspiration. I know some devs find the approach confusing, especially with linker errors if *_IMPLEMENTATION isn't handled correctly. I tried to keep it simple and clearly documented, but feedback like this helps improve it.