Reverse Engineering der NLT II

[HenneNWH]

Jetzt sind es wieder 20 Bytes Unterschied, wie ich es vermutet hatte.

Am Offset 00:01:51:A4 steht

• In der originalen SCHICKM.EXE: 0C:01:CA:07
  
• In der am 12.11.2025 compilierten BLADEM.EXE: 0C:0B:E9:07
  
• In der am 13.11.2025 compilierten BLADEM.EXE: 0D:0B:E9:07
  

Damit ist der Fall klar: Das ist das Datum im Format Tag (1 Byte), Monat (1 Byte), Jahr (2 Bytes little endian). Die originale SCHICKM.EXE wurde demzufolge am 12. Januar 1994 compiliert. (Warum 1994 und nicht 1992? -- Weil es sich um die deutlich später erschienene CD-Version handelt.)

Gestern hat also zufälligerweise der Tag des Monats mit dem vom originalen Compilierzeitpunkt übereingestimmt, womit wir nur 19 Bytes Differenz gesehen haben und nicht 20. Im Januar wird das den ganzen Monat lang so sein, und am 12. Januar sind es sogar nur 18 Bytes Differenz.

Hab gerade für's Linken die Uhr der DOSBox zurückgedreht.
Die Binäräquivalenz ist jetzt bei 17 (+2 für den Stackpointer).

Zu dem Typecast: Keine Ahnung, viele Wege führen nach Rom.

[siebenstreich]

Jetzt sind es wieder 20 Bytes Unterschied, wie ich es vermutet hatte.

Am Offset 00:01:51:A4 steht

• In der originalen SCHICKM.EXE: 0C:01:CA:07
  
• In der am 12.11.2025 compilierten BLADEM.EXE: 0C:0B:E9:07
  
• In der am 13.11.2025 compilierten BLADEM.EXE: 0D:0B:E9:07
  

Damit ist der Fall klar: Das ist das Datum im Format Tag (1 Byte), Monat (1 Byte), Jahr (2 Bytes little endian). Die originale SCHICKM.EXE wurde demzufolge am 12. Januar 1994 compiliert. (Warum 1994 und nicht 1992? -- Weil es sich um die deutlich später erschienene CD-Version handelt.)

Gestern hat also zufälligerweise der Tag des Monats mit dem vom originalen Compilierzeitpunkt übereingestimmt, womit wir nur 19 Bytes Differenz gesehen haben und nicht 20. Im Januar wird das den ganzen Monat lang so sein, und am 12. Januar sind es sogar nur 18 Bytes Differenz.

Hab gerade für's Linken die Uhr der DOSBox zurückgedreht.



Die Binäräquivalenz ist jetzt bei 17 (+2 für den Stackpointer).

Zu dem Typecast: Keine Ahnung, viele Wege führen nach Rom.

Coole Sache! (Und vielen Dank, dass du mich in dem commit-comment und dem @REM erwähnst...)

Auch interessant, wie du das machst. So wie ich es verstehe, ist es ein kleines C-Programm, das die Uhr der Dosbox auf den 12.1.1994 einstellt, und welches du vor dem Ausführen des Borland-Linkers in der Dosbox startest.

(Das ganze erinnert mich daran, dass meine Eltern sich gelegentlich über eine verstellte Uhrzeit auf dem damaligen DOS-PC geärgert hatten. Der Schuldige war das Spiel Sokoban, bzw. ich, der es gespielt hatte. Vermutlich war das eine etwas brachiale Methode, um im Spiel die Zeit zu messen.)

[llm]

Die Binäräquivalenz ist jetzt bei 17 (+2 für den Stackpointer).

Stackpointer kannst du ja auch einfach patchen - Borland definiert seinen stack ja eh dynamisch (soweit ich gelesen habe)

[llm]

bereits vom Typ (struct enemy_flags) sein. Der Typecast hat also eigentlich nichts mehr zu tun -- warum ändert der Typecast den erzeugten Bytecode?

weil das durch den unnötigen cast eine copy forciert werden könnte - vielleicht nur beim Borland C++ 3.1 - neue kompiler machen sowas nicht, da kommt der gleiche code raus

