Reverse Engineering der NLT II

[HenneNWH]

Um es einfach zu sagen: Ich entferne aus dem Schick-Code die Abhängigkeiten zur DOSBox.

Damals habe ich tief in der Trickkiste gewühlt, damit der Code in beiden Welten (DOSBox und DOS) korrekt funktioniert,
z.B. aus der virtuellen DOSBox-Umgebung ausbrechen, eigenen Code ausführen und wieder in die DOSBox rein, wenn es sich um Standartcode handelt (CLib: open(), close(), ...) oder Funktionalitäten welche von der virtuellen DOSBox-Hardware abhängen.
Dafür wurden "Callbacks" verwendet.

Schick soll irgendwann, wie NGEN, als native Desktop-Anwendung laufen, weshalb ich vorerst davon ausgehe,
das auf unterstützten Betriebssystemen eine funktionierende C-Bibliothek vorhanden ist.
Außerdem muss ich jetzt umdenken und ausschließlich für reale (aber veraltete) Hardware entwickeln.


Die Funktion creat() "Erzeugen einer neuen Datei" ist ein Beispiel dafür.
Diese ist auf den gängigen Betriebssystemen seit Äonen vorhanden,
schien unter Windows jedoch dafür verantwortlich gewesen zu sein,
dass die Dateilänge der CHR-Dateien unterschiedlich war.
In dem Fall kann gesagt werden: "Windows hat nachweislich meine Dateien kaputt gemacht."
Mit einem open() mit passenden Parametern konnte ich das Verhalten von creat() nachbilden und es scheint zu funktionieren.

Jetzt entferne ich gerade diese Verbindung zu C-Bibliothek ohne die DOS-Version zu beschädigen.
Mit dem bisher benutzen Testverfahren ist das ohne Weiteres möglich.
Wenn ich anfange die hartcodierten Variablen in richtige Variablen umzubenennen, funktioniert dieses jedoch nicht mehr.
Am Beispiel von NGEN habe ich schon ein Hilfsprogramm erstellt, welches zwei BCC EXE-Dateien vergleichbar macht.
Damit geht es dann hoffentlich.
Darüber zerbrech ich mir jetzt nicht den Kopf und lösche munter vor mich hin, bis es nicht mehr weitergeht.