Reko's build has two documented Visual Studio traps and one native proxy

Three drivers, and only two of them finished

The solution folder called Drivers holds the executables that act as user interfaces, and it has three subdirectories. WindowsDecompiler is the GUI client for the Windows Forms interface. AvaloniaShell is the client for the cross-platform Avalonia interface, and the page marks it as still under construction. CmdLine is the command line driver. So the honest count is two shipped front ends, a command line one and a Windows one, with a third in progress. Behind them sits the core decompiler engine, and behind that the back ends, which is the three layer split the page describes. The ambition stated is broad, supporting decompilation of various processor architectures and executable file formats with minimal user intervention, with the complete list deferred to a wiki page of supported binaries. The two screenshots on the page are both of an ARM binary, one showing its byte map and one the decompiled output, so ARM is the architecture the page demonstrates.

What you learn about a binary lives in a sidecar project file

The engine takes two kinds of input, and the second one is the interesting one. It accepts individual executable files, and it accepts decompiler project files, and those project files hold optional additional information about a binary that helps either the decompilation process or the formatting of the output. Everything a previous session established about a binary, its structure, its symbols, its layout, therefore lives in a file next to your work rather than in a database or in the binary itself. That has a practical consequence for anyone scripting this: reopening a binary without its project file starts from nothing, and copying the executable without the project file discards what the earlier analysis produced. The page does not describe the file format, and the user's guide under doc/guide is where the details are meant to live, with the wiki covering the internal workings.

One command line path, two configurations, three architectures

Building from source means cloning the repository and building the solution file Reko-decompiler.slnx, and the page gives one command for it:

dotnet msbuild -p:Platform={platform} -p:Configuration={config} -v:m -t:build_solution -m ./src/BuildTargets/BuildTargets.csproj

The two placeholders are enumerated: configuration is either Debug or Release, and platform is x64, x86 or ARM64, so six combinations. The target is build_solution, dispatched through a BuildTargets project rather than through the solution file directly, which is how one command covers every front end. Compilation needs the .NET 9.0 SDK, and IDE users are told to use a recent Visual Studio 2026. There is also a fallback for the people who hit a wall: the page asks you to say so if you still cannot compile, so that the project can fix the issue, which tells you the build is expected to be approachable but occasionally is not.

WiX warnings are noise, the CMake project is not

Two separate toolchain problems get their own sections, and only one of them is optional. Loading the solution in Visual Studio without the WiX toolset installed produces warnings and errors that the page says can be safely ignored, because WiX is used only when making MSI installer packages, and because the build process copies all the necessary files into a single directory, so an installer is not needed to get a working copy. CMake is the other case, and it is not optional: NativeProxy depends on it, so Visual Studio may try to rebuild that project. The page is precise about the consequence of the CMake that ships inside Visual Studio, which is enough to run msbuild from the Developer Command Prompt but not to build from inside the IDE unless CMake is on the global PATH, and installing CMake externally is what lets you add it to PATH during installation.

A known Visual Studio hang, and the workaround by name

One more Visual Studio specific failure is documented with its workaround. In certain versions of the IDE, loading the project leaves Visual Studio stuck on Running Background Tasks and refusing to build. The fix is to right click the NativeProxy project in the solution explorer and choose Unload Project, after which the project loads and builds correctly, and the page adds that this never happens when building from the command line. Read together with the previous section, the picture is that the command line path is the one the project maintains as the reference, while the IDE path needs two accommodations: CMake on the global PATH, and NativeProxy unloaded if the IDE hangs. Neither of those is a defect in the decompiler, both are environment issues, and both are documented closely enough that you can hit them without surprise.

Two CI systems, and releases every few months

The repository carries both a .cirrus.yml at the root and a .github/ directory, so continuous integration runs on two systems, with the GitHub Actions workflow named reko.yml. That workflow doubles as a distribution channel: users who cannot or will not build Reko themselves can download the output of the integration builder instead of building. Official releases go to GitHub and to SourceForge, and the page says they are published every few months, which the tags bear out with version-0.12.3 on 16 June 2026, version-0.12.4 on 29 July 2026 and version-0.12.5 on 29 September 2026, the last of them sharing its timestamp with the last push to the branch. The rest of the root explains how the build is arranged: a CMakeLists.txt and a cmake/ directory for the native side, an external/ directory for the dependencies it builds from source, a .ci/ directory, and a .vscode/ directory for editor configuration.

The name is Swedish, the chat badge is not Gitter

Two small details on the page are worth catching. First, the name is given a meaning: Reko is Swedish for decent and obliging, which is the sort of detail that tells you the project has a personality and not just a codebase. Second, the support paragraph names a chatroom as Gitter.im, and the address behind that label, and the badge at the top of the page, both point to a discord.gg link instead, so the label is out of date and the destination is a Discord server. The same paragraph sets expectations in a way most projects do not bother with, saying Reko is built by volunteers in their spare time and asking you to adjust your response time expectations accordingly. Issues and questions otherwise go to the issue tracker, and the wiki plus a style guide under doc/ are where contributors are pointed.

The licence paragraph is a warning, not a disclaimer

The page states that Reko is freely available under the GNU General Public License, and the tree carries COPYING, the same text in COPYING.rtf, and an INSTALL file, so the licence is in the repository in two formats. What is more interesting is the paragraph that follows the ambition statement, because it is about the user rather than the software: many software licences prohibit decompilation or other reverse engineering of their machine code binaries, and the instruction is to use the decompiler only if you have legal rights to decompile the binary, for instance if it is your own. That sentence is the actual operating condition for everything else on the page. Alongside it, the root also carries AUTHORS, NEWS.md, TODO.md and CONTRIBUTING.md, and the wiki holds a road map of areas open to contributors, which is where a new contributor is told to look before proposing work.

Editorial conclusion

Reko fits someone who owns the binary or has the legal right to decompile it, works on Windows or Linux, and is prepared to read the user's guide before touching the options. It does not fit a workflow that needs a finished cross-platform desktop interface today, because the Avalonia shell is still under construction and only the command line driver and the Windows Forms client are described as existing. Before building, check four things: that you have the .NET 9.0 SDK rather than only the runtime, that your CMake is on the global PATH if you build inside Visual Studio, that you are prepared to unload the NativeProxy project if the IDE hangs on background tasks, and that you skip the WiX toolset entirely unless you actually want an MSI package. The project states plainly that it is built by volunteers in their spare time, so issue response time is the thing to plan around rather than features. Licensed GPL-2.0, latest tag version-0.12.5 on 29 September 2026.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. uxmal/reko on GitHub