aber selbst ein aktueller gcc erzeugt für die beiden Zugriffe anderen Code bei ohne Optimierung -O0 -> https://gcc.godbolt.org/z/z5vqa3szW

[llm]

Hab gerade für's Linken die Uhr der DOSBox zurückgedreht.
Die Binäräquivalenz ist jetzt bei 17 (+2 für den Stackpointer).

vielleicht würde es, wenn der Linker wirklich BLADEM.EXE verwendet es sich weiter angleichen, Checksummen oder sowas über den Dateiname, ... aber der Ist-Zustand ist ja schon ok

[llm]

ist im seg090.cpp Zeile 453 wirklich die \0 am Ende vom String nötig - die null wird ja normalerweise automatisch eingefügt und clang beschwert sich

[siebenstreich]

bereits vom Typ (struct enemy_flags) sein. Der Typecast hat also eigentlich nichts mehr zu tun -- warum ändert der Typecast den erzeugten Bytecode?

weil das durch den unnötigen cast eine copy forciert werden könnte - vielleicht nur beim Borland C++ 3.1 - neue kompiler machen sowas nicht, da kommt der gleiche code raus



aber selbst ein aktueller gcc erzeugt für die beiden Zugriffe anderen Code bei ohne Optimierung -O0 -> https://gcc.godbolt.org/z/z5vqa3szW

Danke für die Erklärung. Der Typecast führt also dazu, dass eine Kopie angelegt wird.

[siebenstreich]

ist im seg090.cpp Zeile 453 wirklich die \0 am Ende vom String nötig - die null wird ja normalerweise automatisch eingefügt und clang beschwert sich

Die Binäräquivalenz hilft uns hier nicht weiter, weil sich die Code-Stelle in einem FEATURE_MOD befindet. Ich habe mal verglichen, wie sich die resultierenden schick_gcc Dateien verändern, wenn ich das \0 rausnehme. Sie sind nicht identisch, d.h. das \0 hat tatsächlich eine Einfluss.

Man müsste sich die erzeugte Textmeldung also mal konkret im Spiel anschauen, um zu sehen, ob es das \0 wirklich braucht.

EDIT: Der Meister hat es schon erledigt!

[siebenstreich]

Es gibt an vielen Stellen Variablen, die in mehrfacher Funktion verwendet werden (z.B. als inventar-Slot und später in der Funktion als Helden-Position). Ich frage mich, wie wir solche Variablen benennen sollen. Ich bin dazu übergegangen, sie "tmp" zu nennen (bzw. "tmp_1", "tmp_2" usw wenn es mehrere sind), und hinter die Deklaration einen Kommentar im Stil von "/* multi use: inv_slot, hero_pos */" zu schreiben.

Findet ihr das gut? Gib es eine bessere Bezeichnung als 'tmp"? Wo ich gerade nochmals darüber nachdenke, fällt mir als Bezeichner noch "multiuse" ein, das wäre noch deutlicher.

[HenneNWH]

@LLM & siebenstreich:

* Das überflüssige Zeichen '\0' wurde aus dem String entfernt. Strings haben die abschließende 0 "automatisch".
  Wenn man einen C-String als Char-Array schreibt, ist die abschließende '\0' per Hand einzufügen.

*  Um schnellere Programme zu erhalten, haben die Compilerbauer damals einen Trick benutzt:
    Bsp: Zugriff auf Element array[i - 10].

    Normalerweise würde man erst (i - 10) berechnen, diesen Wert mit der Größe eines Elements multiplizieren, die Startadresse des Arrays addieren und dann den Wert aus dem Array auslesen.

    Da zur Compilezeit schon Informationen vorhanden sind, kann die Adresse von array[-10] schon im Voraus berechnet werden.
    Anschließend wird i * Elementgröße berechnet und zur Adresse von array[-10] addiert und der Wert ausgelesen.
    Nutzen: Die Berechnung von (i - 10) wurde eingespart.
    Nachteil: Es tauchen Speicheradressen im Binary auf, welche NICHT den Anfangsadressen von Arrays entsprechen.

    So war das früher!

  Unter dem Link von LLM sieht der Assemblerkundige an der Ausgabe von Clang, dass bei test1() direkt der Wert ausgelesen wird.
  Bei test2() werden die Flags in einer lokalen Variable zwischengespeichert.

  Stellt man auf den GCC um, wird bei test1() eine Adresse (x + 48) berechnet und der Wert mit dem Offset +4 ausgelesen.
  Bei test2() wird eine Adresse (x + 52) berechnet und der Wert ohne Offset ausgelesen.

  Test: (x + 48 + 4) ?= (x + 52) => (x + 52) == (x + 52) => PASST!

