LEGO Island Decomp: Three Binaries Reproduced Byte for Byte

By Indie Kings | October 29, 2026

Updated October 29, 2026: isledecomp/isle has finished decompiling all three binaries of LEGO Island version 1.1 for English Windows, and its ReproBit verification rebuilds CONFIG.EXE, ISLE.EXE and LEGO1.DLL byte for byte using the original Microsoft Visual C++ 4.2 compiler. The repository has 3,495 stars, 147 forks, 41 contributors and an LGPL-3.0 license, and merged its newest change on October 26, 2026.

Image: a pile of LEGO bricks at a LEGO store, via Wikimedia Commons.

Complete, and verified complete

The README makes a claim that most decompilation projects cannot: CONFIG.EXE, ISLE.EXE and LEGO1.DLL are completely decompiled, and the project's reviewed build reproduces all three retail binaries byte for byte. Not approximately, not function by function, but every byte of the three executables that shipped on the 1997 CD. The only remaining work is naming, documentation and source clarity that does not change the result.

That is a different milestone from the ones usually reported. Most projects track a percentage of matched functions, and a high percentage can hide a lot: unmatched functions, unmatched data, linker differences, and code that compiles to something similar rather than identical. LEGO Island has passed the point where those caveats apply. The three binaries are the proof, and the project publishes two independent reports for each one. The reccmp report compares every recompiled function against the retail binary, and the ReproBit report records a cold rebuild that reproduced all three files exactly.

The distinction between the two reports is worth understanding. Reccmp is a function level comparison: it tells you how closely each reconstructed function matches the original machine code. ReproBit is a build level verification: it starts from a fresh checkout, fetches the original compiler, builds everything, and compares the output byte for byte against the retail files. A project can score well on the first and fail the second if the linker script or the build order is wrong. LEGO Island passes both, and the reports are regenerated by every verified push to master.

This is a different project from the Legoland decompilation covered on this site on October 21. That article concerned a separate repository and a different game; this one is LEGO Island, the 1997 Mindscape title, and the names are similar enough that the confusion is worth heading off.

ReproBit and the original compiler

Reproducing a 1997 binary requires a 1997 toolchain. The project uses Microsoft Visual C++ 4.2, the compiler the game was built with, and ReproBit obtains and checks it as part of setup. The README walks through the process: install Python 3.11 or newer, Git and ReproBit, place the English 1.1 retail files at legobin/CONFIG.EXE, legobin/ISLE.EXE and legobin/LEGO1.DLL, then run rbit setup and rbit verify. On macOS and Linux, Wine is required to run the Windows compiler.

The verification is the interesting part. The verify command builds everything from scratch and checks every byte, then writes the three outputs and a report at .reprobit-state/reports/report.html. GitHub Actions runs the same verification for the continuous release, which publishes the exact binaries, the reccmp progress files, and ReproBit's readable report plus its full JSON record. Each run also compares its reccmp scores and its intervention cost against the master release and prints the delta in the job log, so a regression is visible in the build output rather than discovered later.

Intervention cost is a useful concept. A matching build may require patches, stubs or workarounds to compensate for compiler differences or missing libraries, and each of those is a place where the reconstruction diverges from a clean source tree. Tracking that cost means the project can tell whether a change moved closer to the original or just moved the hacks around. For a project that has already achieved byte equality, the remaining work is largely about reducing interventions and improving readability without breaking the match, which is a subtle and easily lost kind of progress.

There is also an ordinary CMake path for day to day development, and it is explicitly not release certified. That separation is healthy. Contributors can iterate quickly with a normal build, and the authoritative result comes from the slower ReproBit path. A Docker image at ghcr.io/isledecomp/isle packages the environment for Linux and macOS users who do not want to configure Wine by hand, which lowers the barrier for the people most likely to struggle with a 32 bit Windows toolchain.

What is left when the code matches

Naming is the long tail. A function that matches the binary can still be called FUN_0041a2c0, and a structure can still be a block of integers. Turning those into readable code requires understanding what the game does, which is often harder than matching the instructions, because the compiler tells you the shape of the code but not its purpose. The project's development vlog and forums are part of that effort, and the README's list of links reads like a small research community rather than a typical repository.

Documentation has a preservation value that matching alone does not. A byte identical binary proves the reconstruction is correct, but it does not explain how the game's animation system works or why a particular file format exists. The project's stated goal is a workable codebase that can be modified, improved and ported later, and that goal depends on names and comments as much as on instruction equality. The companion project isle-portable takes the codebase to modern platforms, which is only practical if the source is understandable.

The license is LGPL-3.0, which is more restrictive than the CC0 used by some decompilations and less restrictive than the AGPL used by others. For a project whose code is derived from a commercial game, the choice is a compromise: it keeps derivative works open while allowing them to be linked into larger applications under certain conditions. The repository has 41 contributors and only four open issues, a ratio that suggests the hard coordination problems are behind it and the remaining work is distributed and voluntary.

One caveat belongs in any article about a completed decompilation. Completing the code does not make the game freely distributable. The repository does not include the retail binaries, and the build requires the user's own copy of LEGO Island 1.1. The achievement is that the source can reproduce those files, not that it replaces the need to own them. That boundary is what keeps the project on the preservation side of copyright law, and it is stated clearly in the build instructions.

Project card

FAQ

Is the LEGO Island decompilation finished?
The code is complete and all three retail binaries are reproduced byte for byte. Naming and documentation work continues without changing that result.

What is ReproBit?
The project's verification tool. It obtains the original compiler, builds from a fresh checkout, and compares every byte against the retail files.

Do I need the original game?
Yes. The build requires the English 1.1 CONFIG.EXE, ISLE.EXE and LEGO1.DLL from a copy you own.

What is reccmp?
A function level comparison tool that scores how closely each recompiled function matches the original machine code.

Is this the Legoland project covered earlier?
No. It is a separate repository and a different game, despite the similar names.

Can I port it to modern systems?
The decompilation targets 32 bit Windows. The companion isle-portable project is the route for native builds on other platforms.

Bottom Line

Byte for byte reproduction of three executables is the strongest result a decompilation can publish, and LEGO Island did it with the original compiler rather than a modern approximation. The ReproBit verification and the intervention cost tracking are the parts other projects should copy, because they turn a claim into a repeatable check that runs on every push. What remains is the slower work of making the code readable, and that work is what will make the companion port last. Four open issues and 41 contributors describe a project that has crossed the finish line and is now tidying the archive.

Sources

• GitHub isledecomp/isle README, completion status, ReproBit and reccmp reports, build paths and Docker image, accessed October 29, 2026
• GitHub API metadata for isledecomp/isle, stars, forks, contributors, issues and latest commit, accessed October 29, 2026
• Indie Kings coverage of the separate Legoland decompilation from October 21, 2026, used to distinguish the two projects

Related: RecompStore: A Homebrew App Store for Jailbroken PS5 Recomps | We Lurk Below Mod: It Lurks Below Gets a Fan Decompilation and Native Port