Decompilation progress

What the numbers mean

Reconstructed match

Written by AI agents and reviewed, then proven 100% byte-identical to the game by the compiler. A function whose source was written from understanding, in the game’s real class, and whose compiled bytes are identical to the retail program (details just below). Only these count in the headline game-code figure.

Auto-matched

A function whose bytes are identical to the retail program, but whose source was generated by a program from the bytes and the shape of the code, not written by a person. The bytes are proven identical; what is not proven is that the source is the game’s real source.

Stand-in

A made-up stand-in for a game class: a small struct that has just the fields a one-line function touches, at the right offsets, and nothing else. It reproduces the machine code, but it is not the real class, so a stand-in match of a named game function does not count as game code until the function is matched again in real source.

STL, proven from the real headers

Standard Template Library members (strings, vectors, maps and the like) compiled from the real Dinkumware headers that ship with the period compiler. These are the library’s own source, so this sub-tier is firmer than the stand-ins.

Byte-identical overall

Reconstructed plus auto-matched, divided by all bytes of code in the program. It says how much of the executable is reproduced exactly, whoever wrote the source.

Matched (byte-matched)

The function was rewritten from understanding, compiled with Visual Studio .NET 2003 (the compiler of the original build), and the bytes are identical to the retail program, with every address it refers to checked. Nothing else is counted: a rewrite that behaves the same but compiles differently is not a match.

Percent of the game code

Reconstructed matched bytes divided by the bytes of the named game functions: the 5,772 functions whose class and name are known because the program exports them (its scripting interface). It says how much of the part of the game that can be named has been rebuilt. It is the most generous figure, because game code that has no name yet is not in it.

Percent of the whole program

Reconstructed matched bytes divided by all 6,739,316 bytes of code in the program: every function, named or not, library code included, and data inside the code. A reconstructed match outside the named game functions counts here only. Auto-matched code is left out of this one and shown in its own tier.

Not measured

Data (tables, strings, resources) is not compared yet. Nothing on this page says anything about it.

What is known about the rest

Most of the program has no name: only the 5,772 exported functions are named, the other 71,702 are known by number. They are sorted here as far as the evidence goes and no further. Library code is recognised by matching the compiler’s runtime library, stubs and thunks by the shape of their bytes, and unnamed functions that sit between named ones are guessed to belong with them (the page says how often that guess was right in a test). Functions in the linked group are placed by a side reference (a source-file name, the only class that calls them, a copy of a named function); the guessing rules were right about 77% of the time in a leave-out test, so treat it as a hint, never a name. The biggest group, Unknown, is what none of these could place. It is large, and the page shows it as it is.