Nur zu Info: Wenn sich an den "neueren Binaries" etwas ändert ist das in Ordnung.
Zu GCC habe ich sehr großes Vertrauen, da dieser Compiler seit 1987 zum Bauen sämtlicher Linux-Distributionen benutzt wird.
Im Gegensatz zum BCC wird der allerdings noch aktiv weiterentwickelt.

Clang/LLVM ist seit mindestens 2000 verfügbar, kann Aufgrund des neugedachten Ansatzes wesentlich besser optimieren.
Da Clang mittlerweile auch Einzug in die Produkte der vermeintlich Großen gehalten hat (M$, Embarcadero) ist klar,
dass in diesen Unternehmen bzgl. der Weiterentwicklung von Compilern Stillstand herrscht.
So wie ich das wahrnehme sind MSVC und Delphi "nur noch" etablierte IDE's und Debugger.

Benchmark: Phoronix Clang vs. GCC
Fehlermeldungen: Clang, GCC, MSVC

@siebenstreich: Mehrfach benutzte Variablen würde ich jetzt noch nicht umbenennen. Der richtige Weg wäre diese später aufzusplitten, den Scope zu reduzieren und sie dann richtig zu benennen.

[siebenstreich]

@siebenstreich: Mehrfach benutzte Variablen würde ich jetzt noch nicht umbenennen. Der richtige Weg wäre diese später aufzusplitten, den Scope zu reduzieren und sie dann richtig zu benennen.

Ich denke mir halt, alles was man kapiert hat kann man auch gleich im Programmcode kenntlich machen. Dass das später in scopes zerlegt wird, widerspricht dem ja nicht.
Jetzt haben wir den Binäräquivalenz-Check noch zur Verfügung, der uns vor Fehlern bewahrt!

[HenneNWH]

Das verstehe ich. Im aktuellen Zustand sorgt das für Frustration.
Aktuell mache ich an schlecht benannte, mehrfach benutze Variablen einen Kommentar dran.
Die Variablen, die "nur schlecht benannt" sind, werden gleich umbenannt.

Code:

seg058.cpp:    signed int i; /* REMARK: also used as handle */

[llm]

Nur zu Info: Wenn sich an den "neueren Binaries" etwas ändert ist das in Ordnung.

ja das ist klar - ich wollte nur aufzeigen das ein ältere Kompiler vielleicht die Notation schon reicht um anderen Code zu erzeugen
so wie der gcc/clang wenn man die Optimierung ausschaltet - als Versuch Borland 3.1 Optimizer Qualität zu erreichen - im Vergleich  - mehr Bedeutung hatte der Vergleich nicht

So wie ich das wahrnehme sind MSVC und Delphi "nur noch" etablierte IDE's und Debugger.

MSVC mit Delphi in einen Topf zu werfen passt so gar nicht - Delphi(und C++Builder) sind faktisch tod und haben wirklich nur noch Nischenbedeutung

MSVC ist in der Windows-Welt der Platzhirsch - die meisten Windows-Programme werden immer noch mit dieser IDE und dem Kompiler erstellt
weil die IDE den besten(schnellsten) Debugger hat der so von keiner anderen IDE erreicht wird - nicht mal im Ansatz - Optimiert auf Mio/Mrd Symbole - davon ist leider jede andere IDE Kilometer entfernt - merkt man recht schnell im praktischen Einsatz wenn man mal viele Projekte und IDEs für C++ in den Fingern hatte - alle funktionieren, aber wenn die Projekte gross werden wird es mühsam - die meisten Spiele auf dem Markt werden damit erzeugt, Epic ist ja direkter Entwicklungspartner von Microsoft - nicht das ich ein Spieler bin - aber das ist ein Millarden-Markt der nicht klein oder unrelevant ist

