# isledecomp/isle: the LEGO Island decompilation that rebuilds the 1997 binaries byte for byte

> A complete decompilation of LEGO Island 1.1 English, verified against the retail executables with the original Visual C++ 4.2 toolchain. Useful if you want source that matches the 1997 machine code, not a playable modern port.

**isledecomp/isle** — A decompilation of LEGO Island (1997)

- Repository: https://github.com/isledecomp/isle
- Stars: 3,477 · Forks: 146
- Language: C++
- License: LGPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/isledecomp-isle

## What isledecomp/isle actually solves, and who it is for

LEGO Island shipped in 1997 as a 32-bit Windows game, and for most of the following decades its behaviour existed only as compiled machine code. isledecomp/isle is a complete decompilation of LEGO Island Version 1.1, English, with the stated aim of matching recompiled instructions to the original machine code as closely as possible. The README is explicit that the goal is a workable codebase that can be modified, improved, and ported to other platforms later on. The decompilation itself is not that port.

The audience follows from that. This is for people who want to read, annotate or extend the original game logic at the source level, and for people whose work depends on the retail binaries being reproducible. The README notes that CONFIG.EXE, ISLE.EXE and LEGO1.DLL are completely decompiled and that work continues on naming, documentation, and source clarity without changing those results. If your interest is running the game rather than understanding it, this repository is the wrong entry point, and the README says so in a note near the top.

## How the decompilation is verified: reccmp, ReproBit and the three binaries

The mechanism here is unusual and worth understanding before you clone anything. There are two separate verification systems. reccmp produces accuracy reports that compare every recompiled function with the retail binary, published as per-binary progress pages for CONFIG.EXE, ISLE.EXE and LEGO1.DLL. ReproBit is the stricter one: the project's reviewed build uses the original Microsoft Visual C++ 4.2 toolchain and reproduces all three retail binaries byte for byte. The README describes a ReproBit report that records the cold rebuild which reproduced all three binaries and links its full report.json record, and both report families are regenerated by every verified push to master.

That split matters because it defines what counts as a contribution. The ordinary CMake build is described as useful for day-to-day development, but its outputs are not release-certified. Only ReproBit certifies byte-for-byte release outputs, and the README says the byte-for-byte verification is the authoritative result for contributions and releases. The continuous release follows the same path: GitHub Actions runs the same verification, and each run compares its reccmp scores and its ReproBit intervention cost with the master release and prints the deltas in the job log. If you are trying to decide how much to trust a local build, that comparison against master is the signal the project itself treats as meaningful.

## Reproducing the retail binaries: rbit setup and rbit verify

The exact-reproduction path starts from a fresh checkout. You need Python 3.11 or newer, Git, and ReproBit installed; macOS and Linux also need Wine. Your English 1.1 retail files go at legobin/CONFIG.EXE, legobin/ISLE.EXE and legobin/LEGO1.DLL. From the repository root, the README gives two commands:

```console
rbit setup .
rbit verify .
```

setup obtains and checks the original compiler. verify builds everything from scratch and checks every byte against the retail files. A successful run writes build/CONFIG.EXE, build/ISLE.EXE and build/LEGO1.DLL, and the result is reviewed by opening .reprobit-state/reports/report.html. During editing, the README suggests rbit build . for faster incremental builds, with rbit verify . run before sharing a result. Note the boundary: verify is the command that means something, build is a convenience.

The repository layout supports this: reprobit.toml and a reprobit/ directory sit at the top level alongside reccmp-project.yml, and there is a docker/ directory for environments that need one. The README does not document rollback or how to recover from a partially completed setup, so treat the fresh-checkout instruction literally if a run fails.

## The ordinary CMake build with Visual C++ 4.2

For day-to-day work the README documents a second path using CMake and Microsoft Visual C++ 4.2, which it calls the original game's compiler and the most representative choice. You need Visual C++ 4.2, which the README notes can be found on many abandonware sites with an installer that can be a little iffy on modern versions of Windows, and for convenience points at a portable version. CMake is the other prerequisite, often bundled with the Desktop development with C++ workload in newer Visual Studio versions.

The sequence is a Command Prompt, VCVARS32.BAT x86 from Visual C++ 4.2 to populate the path and environment variables, a build folder, and a configure step:

```console
cmake <path-to-source> -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RelWithDebInfo
```

Replace <path-to-source> with the source repository, which can be .. if the build folder is inside it. RelWithDebInfo is recommended because it produces debug symbols useful for further decompilation work; Release is acceptable if you do not need them. Debug builds compile but are not recommended, because the retail binaries were compiled as Release. Then build with nmake or cmake --build <build-folder>.

The constraints the README calls out are concrete and will bite. Visual C++ 4.2 has issues with paths containing spaces, so neither CMake, the repository, nor the compiler should live in a path with spaces. Long file paths may be truncated by make, producing File not found errors. NMake Makefiles is the most recommended generator because it is immediately compatible with Visual C++ 4.2; Ninja builds faster but, due to limitations in Visual C++ 4.2, can only produce Release builds because debug symbols cannot be generated that way.

## Where isledecomp/isle is the wrong tool

The README carries a note that should end most adoption debates early: this repository is for decompilation only and its code is true to the original release, and it will not compile for targets other than 32-bit Windows. Anyone arriving from a search for a way to play LEGO Island on a modern system has found the wrong repository, and the README redirects them to isledecomp/isle-portable, described as a modern adaptation of the LEGO Island codebase with native compatibility for all major platforms and the Web.

