Hello friends!

Welcome to another Sloth Bytes issue. I hope you’re having a good week!

If you’re new, or not yet a subscriber, or just plain missed it, here are some of our recent editions:

🦥 Tailwind has a sugar daddy now

🦥 Git Worktrees for Dummies

🦥 GPT-6 Astra and Claude Fable 5.1

This guide distills 10 AI strategies from industry leaders that are transforming marketing.

Outpace your competitors by mastering AI.

Get Your Free Guide

AI can draft the PRD and prototype the idea. Jira Product Discovery helps teams decide whether it belongs on the roadmap. Bring feedback and ideas together, prioritize as a team, and keep your roadmap connected to delivery in Jira.

Get Started for Free.

For this newsletter, I’m going to nerd out a bit. It’s probably not something most of you use every day, but it’ll definitely be interesting and fun.

Recently, I was rewatching a video from MattKC (shoutout Matt) about how programmers ported Sonic Unleashed to PC:

Fans have also brought Ocarina of Time and Majora’s Mask to PC through projects like Ship of Harkinian and Zelda 64: Recompiled. With improvements like widescreen support, modern controls, and smoother frame rates, too.

Which is cool, but also… how?

They don’t have the original development project. You can’t just rename an N64 game zelda.exe and expect Windows to figure it out.

Some projects use decompilation. Others, like Sonic’s port, use static recompilation.

Today we’ll cover decompilation.

Decompilation is the process of rebuilding readable, high-level code from a compiled program.

“High-level” in this case actually means languages like C.

Yeah… decompilation has you going in DEEP. We’re talking assembly and binary itself.

Quick reminder of how code can be compiled for a computer or console:

With decompilation, we work backwards. A decompiler studies the compiled code and tries to rebuild something people can read:

It’s one part of reverse engineering, which means studying an existing program to understand how it works.

To do this, you’d usually use a tool like Ghidra.

Fun fact: Ghidra is maintained by the NSA. Yes, that NSA.

Anyways, notice how I said rebuilding.

When you decompile something, you aren’t guaranteed to get the original source code.

First, it reads the instructions. For machine-code programs, it needs to know which type of CPU the code was built for.

For you new-gen vibe coders, CPU type actually matters here. Windows PCs can use x86-64 or ARM64, while Apple silicon Macs use ARM64.

What matters is what the program was built for, not the computer you’re analyzing it on.

Different CPU types encode instructions differently, so the tool needs to read the right instruction set.

A disassembler shows those machine instructions as assembly. The decompiler analyzes the instructions to rebuild code you can read.

The decompiler will follow the program’s paths and values. It’ll figure things out like:

Then it rebuilds familiar code. Patterns of checks and jumps can become if statements and loops. Several low-level operations can become one expression.

Let’s do a simple example and hurt your eyeballs with some delicious assembly.

Here, edi and esi hold the two inputs, and eax holds the return value.

A decompiler could turn that into something like this, with placeholder names. This is an example, not an actual decompiler export:

Much easier to read than assembly, right?

We can see the comparison and subtraction, but what are value1 and value2?

To figure that out, you follow the code that calls this function and confirm that it passes in the player’s coin count and the item’s price.

Now you can give the function and its inputs useful names:

With 150 coins and a price of 100, it returns 50. With 80 coins and the same price, it returns 80. Sounds like this function is meant to calculate the remaining balance.

This only calculates a balance. The shop’s other code still has to approve the purchase and give you the item.

Congrats, you just decomplied something. I’m proud of you.

That example is the common workflow in decompilation projects:

Remember though: in this example, those names come from your investigation, not the developer’s original source.

Because compilation can lose information.

Let me give you a very simple example. These code snippets can produce the same machine instructions:

Both add one, but which one did the original game use?

When the instructions are identical, they can’t tell you which version was originally written.

The game can behave exactly the same either way. It just means you can’t prove which version the developer wrote.

Comments and formatting usually disappear too, so unfortunately we often miss out on the developer’s original suffering.

Some builds actually do preserve extra details for debugging, but others leave fewer clues.

Compiler optimizations can also make the original code harder to recover.

To make a program faster or smaller, the compiler may remove unused code or combine several operations.

Also, readable output isn’t automatically correct or ready to compile. A decompiler can get a type wrong or fail to rebuild part of the program properly.

Decompilers are meant to guide your investigation, but you still have to check that the rebuilt code matches what the program actually does.

The good news: no.

Not every program compiles straight to machine code.

Some compile to bytecode or intermediate code first, which a runtime like .NET then runs.

For example, many C# programs contain .NET intermediate code plus metadata, details about things like classes, methods, and types.

Those details give a decompiler clues that may be missing from an optimized machine-code program. There’s also obfuscation, which is deliberately changing code to make it harder to understand.

A tool might replace useful names with meaningless ones, but it’ll still keep the program’s behavior.

The tool you use depends on the program you’re inspecting:

Ghidra supports many machine-code formats, while ILSpy specializes in .NET decompilation. There isn’t one universal tool that perfectly reverses every program.

A famous example is the Ocarina of Time decompilation project.

Projects like this combine tools with people studying and rebuilding code, often function by function.

Some aim for matching decompilation: compiling the rebuilt source with the right tools and settings produces the same machine code as the original build.

That’s a better check than “Link walks around and hasn’t glitched. Seems fine.”

Matching is a specific goal. You don’t need identical machine code just to understand a function.

Turning that work into a PC port is another job. Ship of Harkinian uses rebuilt Zelda code alongside support for modern graphics, controllers, audio, and other services.

It also needs the game’s assets, such as models and music, supplied through a supported original game file.

Understanding the code helps make a port possible. It doesn’t mean every part of the port comes from a decompiler.

This distinction actually does matter.

Recompilation means compiling again. Sonic’s Unleashed Recompiled uses static recompilation: tools translate its compiled instructions ahead of time, generating code that can be compiled for PC.

That generated code can follow the original console’s instructions without recovering the original programmer’s names or code structure.

These techniques can overlap.

And of course, let’s not forget about emulation.

Emulation means providing the behavior of another system so its programs can run.

Some emulators use JIT, or just-in-time compilation, which translates code while the program runs. Dolphin does this. They’re all related tools, but for different jobs.

Here’s a fun video comparing recompilation and emulation:

Let me know if you want me to cover emulation too.

Absolutely.

Maybe a library behaves differently from its docs. Decompilation can help you inspect what it actually does when the source isn’t available. Visual Studio supports this for external .NET code.

It can also help people study older software when the original source is missing. Game projects such as Ocarina of Time are examples of that larger idea.

You don’t need to rebuild an entire game. Sometimes the useful result is understanding one annoying function.

The main thing to remember: decompilation helps you understand a compiled program. It doesn’t promise to bring back the developer’s original project.

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake (which wouldn’t be surprising) or you have any questions, feel free to comment below or reply to the email!

See you all next week.

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.