Reverse Engineering der NLT II

[HenneNWH]

Glückwunsch! Was ist denn mit den 12 verbleibenden Bytes, warum geht das nicht besser? Ist davon auszugehen, dass auch Attic hier mit Assembler-Code gearbetet hat?

Nope, das ist genau eine Zeile in C. Damit muss ich leben! :-D

Für die perfekte digitale Denkmalpflege fehlt mir in dieser Liste irgendwie noch der Aspekt, den Quellcode möglichst verständlich zu machen.

Also das Herausarbeiten der Programmlogik, so dass der (mitunter etwas krude) originale Code möglichst gut gelesen und verstanden werden kann, beispielsweise:

• Variablen und Funktionen passend benennen nach einem konstistenten Schema.
  
• "magic numbers" durch benannte Konstanten ersetzen (also z.B. g_hero.skills[TA_SCHWERTER] anstelle von g_hero.skills[3]).
  
• Höhere Datenstrukturen (structs) einführen, soweit es die Binär-Äquivalenz zulässt.
  
• Nicht offensichtliche Programmlogik kommentieren.
  
• Insbesondere: Bugs und sonstige Dubiositäten dokmentieren.
  
• Soweit es ohne übermäßigen Aufwand funktioniert: Optional zuschaltbare Bugfixes, so dass idealerweise mit dem BCC eine dem umfassenden Bugfix-Patch ebenbürtige Version der Schicksalsklinge erzeugt werden kann.
  

(Die letzten beiden Punkte sind eher für die SCHICKM.EXE gedacht und für die GEN.EXE hoffentlich irrelevant, aber wer weiß.)



Der Test auf Binär-Äquivalenz ist bei solchen Änderungen (abgesehen von Bugfixes) eine sehr mächtige Absicherung, dabei nicht versehentlich etwas kaputt zu machen. Zumindest ist die Erfahrung aus meinen Versuchen, den Bright-Eyes-Code der Schicksalsklinge dahingehend weiterzubringen.

Vorerst arbeite ich an der neuen Version und hab heute sehr große Umbauarbeiten gemacht und interne Abhängigkeiten minimiert um vorzubereiten wo ich am Besten etwas bewirken kann. Das hat schon viel gebracht.

Beeindruckend, mit welch großen Schritten es hier vorangeht. Durch die Aufspaltung ist jetzt aber die Situation eingetreten, dass Änderungen vom oben aufgelisteten Typ eigentlich parallel in beiden Versionen gemacht werden müssten.

Beispiel: In diesem Commit wurden einige Dinge im "modernen Teil" mit treffenderen Bezeichnern belegt.

Henne, hast du vor, solche Umbenennungen auch nach gen_dos rückzuportieren? Ich fände das sehr gut.

Wenn es am Generator "nichts mehr zu tun gibt" und alles soweit verstanden ist, werden dann auch die alten Versionen entsprechend aktualisiert. Dort muss aber weitestgehend alles so bleiben wie es ist.

Wenn man sich nicht ganz genau auskennt, drängt sich bei V1.06 der Eindruck auf, dass dass Attic doch noch eine neuere Version produziert hatte.

Meiner Meinung nach wäre für BrightEyes eine unabhängige Versionsnummerierung besser.

Z.B. BE1.0 (BrightEyes 1.0) oder V1.05BE1 (Die auf V1.05 basierende BrightEyes Version 1) oder so.

Joa, aber erstmal als Arbeitsversion bin ich zufrieden.