Verdammt, das ärgert mich jetzt maßlos. Ich habe Rollercoaster Tycoon mit Railroad Tycoon verwechselt, welches ein 16-bit DOS Spiel war. Aber du hast natürlich Recht: Rollercoaster Tycoon ist ein 32-bit Windows-Spiel, und damit ist was ich gesagt habe in diesem Fall völlig hinfällig.
Das ärgert mich jetzt maßlos, da ich es absolut vermeiden will, Fehlinformation zu verbreiten. Technisch stimmt was ich gesagt habe alles… aber halt kein bisschen für das Spiel, um das es hier geht! Meine aufrichtige Entschuldigung!
Ob etwas Mal in Assembler, C, C++ oder sonst was geschrieben wurde ist für die Ausführung völlig irrelevant. All das wird in die gleiche Binärdarstellung übertragen und läuft natürlich noch genau so auf einem modernen Prozessor.
Da verstehe ich jetzt aber nicht ganz, worauf du eingehst? Natürlich ist das irrelevant wenn es für die selbe Architektur geschrieben wurde. Ein Programm das aber z.B. in 68k- oder 8080-Assembly geschrieben wurde, oder eines das in C geschrieben und vom Compiler für eben diese übersetzt wurde, läuft natürlich nicht ohne Emulation auf einer modernen CPU. So würde es sich auch mit 16-bit x86 Code verhalten.
Ja, exakt das meinte ich. Im 64-bit-Modus gibt es (anders als im 32-bit Protected Mode) keine 16-bit-Segmente mehr, demnach auch kein vm86 mehr, und damit keinen 16-bit Code ohne Emulation mehr. (Ich habe sogar schon selbst kleinteilig einen vm86-Monitor geschrieben.) Leider ist Rollercoaster Tycoon wohl überhaupt kein 16-bit Code.
Vor allem weil DOS selbst ein 16-Bit-Produkt ist, und dessen Schnittstellen dann auch. Wobei 32-bit Programme unter DOS üblicherweise über DOS-Extender (bestimmt erinnern sich viele noch z.B. an DOS/4GW) eine 32-bit-Adaption zu diesen Schnittstellen bekommen haben. Windows hatte zumindest mal auch selbst für lange Zeit einen eingebaut.
Wurscht, hat ja mit Rollercoaster Tycoon nix zu tun.
den alten Assembler-Code durch einen decompiler gejagt hat und dann diesen (unlesbaren) C-Code weiter verwendet hat. […] Solange der Code sich an gewisse Regeln hält, können auch Programme die ursprünglich von Hand in Assembler geschrieben wurden, durchaus dekompiliert werden, wenn das einzige Ziel ein erneutes Übersetzen für andere Plattformen ist, kann das durchaus ein adäquater weg sein.
Da wage ich aber ein bisschen Zweifel. Hast du mal gesehen, was dabei dann rauskommt? Wenn etwas in der 16-bit-Ära in Assembly geschrieben wurde, dann folgt das nicht unbedingt gängigen Calling Conventions, sauberen Stack Frames, und generell den üblichen Mustern die ein Compiler produziert. Der decompilierte C-Code (z.B.) ist, falls der Decompiler nicht sowieso wegen komischen Sprüngen mit komischen Stack-Layouts aussteigt, bestenfalls bizarr. Selbst 16-bit C-Sourcecode wäre sehr schwer zu verwerten (ich kann separat ausführen warum).
Um zurück zum Thema Rollercoaster Tycoon zu kommen: Ich vermute, dass auch das weiterverwerten des handgeschriebenen 32-Bit-Windows-Code sich nur schwer für andere Plattformen weiterverwenden lassen würde. Wäre er von einem Compiler generiert worden, sähe das anders aus, da er dann eine viel bessere Chance hätte, sinnvoll decompiliert zu werden.
Hi :),
ich hatte das bereits im SF Discord gepostet, aber vielleicht ist es auch für ein paar Leute hier interessant:
In eurer RollerCoaster-Tycoon-Folge (Wusstet ihr eigentlich…?) hattet ihr ja einen Bug angesprochen, bei dem der Szenario-Fortschritt beim Wechsel zwischen Sommer- und Winterzeit verloren geht. Chris hat spekuliert, ob da ein Cheat- bzw. Anti-Cheat-Mechanismus falsch läuft, und Gunnar meinte, das Spiel könnte das Systemdatum abfragen, um zu tracken, wie viel Zeit vergangen ist. Das hat mich nicht losgelassen, also hab ich mir eine Originalversion über eBay besorgt und den Grund direkt in der Binary gefunden. Ist etwas detailliert geworden – ich hab ein Video draus gemacht:
Kleiner Teaser: Mit Cheat-Schutz hat es tatsächlich nichts zu tun. Die eigentliche Ursache liegt an einer Stelle, die man erstmal nicht auf dem Schirm hat. Und dann ist da noch ein mysteriöses Datum im Code, der 20.12.1998.
Nur zur Info, es gibt jetzt einen englischen dev.to Artikel. Der ist jetzt aber mehr für Reverse-Engineering Publikum: RollerCoaster Tycoon and the Mysterious 20.12.1998 - DEV Community
Hier noch ein bisschen Spaß/Experimentierfreude.
Ich habe Classic RCT Deluxe mit Hilfe einer MCP Bridge an eine agentische Steuerung angebunden (im Video Claude Code). Ein ausführliches Video über die Architektur und das Reverse Engineering dahinter ist in Arbeit — falls ihr besondere Fragen habt, nehme ich die gern mit auf. (Claude Code => JSON RPC(StdIO) => MCP Bridge => Unix Sockets => MCP Daemon => /proc/pid/mem Zugriff auf gamescope-wine-RCT)
Herzlich willkommen im Forum @lutzleonhardt 
Danke für deine Begrüßung 
Das ist ja abgefahren. Schreibt dein MCP da direkt im Speicher des RCT Prozesses herum? Und woher weiß Claude, welche Variable wo steht? Hast du ihm da Code zum lernen gegeben?
Genau richtig. Die RCT-Engine arbeitet in Ticks: Bei jedem Durchlauf werden die Daten im Speicher ausgewertet, um Bedingungen zu prüfen und Interaktionen zu triggern. Ich habe die notwendigen Datenstrukturen (Sprites/Peeps, Rides usw.) reverse-engineered und den Code nach und nach aufgedeckt — die Erkenntnisse habe ich fortlaufend in ein Handbuch geschrieben.
Claude Code (oder jedes LLM mit MCP-Zugriff) kann ein Python-Skript an den Server senden. Im Skript stehen Funktionen für den Lese- und Schreibzugriff auf die Datenstrukturen bereit — geschrieben werden darf dabei nur auf Speicherstellen, die im Handbuch explizit freigegeben sind. Das Handbuch selbst kann CC per Tool durchsuchen und Infos nachschlagen. Beispiel: CC schickt ein Skript, das über das Sprite-Array iteriert, das Typ-Flag auswertet (nur Peeps), das Byte-Feld für die ID extrahiert, einen Lookup in die globale Names-Table macht und die Infos zurückgibt. Heißt auch: Je intelligenter das Modell, desto besser das Ergebnis.
Hier ist das Repo: GitHub - lutzleonhardt/rct-bridge · GitHub
Hier das Handbuch: rct-bridge/PEEP_HANDBUCH.md at main · lutzleonhardt/rct-bridge · GitHub