The second limitation is legal and practical rather than technical. The build instructions assume you already possess the English 1.1 retail files and place them at specific paths under legobin/. The README does not tell you where to obtain them. The decompiled source is published under LGPL-3.0, but that licence covers the repository's code, not the original game assets or binaries, and nothing in the README suggests the retail files are redistributable. Working with this project therefore presumes you have a legitimate copy.

A third constraint is the toolchain itself. Byte-for-byte verification depends on Microsoft Visual C++ 4.2, a compiler from the mid-1990s, and on Wine outside Windows. That is not a stack most teams can drop into an existing CI pipeline without deliberate effort. The README also does not document what happens when verification fails partway through, beyond directing you to the report.

## isle-portable and the difference in approach

The real alternative is not another decompilation project but the sibling repository the README points to. isle-portable takes the LEGO Island codebase and adapts it for native compatibility across major platforms and the Web. The difference is the objective, and it changes everything downstream. isledecomp/isle treats the original machine code as the specification: the recompiled instructions should match, the build should reproduce the three retail binaries byte for byte, and the code stays true to the 1997 release. isle-portable treats cross-platform behaviour as the specification and is free to change code to reach it.

That means the two repositories answer different questions. If you need to know what the retail LEGO1.DLL did at a given address, or you want to contribute named functions and documentation to a codebase that is checked against the original, isledecomp/isle is the one with the verification machinery. If you want the game to run on Linux, macOS or in a browser, isle-portable is the repository the README itself names. Choosing between them is not a matter of quality; it is a matter of whether fidelity to 1997 or portability today is the constraint you are working under.

## Licence, maintenance and what an upgrade costs

The repository is licensed LGPL-3.0. For anyone embedding decompiled LEGO Island code in another project, that licence carries obligations around how modified library code is distributed and relinked, and the repository's LICENSE file is the text that governs. This is not legal advice, and the interaction between an LGPL-3.0 source release and the original game's own rights is a question for a lawyer, not for the README, which is silent on the subject.

On maintenance, the repository is not archived and the last push was on 2026-09-18, so work is ongoing. The single recent release is labelled continuous and carries the same 2026-09-18 timestamp, which fits the README's description of a GitHub Actions verification that regenerates the reports on every verified push. There is no versioned release train to upgrade along; you track master and re-run verification.

The upgrade cost is dominated by the environment rather than by code churn. A contributor needs Python 3.11 or newer, Git, ReproBit, Wine outside Windows, and a Visual C++ 4.2 installation for the CMake path, plus the retail binaries in legobin/. When the decompilation changes, the check is rbit verify . on a fresh checkout and a read of .reprobit-state/reports/report.html. The continuous release also prints reccmp score deltas and ReproBit intervention cost against master in the job log, which is where a regression in accuracy would show up first.

## Conclusion

Adopt isledecomp/isle if you are doing reverse engineering, source-level study of the 1997 LEGO Island code, or work that feeds isle-portable, and you can supply the English 1.1 retail files and a Visual C++ 4.2 environment. Do not adopt it if you want to play LEGO Island on a modern machine: the README states plainly that it will not compile for targets other than 32-bit Windows, and isle-portable is the project pointed at for that. Before contributing, run rbit verify . on a fresh checkout and read the report at .reprobit-state/reports/report.html, because only that path certifies byte-for-byte output and an ordinary CMake build does not.

## FAQ

### Can I use isledecomp/isle to play LEGO Island on a modern computer?

No. The README states that the repository is for decompilation only, that its code is true to the original release, and that it will not compile for targets other than 32-bit Windows. It points to isle-portable for a modern adaptation with native compatibility for all major platforms and the Web.

### How do I build isledecomp/isle so the output matches the retail binaries?

Install Python 3.11 or newer, Git and ReproBit, place your English 1.1 retail files at legobin/CONFIG.EXE, legobin/ISLE.EXE and legobin/LEGO1.DLL, then run rbit setup . followed by rbit verify . from the repository root. A successful run writes the three binaries into build/ and the result is reviewed at .reprobit-state/reports/report.html.

### What is the difference between the ReproBit build and the ordinary CMake build in isledecomp/isle?

ReproBit uses the original Microsoft Visual C++ 4.2 toolchain and produces and certifies the exact release binaries, and the README calls its byte-for-byte verification the authoritative result for contributions and releases. The ordinary CMake build is useful for day-to-day development, but its outputs are not release-certified.

### Which compilers and files does the isledecomp/isle build require?

The CMake path uses Microsoft Visual C++ 4.2, the original game's compiler, with CMake as the build system, and the README notes that other compilers may work for experimentation but are not covered. The exact-reproduction path additionally requires Python 3.11 or newer, Git, ReproBit, Wine on macOS and Linux, and the English 1.1 retail files placed under legobin/.

## Sources

- [isledecomp/isle on GitHub](https://github.com/isledecomp/isle)
- [Issues](https://github.com/isledecomp/isle/issues)
- [License: LGPL-3.0](https://github.com/isledecomp/isle/blob/master/LICENSE)
- [README](https://github.com/isledecomp/isle/blob/master/README.md)
- [Releases](https://github.com/isledecomp/isle/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/isledecomp-isle