# Fortschrittsberichte zur Dekompilierung richtig lesen

Author: DecompHub
Updated: 2026-10-10
Language: de
Canonical: https://decomphub.com/de/guides/understanding-decompilation-progress

Ein Prozentsatz braucht einen Geltungsbereich: Was wird gezählt, für welchen Build und zu welchem Zeitpunkt? DecompHub erhält Bezeichnung, Umfang und Quellenlink. Ohne belastbare Messung bleibt der Fortschritt unbekannt. Das ist nicht gleich null.

## Binärgleichheit und Nutzbarkeit

Eine Matching-Dekompilierung soll denselben Maschinencode wie ein bestimmter Original-Build erzeugen. Compiler und Einstellungen sind ebenso wichtig wie rekonstruierter Quellcode. Die [decomp.me-FAQ](https://www.decomp.me/faq) erklärt Vergleiche einzelner Funktionen in teilbaren Arbeitsumgebungen. Das Ergebnis einer Funktion ist keine Quote für ein ganzes Spiel.

Ein kompatibler Ersatz bildet Verhalten nach. [ScummVM](https://docs.scummvm.org/en/latest/help/faq.html) ersetzt Spielprogramme und nutzt deren Originaldaten. Unterstützung für ein Spiel ist daher kein Anteil binärgleichen Codes. Auch Portierungen und Hardwareforschung sind ohne solchen Bericht wertvoll.

## Den Nenner prüfen

Berichte zählen etwa Funktionen, Bytes, Dateien, Symbole oder identifizierte Assets. Diese Einheiten sind nicht austauschbar. **Fiktives Beispiel:** 900 passende von 1.000 Funktionen ergeben 90 Prozent nach Funktionsanzahl. Enthalten die übrigen Funktionen die Hälfte aller Codebytes, sind nicht 90 Prozent der Bytes fertig. Dies ist kein echter Katalogwert.

Prüfe **Messgröße**, **Einheit**, **Umfang** und **Quelle**. Bei einer Anzahl muss der Gesamtwert tatsächlich dokumentiert sein. Bibliothek, Region und vollständiges Programm sind verschiedene Bezugsgrößen.

[objdiff](https://github.com/encounter/objdiff) dokumentiert Vergleichs- und Berichtswerkzeuge. Ihre Verwendung allein verrät nicht, welche Konfiguration und welcher Nenner im jeweiligen Projekt gelten.

## Versionen getrennt betrachten

Ein Spiel kann regionale Ausgaben, Revisionen und Debug-Builds haben. Ein abgeschlossenes Ergebnis für eine Version beweist nichts über alle anderen. [Ocarina of Time](https://github.com/zeldaret/oot) beschreibt unterstützte Versionen und die Zielauswahl.

Code-Matching und Asset-Identifikation sind ebenfalls getrennte Aufgaben. Fertiger Code bedeutet nicht, dass jede Textur, jeder Klang und jede Datenstruktur verstanden ist. Bilde keinen Mittelwert, sofern das Projekt diese Gesamtgröße nicht selbst definiert.

## Datumsangaben unterscheiden

Ein **Berichtsdatum** stammt vom Herausgeber. Ein **Beobachtungsdatum** beschreibt, wann DecompHub die Quelle gelesen hat. Ein neuer Abruf kann eine alte Messung enthalten. Repository-Abfragen und Änderungen am Eintrag erneuern nicht automatisch den Messwert.

Die [Datendokumentation](/data) erklärt die Exportfelder. Zitiere Projekt, Messgröße, Umfang, URL und Art des Datums zusammen.

## Fehlende Daten ehrlich behandeln

Unbekannt kann ein fehlendes geeignetes Format, eine unerreichbare Quelle, einen unklaren Umfang oder noch ausstehende Erfassung bedeuten. Es beweist nicht, dass nichts getan wurde. Werte über 100 Prozent, veränderte Nenner oder widersprüchliche Badges müssen geprüft werden. Keine stillen Korrekturen, erfundenen Nullwerte oder Sterne als Ersatz.

[Öffne Projekte mit erfasstem Fortschritt](https://app.decomphub.com/de/explore?progress=in-progress) und vergleiche Gleiches mit Gleichem. Melde falsche Angaben über die Projektseite mit der konkreten Originalquelle.