Wenn man Windows-Software mit C++ macht ist die wahrscheinlichkeit auf MSVC zu treffen mind. 80%

Chrome wird mit dem clang-cl gemacht - damit google die MSVC-IDE nutzen kann aber darin mit dem clang bauen kann - das machen aber nach meinem Wissen nur noch LibreOffice auch noch - also nicht clang sondern ein clang-Kompiler der die Microsoft-Compiler Parameter versteht und sich auch so verhält - der kann direkt in MSVC verwendet werden - damit man den Debugger usw. hat - sonst macht der clang-cl keinen Sinn - clang-cl ist auch wie schon gesagt im Standard LLVM/Clang Paket immer mit dabei

gcc/clang kämpfen hier und da um optimaleren Code - mal gewinnt clang, mal gcc - wichtig die das die jemanden haben gegen den sie kämpfen können - der MSVC ist in vielen Fällen schlechter - wird deswegen aber nicht weniger verwendet weil es in vielen Programmen nicht die relevanz hat

und Microsoft ist auch viel stärker dabei neue C++ Standards umzusetzen, deren Open-Source STL ist da mitlerweile immer am weitesten, auch im Module-Support ist Microsoft führend, MSVC/cl ist vielleicht nicht so modern wie ein LLVM/clang aber trotzdem sehr dominierend auf dem Mark - die Zeiten vom alten Microsoft das sich nicht an Standards hält und mit allem hinterher ist sind schon sehr sehr lange vorbei

Es kommt sehr auf den Bereich/Branche an - Desktop-Software/Gaming ist Microsoft ganz vorne, für Server/etc. sind gcc/clang die Spitzenreiter

Microsoft hat den clang-cl in die IDE integrierbar gemacht (obwohl zu >90% von google entwickelt) und auch auch eine Kompiler-Variante mit clang-Frontend und Microsoft Backend, genau so wie Intel oder Embacadero (die behalten alle ihre Kompiler-Backends aber spielen eben mit den Frontends) - das sind aber alles Entwicklungen die nach dem Frontend stehen geblieben sind und nicht weiter gefahren werden - die clang-cl integration bei MSVC ist aber wenigstens so "unabhängig" das man einfach LLVM updaten kann und eben einen neueren clang-cl hat, früher gab es da nur den der von Microsoft mitgeliefert wurde

bei der Diagnose sind clang und gcc natürlich ganz vorne - die kämpfe da sehr aktiv um die Spitze, da kommen sehr viele Verbesserungen mit kurzen Abständen

worauf ich mich freue sind die neuen Template-Error Diagnostics im gcc 16: https://www.youtube.com/watch?v=v0X7o5wdoeY, der gcc 15 war aber diagnostisch auch schon wieder ein riesen Sprung

Ich baue immer den 3 Kompilern (wenn vom Projekt möglich) - normaler sauber geschriebener C/C++ Code läuft einfach bei allen gleich gut durch und ich hatte schon relevante Warnungen vom gcc die beim clang nicht kommen oder Link,Compiler Probleme von allen dreien - hab schon für jeden Kompiler ICEs gemeldet, wobei der clang bisher der stabilste ist, dann gcc und Schlusslich MSVC

[Hirukan]

Es sind nur noch 20 Bytes.
Der Code baut schon lange, wird aber noch nicht wirklich benutzbar sein.
Wenn die 20 Byte eliminiert wurden, wird der Code zu Rekonstruktionszwecken in ein anderes Verzeichnis kopiert.
Die Hauptentwicklung geht dann in diesem Verzeichnis weiter.
Es sind noch ein paar Pointer im Spielstand, weshalb Laden und Speichern noch nicht funktionieren wird.

Die nächsten Schritte sind dann:
* Grafik, Tastatur + Maus mit SDL2 ,
* Dateioperationen portieren,
* Musik (FLAC),
* Sound UUUUUND
* Bugfixing!

