A developer personal journal

Creating a compiler for retro, a nice experience

It feels like ages since I last wrote something. A lot has changed in my life, yet I feel very refreshed writing here again.

I don’t want to turn this into a dramatic story, so I’ll get straight to the point. Since 2025, I’ve been working on a new and exciting project—something I’ve wanted to build my whole life: a compiler.

Sometime last year, I started experimenting just for fun with an AI agent (Jules) using its free tier. I built a plugin for learning Neovim (nvim), which was an interesting experience on its own.

After that, I got that familiar itch—you can use these tools to build the side projects you’ve always wanted to try, or at least sketch your ideas. The Neovim plugin wasn’t a hit in terms of downloads, but the idea came to life without me having to deal with the UI parts I don’t enjoy. https://github.com/melkyr/learn-vim

Then I tried something more experimental, just for fun—building a CMS using Go and HTMX to render websites like static pages (an old idea I’ve always liked). I love tools like that; they remind me of the “good old days.” I’ve spent a lot of time chasing that feeling—when static HTML sites were common, and even though limited RAM made things slower, it didn’t really matter. After building and modifying this shell CMS, I started thinking: “This might be the time to try my silly idea.”

In November 2025, I committed to creating a compiler as a personal goal. I’m not interested in creating a new language (at least not right now); I wanted the experience of building that small application that produces another application—the kind of thing that puts food on my table every day.

Then came a lot of head-scratching: which language should I “remake” a compiler for? Which one would be useful—or at least fun? With limited time, I needed a project that wouldn’t feel like a race or a burden.

I didn’t want to build yet another C# or Java compiler and compete in a crowded space. I wanted something I could work on quietly—something no one expects, and that could emerge from the shadows as an “unnecessary” tool.

The thing is, as engineers, we often dream about building something just for the sake of it—no clear goal, just curiosity and fun. And there I was, still trying to rationalize the pros and cons of targeting different platforms.

Then it hit me: I don’t want to build a tool for people—I want to build a tool for fun. So I decided to remove that pressure and pick something I genuinely liked. A retro platform. No active support, documentation already “finished,” and the outcome doesn’t matter anymore—it already belongs to the past. I chose Windows 98 as my target platform.

The next answer came immediately. After locking myself into Win98, I could quickly check what had or hadn’t been built for it. I came across an article about making Rust (a modern language) work on Windows 95: https://seri.tools/blog/announcing-rust9x/. Even now, they’ve managed to make a toolchain that outputs Rust apps for Win9x—that’s impressive.

But for my compiler, I wanted something different. I wanted a retro compiler with era-accurate limitations. That meant no LLVM, no ANTLR, and operating under tight resource constraints—targeting machines with 16MB or 32MB of RAM.

With those constraints, it became clear I needed a low-level language, giving users full control and responsibility for optimization.

With Rust already “working” thanks to the Rust9x project, I thought: “Let’s try Zig.” A silly idea at first glance—if you look at Zig’s feature set, replicating that in the Windows 98 era feels like something only someone from the future could do.

With Zig as the target language and Windows 98 as the platform, the next big question was: how? If I wanted time accuracy and minimal dependencies, I had to rely heavily on native OS features—and if you lived through that era, you know Windows 98 wasn’t exactly reliable.

Big decisions had to be made: how to build it, what dependencies to allow, and how much complexity to tolerate. The project started, as many do, with a developer thinking too much.

Then I remembered how portable software used to be—just copy an .exe file and run it. No dependencies, no setup. That became my goal.

I decided the compiler had to be buildable using tools available on the target OS itself. If Windows 98 is the minimum, then everything must be based on what was available at the time—again, era-accurate.

That left me with options like Fortran, C++, C, Delphi, and BASIC (yes, really). There was also some Python for Win9x, but I discarded it due to resource constraints. I had to consider limitations like the 1MB stack on Windows 98. Delphi was proprietary, which I wanted to avoid. C was a strong option but very manual. BASIC… not that much torture. So I committed to another kind of pain: C++—specifically C++98.

As for execution, that’s where Jules came in. I guided it with structured plans while designing everything as if I had unlimited time. A classic waterfall approach: tasks building on top of each other toward the final goal—a bootstrap compiler.

Yes, AI has its issues—hallucinations, weak context handling, inconsistent quality. I’ve experienced all of them. But I decided to use it for what it’s good at: generating the bootstrap compiler—the basic building block, a one-time-use tool. A perfect use case for AI.

So the journey began. Initially, I planned to output assembly for maximum performance, but later I switched to generating C89 for portability and easier debugging.

I also had to give up many rich language features due to the platform’s limitations. If I support them in the future, it will be in the self-hosted compiler—not the bootstrap version. Still, I pushed to make the first step as capable as possible.

So how did it go?

Well… six long months later: https://github.com/melkyr/znineeight

The bootstrap compiler is alive. It works. That’s everything I want to say for now—more details coming in the next days and weeks.

Tags: programming, general, retro, win98