16.02.2017, 10:41
Du benutzt doch auch den BCC, stimmts?
Hast Du im Verzeichnis rewrite_m302de/temp/ die Dateien BLADEM.EXE und BLADEM.MAP?
Das Datensegment solltest du am besten aus der BLADEM.EXE extrahieren.
Das macht zum jetzigen Zeitpunkt für die GCC-Version tatsächlich keinen nennenswerten Unterschied.
Es wird erst interessant, wenn die ds_*-Makros/Funktionen wirklich durch Zugriffe auf die Variablen ersetzt werden.
Dann wird aber das Skript bc_ready.sh nicht mehr funktionieren,
da die Adressen in den Objektdateien relativ zum Anfang der DATA, bzw. BSS Sektion der Objektdatei angegeben werden.
Ich halte es für die einfachste Lösung, wenn als nächster Schritt das Datensegment in der DOS-Variante von Bright-Eyes
mit dem der SCHICKM.EXE in Übereinstimmung gebracht wird.
Dann reicht es aus nur noch die Binärdateien zu vergleichen.
Das funktioniert so nicht.
Der Grund dafür ist, dass die Daten- und Codebereiche in den OBJ-Dateien aufgeteilt werden.
Deshalb siehst du Verwaltungsdaten und Programmdaten gemischt.
Genau deswegen gibt es das tool dump_obj, welches die zusammengesetzten Codeteile aus den OBJ-Dateien extrahiert.
Eine datseg.obj gibt es jetzt nicht mehr, da die SCHICKM.EXE auch ein Segment (seg14) enthält,
dessen Größe von der Anzahl der gelinkten Objektdateien abhängt.
Die Datei datseg.cpp habe ich in seg002.cpp per include eingebunden.
(Kein guter Stil aber die Größe von seg14 ändert sich nicht.)
Das mag als guter Stil erscheinen, aber initialisierte Daten (DATA) und uninitialisierte Daten (BSS) werden vom Linker an unterschiedlichen Orten im Datensegment abgelegt.
Zuerst die C-Lib-Daten (DATA), z.B. der String "Borland C++"... , dann die DATA Daten der einzelnen Objektdateien,
in der Reihenfolge des Linkens.
Anschließend kommen die BSS-Daten.
Wenn die Variablen jetzt initialisiert werden wechseln sie von der BSS- in die DATA-Section
und die Reihenfolge ist durcheinander.
Ich bleibe bei der alten Datei.
Da fehlen zwar noch die Adressen von den Funktionspointern für Reiseevents, Zaubersprüche, etc.,
welche ich aus der GCC-Variante übernehmen kann.
Ein größerer Aufwand muss dann bei den Beschreibungen der Schatztruhen betrieben werden,
da diese auch Funktionspointer enthalten.
Ja, das ist im Detail nicht so einfach wie gedacht, aber du hast meinen Respekt und Dank,
dass Du dich in dieses Projekt so gut einarbeitest.
Hast Du im Verzeichnis rewrite_m302de/temp/ die Dateien BLADEM.EXE und BLADEM.MAP?
Das Datensegment solltest du am besten aus der BLADEM.EXE extrahieren.
(15.02.2017, 22:20)gaor schrieb: Bevor ich für irgendwas einen PR erstelle: Haben denn die Deklarationen der ganzen globalen Variablen Auswirkungen auf das mit gcc kompilierte Bright-Eyes? Macht das zum jetzigen Zeitpunkt irgendeinen Unterschied, wenn die da alle noch in der datseg.cpp herumfliegen?
Das macht zum jetzigen Zeitpunkt für die GCC-Version tatsächlich keinen nennenswerten Unterschied.
Es wird erst interessant, wenn die ds_*-Makros/Funktionen wirklich durch Zugriffe auf die Variablen ersetzt werden.
Dann wird aber das Skript bc_ready.sh nicht mehr funktionieren,
da die Adressen in den Objektdateien relativ zum Anfang der DATA, bzw. BSS Sektion der Objektdatei angegeben werden.
Ich halte es für die einfachste Lösung, wenn als nächster Schritt das Datensegment in der DOS-Variante von Bright-Eyes
mit dem der SCHICKM.EXE in Übereinstimmung gebracht wird.
Dann reicht es aus nur noch die Binärdateien zu vergleichen.
(15.02.2017, 22:20)gaor schrieb: Wenn ich aktuell eine DATSEG.OBJ baue und die dort enthaltenen Daten (mittels xxd) mit dem Datensegment der originalen SCHICKM.EXE vergleiche, kommt heraus, dass in der DATSEG.OBJ irgendwelche zusätzlichen Daten rumfliegen, deren Herkunft ich mir nicht erklären kann - allerdings erst ab Offset 0x0400 (gerechnet ab dem Beginn des Datensegments), davor stimmen die Datensegmente überein. Das bedeutet, dass mitten im Array "g_wearable_items_warrior" irgendwelche Daten eingefügt werden, die in der Deklaration gar nicht vorkommen?!
Das funktioniert so nicht.
Der Grund dafür ist, dass die Daten- und Codebereiche in den OBJ-Dateien aufgeteilt werden.
Deshalb siehst du Verwaltungsdaten und Programmdaten gemischt.
Genau deswegen gibt es das tool dump_obj, welches die zusammengesetzten Codeteile aus den OBJ-Dateien extrahiert.
Eine datseg.obj gibt es jetzt nicht mehr, da die SCHICKM.EXE auch ein Segment (seg14) enthält,
dessen Größe von der Anzahl der gelinkten Objektdateien abhängt.
Die Datei datseg.cpp habe ich in seg002.cpp per include eingebunden.
(Kein guter Stil aber die Größe von seg14 ändert sich nicht.)
(15.02.2017, 22:20)gaor schrieb: Übrigens gibt es eine neue Version meiner datseg.cpp: https://gist.github.com/tuxor1337/08cdaf...c95d466c18 Ich initialisiere jetzt auch Variablen, die den Wert 0 haben (hatte ich vorher uninitialisiert gelassen, dann sortiert er die aber in der DATSEG.OBJ weg).
Das mag als guter Stil erscheinen, aber initialisierte Daten (DATA) und uninitialisierte Daten (BSS) werden vom Linker an unterschiedlichen Orten im Datensegment abgelegt.
Zuerst die C-Lib-Daten (DATA), z.B. der String "Borland C++"... , dann die DATA Daten der einzelnen Objektdateien,
in der Reihenfolge des Linkens.
Anschließend kommen die BSS-Daten.
Wenn die Variablen jetzt initialisiert werden wechseln sie von der BSS- in die DATA-Section
und die Reihenfolge ist durcheinander.
Ich bleibe bei der alten Datei.
Da fehlen zwar noch die Adressen von den Funktionspointern für Reiseevents, Zaubersprüche, etc.,
welche ich aus der GCC-Variante übernehmen kann.
Ein größerer Aufwand muss dann bei den Beschreibungen der Schatztruhen betrieben werden,
da diese auch Funktionspointer enthalten.
Ja, das ist im Detail nicht so einfach wie gedacht, aber du hast meinen Respekt und Dank,
dass Du dich in dieses Projekt so gut einarbeitest.