Ich hab eine Frage, warum SDL2 und nicht SDL3? 
Nicht, dass es einen großen Unterschied macht, aber speziell für die Grafik (das hat nun zusätzlich zu denen von SDL2 noch ein SDL_GPU backend was Vulkan, DX12 und Metal benutzen kann) und für Sound wäre doch auch SDL3 super. SDL3 hat ein wahnsinnig gutes Audio System (um Welten besser als SDL2) und auch SDL3 Mixer ist super gut und einfach zu benutzen.
Außerdem benutzt es "Main Callbacks" welche egal auf welchem Gerät es läuft, ideal mit den Powersaving Einstellungen zusammenarbeitet.
Somit könnte eigentlich alles in SDL3 verwirklicht werden und somit könnte die ganze Geschichte auch einfach für Android oder IOS, oder gar Emscripten portiert werden...

[HenneNWH]

Ich baue immer den 3 Kompilern (wenn vom Projekt möglich) - normaler sauber geschriebener C/C++ Code läuft einfach bei allen gleich gut durch und ich hatte schon relevante Warnungen vom gcc die beim clang nicht kommen oder Link,Compiler Probleme von allen dreien - hab schon für jeden Kompiler ICEs gemeldet, wobei der clang bisher der stabilste ist, dann gcc und Schlusslich MSVC

Das ist eine kluge Erkenntnis, LLM. Von "großen" SW-Unternehmen halte ich nicht viel.
Zuviel heiße Luft, zuwenig Qualität und wenig fähige Leute, die sich auf das Wesentliche konzentrieren.

Hab mal ein Jahr in einer Delphi-Bude verbracht und musste feststellen, dass es wirklich so katastrophal ist wie ich angenommen hatte. Keiner konnte was, aber alle waren wichtig.
aus Pietätsgründen habe ich mich nach einem Jahr aus dem Unternehmen entfernt.
Im Arbeitszeugnis steht "er hat immer die richtigen Entscheidungen getroffen und fand ausnahmslos gute Lösungen."

Ich hab eine Frage, warum SDL2 und nicht SDL3? 
Nicht, dass es einen großen Unterschied macht, aber speziell für die Grafik (das hat nun zusätzlich zu denen von SDL2 noch ein SDL_GPU backend was Vulkan, DX12 und Metal benutzen kann) und für Sound wäre doch auch SDL3 super. SDL3 hat ein wahnsinnig gutes Audio System (um Welten besser als SDL2) und auch SDL3 Mixer ist super gut und einfach zu benutzen.
Außerdem benutzt es "Main Callbacks" welche egal auf welchem Gerät es läuft, ideal mit den Powersaving Einstellungen zusammenarbeitet.
Somit könnte eigentlich alles in SDL3 verwirklicht werden und somit könnte die ganze Geschichte auch einfach für Android oder IOS, oder gar Emscripten portiert werden...

Das klingt gut, hat aber aktuell keine Relevanz. Mit SDL2 bin ich erstmal zufrieden und ich leide nicht an Featuritis.
* Vulkan, DX12, in einer 2D DOS-Anwendung => bringt gar nichts.
* Musik ist Stereo, Sound 22.1 kHz => bringt gar nichts.
* Energieverbrauch der Anwendung mit einer SDL3 Portierung => bringt gar nichts.

Welche Programmiersprachen kannst du denn? Hätte noch ein paar Aufgaben zu vergeben.
Der Charaktergenerator könnte noch einen Portraiteditor vertragen.
Ist ganz einfach...

[Hirukan]

Das klingt gut, hat aber aktuell keine Relevanz. Mit SDL2 bin ich erstmal zufrieden und ich leide nicht an Featuritis.
* Vulkan, DX12, in einer 2D DOS-Anwendung => bringt gar nichts.
* Musik ist Stereo, Sound 22.1 kHz => bringt gar nichts.
* Energieverbrauch der Anwendung mit einer SDL3 Portierung => bringt gar nichts.

Welche Programmiersprachen kannst du denn? Hätte noch ein paar Aufgaben zu vergeben.
Der Charaktergenerator könnte noch einen Portraiteditor vertragen.
Ist ganz einfach...

