Skip to content
r-melvinPublic

About

Decompilation of the Red Alert 2 / Yuri's Revenge engine (gamemd.exe v1.001, MSVC 6.0) for software preservation

Topics

Resources

Contributing

Stars

27 stars

Watchers

3 watching

Forks

Repository files navigation

gagarin

Progress

gagarin is reconstructing the Command & Conquer: Red Alert 2 — Yuri's Revenge engine from retail gamemd.exe v1.001. The aim is a buildable, structured, human-readable C++ project whose classes and organization follow Westwood's as closely as binary evidence allows. Each annotated engine function aims to reproduce the retail instructions with the period compiler, including verified layouts and address bindings. Statically linked library code is outside source-recovery scope. Function matching and successful compilation do not prove whole-image identity.

The current project status, verified progress, consolidation record, coverage caveats and remaining gates are in STATUS.md. The target image is identified by SHA-256 in reccmp-project.yml.

At source snapshot ce91a761 (2026-10-27), 10,307 of the 19,778 functions in the extent census are matched (52.1%) and 784 more are partial. Matched bodies cover 716,425 of 3,878,653 listed function bytes (18.5%). The full regression check re-proves every matched row; affected exact functions also pass explicit relocation checks. The address-faithful stub link (M1) resolves every external and places all 14,699 matched entries at their retail addresses. With --pin-data --order-tail, 14,692 of them are byte-identical to retail in place. The M1 image itself is a layout probe with stub bodies. The M2 hybrid image (link_m1.py --hybrid) has .text, .rdata, .data and .rsrc equal to retail and starts under Wine, but fills unmatched code and data from the pinned binary; at M3, 39.2% of its 8,391,297 section bytes come from source. No whole-image identity is claimed.

gagarin matching progress

gagarin link milestones

Get started

You need a legally owned copy of gamemd.exe v1.001 for retail verification, Wine (WoW64), Python 3, Git, 7-Zip, GNU objdump, Ghidra, and the MSVC 6.0 toolchain fetched separately by scripts/vc6/fetch_toolchain.sh. Do not commit the game binary, assets, PDBs, build outputs or toolchain.

scripts/vc6/fetch_toolchain.sh
scripts/vc6/compile_all.sh
GAMEMD_BINARY="/path/to/gamemd.exe" python3 scripts/vc6/verify_all.py
python3 scripts/vc6/build_project.py --jobs 8
python3 scripts/vc6/link_diag.py --objdir build-vc6/project
python3 scripts/vc6/link_m1.py --objdir build-vc6/project

compile_all.sh is the binary-free compile gate. verify_all.py checks the manifest's fully matched functions against the pinned retail binary and compile-checks documented partial rows. build_project.py compiles tracked C++ files into path-preserving VC6 objects. Two link probes run on those objects: link_diag.py (M0) links everything with /FORCE and counts the unresolved externals, and link_m1.py (M1) links the objects with int3 stubs in retail order, then mapcheck.py checks each matched function's linked address. Neither of those two images runs (--hybrid builds the runnable M2 image). scripts/orchestration/link_svg.py --refresh updates the link figures from their output. See CONTRIBUTING.md for setup, the per-function matching workflow and file conventions; AGENTS.md defines the evidence and engineering rules; LEGAL.md defines the legal scope and provenance restrictions.

ByteMatch reports

After the compile gate, default-branch push builds upload a GAMEMD_1.001_report artifact for ByteMatch. Generate the same report locally with:

python3 scripts/vc6/bytematch_report.py --output build/GAMEMD_1.001/report.json

The exporter writes objdiff-format version 2 JSON from the checked-in match manifest and function census. It does not run an objdiff comparison or replace the retail verification gate. Known functions use their manifest lengths; unclaimed functions use census lengths. report-context.json records any differences from the older census. Partial functions receive no matched credit, and every unit remains marked incomplete. The linked figure (complete_code) is the .text bytes the M3 link takes from source (scripts/data/link_progress.json), counted only while that image equals retail. Progress is also split into a game category (engine code) and a library category (CRT, comsupp, LZO and linker thunks, outside the recovery scope). Data progress is not measured. Source units follow the repository paths; unrecovered functions have no invented source path. Existing function address annotations support source lookup. Only JSON reports are uploaded; no game bytes, objects or toolchain files.

Evidence and legal scope

The retail binary is the authority for addresses, layouts, signatures and matches. External references can suggest names or organization, but every fact must be confirmed against binary evidence. Source recovery for statically linked CRT and third-party code is out of scope; their bytes still belong to the complete executable reproduction target.

See LEGAL.md for licensing, permitted source material and commit restrictions, and LICENSE for the licence text.

Credits

  • itsmattkc/MSVC600 supplies the fetched VC6 toolchain.
  • reccmp provides the annotation format and project configuration; this repository implements the byte and instruction checks.
  • decomp-permuter supports bounded source-variation searches.
  • REA and Ghidra support focused reverse engineering and evidence gathering. Retail instructions and the VC6 oracle remain the factual checks.
  • YRpp, TSpp and EA's released Red Alert source are consult-only naming and structure references, as restricted by LEGAL.md.

About

Decompilation of the Red Alert 2 / Yuri's Revenge engine (gamemd.exe v1.001, MSVC 6.0) for software preservation

Topics

Resources

Contributing

Stars

27 stars

Watchers

3 watching

Forks

Releases

Packages

Contributors

Languages