Ja das stimmt wohl. Der Software oder der OpenGL Renderer von SDL reicht da vollkommen aus, da ja nur ein fertiges Bild dargestellt werden muss.
Beim Audio jedoch eine Sache macht SDL3 was für mich den Wechsel rechtfertigen würde: Wenn das default Audio device des Gerätes verwendet wird und es sollte sich ändern (Kopfhörer angeschlossen, Bluetooth Lautsprecher benutzt, ...), dann wechselt das Audio System automatisch zu dem Neuen. Das macht SDL2 ja nicht, und der Sound kommt aus den unerwünschten Device raus. Und das ist schon gut meiner Meinung nach.

Bei der Energeiverwaltung, es kommt ganz darauf an. Der Compositor gibt an ob AppIterate aufgerufen wird. Was auf mobilen Geräten wichtig sein kann (und auch Wayland macht das), wenn die App im Hintergrund ist und damit nicht aufgerufen wird und die App nicht weiterläuft. Aber ich habe mir den Quellcode nicht genau genug angeschaut um zu beurteilen ob das auch sinnvoll benutzt werden kann. (Normalerweise kommt der Inhalt des gameloops einfach da rein). Aber da spricht wahrscheinlich einfach nur heraus, dass ich Programme auf PC und Handys gleichermaßen entwickle und das somit für mich hohe Priorität hat. Für mich die Vortsellung DSA am Handy zu spielen, die mag ich einfach gerne und dann ein wenig Reinzoomen zu können (z.B. im Kampfscreen), ... Aber das bin wahrscheinlich nur ich.

Falls die Frage für Programmiersprachen an mich gerichtet ist: C++ 17 (wegen Android) das ist mein Zuhause und ich habe mir auch etwas Rust angeeignet. Zwar schon länger nicht mehr angewandt C# und natürlich C.

[HenneNWH]

Nicht schlecht. Mit C-Cprachen ist man häufig auf der richtigen Seite.

Beim Charaktergenerator, stellvertretend für alle DOS-Spiele, war ein großer Performanceverlust und Resourcenverbrauch,
das permanente Aktualisieren des Fensterinhaltes. Auf einem Smartphone kann so etwas der Akkutod sein. :-(
Hinzu kommt dass die Auflösung auf 320x200 Pixel festgenagelt ist.
In dem Bereich hab ich aus dem Charaktergenerator schon erstmal alles rausgeholt.

Bei Schick kommt noch hinzu, dass zum Spielen auf Smartphones eine Ingame-Tastatur notwendig ist.
Ob das auf einem Smartphone wirklich Spaß macht, wage ich zu bezweifeln.

Mit ScummVM habe ich mal Monkey-Island versucht, das war nicht so toll.
Wenn du Bock hast einen ähnlichen Test zu machen:
"Eye of Beholder 1 + 2" und "Might & Magic IV + V" laufen mit ScummVM.
Ähnliches Spielprinzip, auf dem PC mit Tastatur und Maus gehts.
Versuch mal dein Glück!

@Obi-Wahn & Siebenstreich, ... : Bei M&M IV lagt der Mauszeiger ähnlich wie in der Anfagszeit im Charaktergenerator und sorgt bei kreisenden Bewegungen für eine CPU-Auslastung von 15 % im Vergleich zu 8 % ohne Mausbewegung. :-)

[NewProggie]

Da möchte ich doch nochmal an meinen Beitrag aus 2011 (!) verweisen. Da hab ich schon Schick auf meinem Android gespielt :-)

https://www.crystals-dsa-foren.de/showth...#pid100552

[HenneNWH]

Hatte damals ein N900 und hab Bright-Eyes darauf auf zum Laufen bekommen.
Das Gerät hatte eine Tastatur.
Komfortabel war das allerdings nicht.

Mit den Android-DOSBox Varianten mag das gehen, aber die CPU-Emulation der DOSBox ist extra noch ein Resourcenfresser.

[Obi-Wahn]

Wie viele Tastatureingaben braucht Schick eigentlich wirklich, die nicht durch andere Tasten zu ersetzen wären? Ich kann mich allerdings schon an ein paar Gelegenheiten erinnern, wo man Wörter eingeben musste. Aber vielleicht kann man da eine andere Lösung finden? :-D

Achja, die DosBox und Schick sind bei mir schon auf vielen Geräten "irgendwie" gelaufen. :-D