Login

siebenstreich · (Dieser Beitrag wurde zuletzt bearbeitet: 09.02.2021, 22:51 von siebenstreich.)

Danke für diese ausführliche Antwort!

So ganz funktioniert es leider noch nicht.
Das Skript ./disassemble.sh (das ich noch ausführbar machen musste) liefert bei mir

Code:
SEG001.dis near =  3  far = 25  changed

SEG002.dis near =  92  far = 338  changed

SEG003.dis near =  0  far = 9  changed

SEG004.dis near =  30  far = 67  changed

SEG005.dis near =  2  far = 63  changed

SEG006.dis near =  3  far = 33  changed

SEG007.dis near =  1  far = 0  changed

SEG008.dis

SEG009.dis

SEG010.dis near =  0  far = 2  changed

SEG011.dis

SEG024.dis near =  1  far = 23  changed

SEG025.dis near =  14  far = 143  changed

SEG026.dis near =  9  far = 160  changed

SEG027.dis near =  0  far = 140  changed

SEG028.dis near =  7  far = 129  changed

SEG029.dis near =  2  far = 56  changed

SEG030.dis near =  3  far = 118  changed

SEG031.dis near =  1  far = 29  changed

SEG032.dis near =  0  far = 88  changed

SEG033.dis near =  0  far = 124  changed

SEG034.dis near =  0  far = 82  changed

SEG035.dis near =  0  far = 32  changed

SEG036.dis near =  0  far = 49  changed

SEG037.dis near =  0  far = 34  changed

SEG038.dis near =  1  far = 8  changed

SEG039.dis near =  0  far = 27  changed

SEG040.dis near =  0  far = 27  changed

SEG041.dis near =  1  far = 40  changed

SEG042.dis near =  0  far = 129  changed

SEG043.dis near =  0  far = 138  changed

SEG044.dis near =  0  far = 23  changed

SEG045.dis near =  0  far = 12  changed

SEG046.dis near =  0  far = 108  changed

SEG047.dis near =  0  far = 17  changed

SEG048.dis near =  0  far = 87  changed

SEG049.dis near =  0  far = 63  changed

SEG050.dis near =  0  far = 68  changed

SEG051.dis near =  2  far = 87  changed

SEG052.dis near =  0  far = 46  changed

SEG053.dis near =  0  far = 66  changed

SEG054.dis near =  0  far = 79  changed

SEG055.dis near =  2  far = 39  changed

SEG056.dis near =  0  far = 100  changed

SEG057.dis near =  0  far = 107  changed

SEG058.dis near =  2  far = 87  changed

SEG059.dis near =  0  far = 45  changed

SEG060.dis near =  1  far = 115  changed

SEG061.dis near =  3  far = 86  changed

SEG062.dis near =  0  far = 74  changed

SEG063.dis near =  3  far = 88  changed

SEG064.dis near =  0  far = 7  changed

SEG065.dis near =  0  far = 134  changed

SEG066.dis near =  55  far = 111  changed

SEG067.dis near =  9  far = 114  changed

SEG068.dis near =  2  far = 125  changed

SEG069.dis near =  0  far = 48  changed

SEG070.dis near =  0  far = 86  changed

SEG071.dis near =  0  far = 70  changed

SEG072.dis near =  5  far = 64  changed

SEG073.dis near =  0  far = 21  changed

SEG074.dis near =  13  far = 34  changed

Traceback (most recent call last):

  File "./nc2fc.py", line 63, in <module>

    opcode = int(pushline[1][:2], 16)

IndexError: list index out of range

SEG076.dis near =  9  far = 87  changed

SEG077.dis near =  0  far = 61  changed

SEG078.dis near =  0  far = 119  changed

SEG079.dis near =  1  far = 107  changed

SEG080.dis near =  0  far = 98  changed

SEG081.dis near =  0  far = 141  changed

SEG082.dis near =  0  far = 55  changed

SEG083.dis near =  12  far = 118  changed

SEG084.dis near =  0  far = 125  changed

SEG085.dis near =  0  far = 102  changed

SEG086.dis near =  0  far = 76  changed

SEG087.dis near =  0  far = 162  changed

SEG088.dis near =  0  far = 30  changed

SEG089.dis near =  28  far = 105  changed

SEG090.dis near =  4  far = 76  changed

SEG091.dis near =  7  far = 57  changed

SEG092.dis near =  1  far = 90  changed

SEG093.dis near =  0  far = 46  changed

SEG094.dis near =  5  far = 56  changed

SEG095.dis near =  20  far = 60  changed

SEG096.dis near =  14  far = 12  changed

SEG097.dis near =  6  far = 89  changed

SEG098.dis near =  2  far = 81  changed

SEG099.dis near =  0  far = 81  changed

SEG100.dis near =  0  far = 79  changed

SEG101.dis near =  0  far = 80  changed

SEG102.dis near =  0  far = 35  changed

SEG103.dis near =  0  far = 88  changed

SEG104.dis near =  0  far = 80  changed

SEG105.dis near =  1  far = 27  changed

SEG106.dis near =  0  far = 126  changed

SEG107.dis near =  0  far = 57  changed

SEG108.dis near =  0  far = 85  changed

SEG109.dis near =  4  far = 147  changed

SEG110.dis near =  4  far = 166  changed

SEG111.dis near =  0  far = 152  changed

SEG112.dis near =  3  far = 125  changed

SEG113.dis near =  3  far = 163  changed

SEG114.dis near =  0  far = 159  changed

SEG115.dis near =  0  far = 152  changed

SEG116.dis near =  0  far = 171  changed

SEG117.dis near =  0  far = 174  changed

SEG118.dis near =  0  far = 117  changed

SEG119.dis near =  0  far = 74  changed

SEG120.dis near =  1  far = 178  changed

SEG121.dis near =  0  far = 40  changed

SEG122.dis

Der Fehler "IndexError: list index out of range" ist vermutlich nicht so gewollt.

Und das Compilieren geht auch nicht, leider. Auskommentieren der seg038-Zeile in compile.bat und anschließendes Ausführen von tools/bc.sh liefert

Code:
seg038.cpp

Error seg038.cpp 13: Unable to open include file 'string.h'

Error v302de.h 12: Unable to open include file 'stdlib.h'

Error v302de.h 973: Unable to open include file 'DOS.H'

[...]

Anscheinend findet er die Bibliotheks-Dateien nicht. Unter src/custom/drive_c/BORLANDC/INCLUDE gäbe es bei mir die Dateien STDIO.H, STDLIB.H und DOS.H.

Hast du zufällig noch eine Idee, wie ich weiterkommen könnte? Ich würde wirklich gerne kontrollieren, wie viel ich mit meinen ganzen Änderungen mittlerweile kaputt gemacht habe.

gaor · 09.02.2021, 20:22

Also ich habe das jetzt auch nur aus dem Gedächtnis und aus den verlinkten Beiträgen rekonstruiert. Ich kann das Skript disassemble.sh auch auf meinem aktuellen System nicht ausführen, weil nc2fc.py in Python Version 2 geschrieben ist, und mein System (Fedora) unterstützt kein Python 2 mehr. Deswegen kann ich dir jetzt so auf die schnelle leider keine Hilfestellung leisten. Vielleicht finde ich am Wochenende Zeit.

wiese.hano · 09.02.2021, 22:24

Wenn ihr das hinbekommt, werde ich es auf jeden Fall auch durchexerzieren.

siebenstreich · (Dieser Beitrag wurde zuletzt bearbeitet: 10.02.2021, 00:38 von siebenstreich.)

(09.02.2021, 20:22)gaor schrieb: Also ich habe das jetzt auch nur aus dem Gedächtnis und aus den verlinkten Beiträgen rekonstruiert. Ich kann das Skript disassemble.sh auch auf meinem aktuellen System nicht ausführen, weil nc2fc.py in Python Version 2 geschrieben ist, und mein System (Fedora) unterstützt kein Python 2 mehr. Deswegen kann ich dir jetzt so auf die schnelle leider keine Hilfestellung leisten. Vielleicht finde ich am Wochenende Zeit.

Vielen Dank, das wäre wirklich sehr nett! Ich habe gerade nochmal alle Schritte durchgeführt, ausgehend von einer frischen Kopie der letzten BrightEyes-Version von Henne. Auch die SCHICKM.EXE hab ich nochmal von meiner originalen CD gezogen. Die beiden Fehler bleiben, leider. Was könnte die Ursache sein? Bei disassemble.sh könnte es sein, dass neuere Versionen von ndisasm bzw. Python-Modulen etwas anderes produzieren als die damaligen Versionen, mit denen das Skript von Henne geschrieben wurde. Und bei tools/bc.sh könnte es sein, dass in der Archive-Version des Borland Compilers Sachen fehlen oder anders aufgebaut sind.

Die Python 2 vs. Python 3 Problematik ist ein ewiges Ärgernis. Ich musste mich auch wieder damit herumschlagen, um disassemble.sh zum Laufen zu bringen. Bei mir ist ein Ubuntu am Laufen, wo es glücklicherweise keine grundlegenden Probleme mit Python 2 gibt. Gelernt habe ich dabei auch, dass es in Ubuntu neuerdings zwei (sich gegenseitig ausschließende) Pakete namens python-is-python2 und python-is-python3 gibt, die einen Link unter /usr/bin anlegen, so dass der Befehl python dann python2 bzw. python3 aufruft.

**Rabenaas** · 10.02.2021, 16:10

(09.02.2021, 20:22)gaor schrieb: Ich kann das Skript disassemble.sh auch auf meinem aktuellen System nicht ausführen, weil nc2fc.py in Python Version 2 geschrieben ist, und mein System (Fedora) unterstützt kein Python 2 mehr.

Könnt ihr mir einen Beispielinput für nc2fc.py geben? Ich habe das nach Python3 umgeschrieben, aber noch nicht getestet.

gaor · (Dieser Beitrag wurde zuletzt bearbeitet: 12.02.2021, 12:06 von gaor.)

So, ich hab das Problem mit der disassemble.sh gelöst. Edit: Siehe mein nächster Beitrag für den Fix.

@Rabenaas: Danke für das Übersetzen in Python 3. Du hast auch noch ein bisschen Code-Linting betrieben, sehr löblich. Edit: Siehe mein nächster Beitrag für den passenden Pull Request.

gaor · (Dieser Beitrag wurde zuletzt bearbeitet: 12.02.2021, 12:05 von gaor.)

@siebenstreich: Dein Problem mit der bc.sh kann ich nicht reproduzieren. Hier habe ich mal alle Dateien in BORLANDC aufgelistet, dann kannst du vergleichen ob in deiner Version vielleicht Dateien fehlen: https://paste.eccologic.net/?5cfda88c19f...fhVcUZofJi

@siebenstreich: Ich habe einen Pull Request erstellt für die Unterstützung von Python 3 und neuere nasm-Versionen, dann braucht man auch keine conda-Umgebungen und solchen Kram: https://github.com/siebenstreich/Bright-Eyes/pull/1 Würdest du das bitte mergen? Ich würde sowieso vorschlagen, dass wir jetzt erstmal mit deinem Fork weiterarbeiten, solange Henne nicht erreichbar ist.

siebenstreich · (Dieser Beitrag wurde zuletzt bearbeitet: 13.02.2021, 23:02 von siebenstreich.)

goar: Danke für den pull request! Ich habe das übernommen. Wobei ich die Sachen nach wie vor natürlich am liebsten im originalen BrightEyes drin sähe. Aber da dort Funkstille ist, ist die nächstbeste Variante natürlich, zumindest an nur einem Fork rumzuschrauben.

./disassemble.sh geht jetzt, danke auch an Rabenaas!

Du hast ja noch weitere Sachen geändert. Für die Wiederherstellung der Binäräquivalenz in seg068.cpp bin ich froh. Darf ich daraus schließen, dass ich sonst nirgends etwas kaputt gemacht habe? Darauf hätte ich nicht viel getippt.

Etwas ärgerlich finde ich es schon, dass wir anstelle von

Code:
for (item_pos = cursed_hero_pos = 0; item_pos <= 6; item_pos++, hero += SIZEOF_HERO) {

nicht

Code:
cursed_hero_pos = 0;

for (item_pos = 0; item_pos <= 6; item_pos++, hero += SIZEOF_HERO) {

schreiben dürfen. Ich kann nicht recht glauben, dass die Attic-Programmierer das damals so geschrieben haben. Gibt es (im Rahmen der Binäräquivalenz) wirklich keine Möglichkeit, diese geschachtelten Zuweisungen besser lesbar zu machen?

Deine ITEM-Umbenennungen sind gut für die Lesbarkeit. Eine Sache dazu: Teilweise waren und sind diese Bezeichner auf Englisch ("ITEM_WHIRLWEED"), teils auf Deutsch ("ITEM_LOBPREISUNGEN"), oder sogar ein Mischmasch "ITEM_ANGST_POISON". Nachdem es ja die deutschsprachige Version ist, die hier nachkonstruiert wird, würde ich am liebsten die Gegenstände konsequent nach dem deutschen Namen im Spiel benennen. Also z.B. "ITEM_WIRSELKRAUT" oder "ITEM_ANGSTGIFT". Ansonsten müsste man ja eigentlich in der englischen Version nachschauen, wie die ganzen Gegenstände dort korrekt heißen, was auch irgendwie albern wäre.

siebenstreich · (Dieser Beitrag wurde zuletzt bearbeitet: 13.02.2021, 23:14 von siebenstreich.)

@gaor:
Das Problem mit tools/bc.sh besteht unverändert weiter, leider. Ich habe deine Dateiliste stichpunktartig verglichen, und konnte keine Unterschiede feststellen.
Womit hast du diese Liste erzeugt? Dann könnte ich das auch machen und direkt die Listen vergleichen.

Noch eine Bitte: Könntest du das Skript tools/bc.sh vielleicht mal testweise mit der oben verlinkten archive-Version des BCC ausprobieren?

gaor · 14.02.2021, 14:45

(13.02.2021, 22:58)siebenstreich schrieb: Du hast ja noch weitere Sachen geändert. Für die Wiederherstellung der Binäräquivalenz in seg068.cpp bin ich froh. Darf ich daraus schließen, dass ich sonst nirgends etwas kaputt gemacht habe? Darauf hätte ich nicht viel getippt.

Ja, sieht so aus als wäre das das einzige Problem.

(13.02.2021, 22:58)siebenstreich schrieb: Ich kann nicht recht glauben, dass die Attic-Programmierer das damals so geschrieben haben. Gibt es (im Rahmen der Binäräquivalenz) wirklich keine Möglichkeit, diese geschachtelten Zuweisungen besser lesbar zu machen?

Ich halte es nicht für so abwegig, dass die Attic-Programmierer das so geschrieben haben. Aber es kann auch sein, dass es anders geschrieben werden kann, ohne die Binäräquivalenz zu zerstören.

Ich habe mir die Version von BCC 3.1 angeschaut, die auf Archive liegt. Da fehlt anscheinend das "Application Framework". Das gibt es beispielsweise hier: https://winworldpc.com/product/borland-c/30

siebenstreich · (Dieser Beitrag wurde zuletzt bearbeitet: 15.02.2021, 00:04 von siebenstreich.)

(14.02.2021, 14:45)gaor schrieb: Ich habe mir die Version von BCC 3.1 angeschaut, die auf Archive liegt. Da fehlt anscheinend das "Application Framework". Das gibt es beispielsweise hier: https://winworldpc.com/product/borland-c/30

Vielen Dank! Damit scheint es jetzt zu klappen.

Anleitung: Unter dem winworldpc-Link "Borland CPP 3.1 and Application Frameworks (1992) (3.5-1.44mb)" herunterladen. Dann alle Diskettenimages der Reihe nach einzeln mounten und die darin enthaltenen Dateien in ein Verzeichnis <all_disks> kopieren (die Dateien von den verschiedenen Disketten landen also alle im selben Verzeichnis). Außerdem ein Verzeichnis <install> anlegen. Dann Dosbox starten,

Code:
mount a <all_disks>

mount c <install>

a:

install

In dem Installer unter "Windows Options" alles abwählen, dann "Start Installation".

Danach liegt unter <install> das benötigte Verzeichnis BORLANDC mit Compiler, Bibliotheken etc.

gaor · 15.02.2021, 21:08

Super! Unsere Erkenntnisse zum Developer-Setup würden doch ein gutes README-Dokument abgeben, das du in deinen Fork aufnehmen könntest, findest du nicht? Das war lange schon überfällig. Hier im Forum altern derlei Infos und HowTos leider nicht besonders gut, sondern verschwinden allmählich im Nirvana der Thread-Historie.

siebenstreich · (Dieser Beitrag wurde zuletzt bearbeitet: 20.02.2021, 01:10 von siebenstreich.)

Ja, das ist eine gute Idee. Ich habe in der README.brighteyes bei mir ein paar Zeilen geschrieben.

Allerdings springt ja jetzt beim commit dieser pre-commit-hook an, der mit BCC testen will ob alles passt.
Und dabei bekomme ich jetzt folgende Fehlermeldung:

Code:
wc: <path>/src/custom/schick/rewrite_m302de/temp/disasm_orig/SEG013.dis: No such file or directory

head: invalid number of lines: ‘<path>/src/custom/schick/rewrite_m302de/temp/disasm/SEG013.dis’

REPORT 110 Files: Good = 110 Fail = 0

Fehler: 110 Dateien wurden geprueft, aber es sollten 111 sein

Good files were broken

Beim genaueren Hinschauen fällt auf, dass in der disassemble.sh die Dateien SEG012.dis bis SEG023.dis nicht erzeugt werden. Das ist auch in der letzten Henne-Version von BrightEyes schon so, wir haben also nichts kaputtgemacht. Nachdem der BCC-commit-Test bei dir ja offenbar durchgelaufen ist, gaor: Könntest du mir hier nochmal helfen?

gaor · (Dieser Beitrag wurde zuletzt bearbeitet: 20.02.2021, 11:01 von gaor.)

Du hast in der SEG043 einige Aufrufe von D1_INFO hinzugefügt, ohne "#if !defined(__BORLANDC__)", deswegen schlägt die BCC-Kompilation von seg043.cpp fehl. Zugegebenermaßen ist die Fehlerausgabe des Hook-Skripts bc_ready.sh nicht besonders hilfreich. Ich habe einen Pull Request erstellt, der die Ausgabe etwas verbessert und seg043.cpp korrigiert: https://github.com/siebenstreich/Bright-Eyes/pull/2

siebenstreich · 20.02.2021, 11:18

Vielen Dank!

Ich schaue mir das später genauer an, wenn ich Zeit habe. Nur kurz:

Wäre es nicht besser, das

Code:
#if !defined(__BORLANDC__)

in das Makro D1_INFO mit hineinzuverpacken?

Und dass in disassemble.sh SEG012 bis SEG023 fehlen, ist wohl tatsächlich korrekt so?

Bitte vorerst keinen größeren Commit machen, bei ist nämlich noch was in der Warteschlange...

gaor · (Dieser Beitrag wurde zuletzt bearbeitet: 20.02.2021, 14:42 von gaor.)

D1_INFO ist ein Makro mit Variadic-Argument, also mit einer Variablen Anzahl an Argumenten: D1_INFO(...) Diese Art von Makro wird von BCC 3.1 nicht unterstützt: http://www.bitsavers.org/pdf/borland/bor...e_1992.pdf Es gäbe die Möglichkeit, D1_INFO als eine richtige Funktion zu definieren, die nichts tut:

Code:
static inline void D1_INFO(...) { }

Aber leider ignoriert das der BCC-Compiler nicht, sondern baut da tatsächlich einen function call ein, der dann die Binärkompatibilität zerstört.

Also, wenn du eine elegante Möglichkeit siehst, D1_INFO in BCC zu definieren, ohne die Binärkompatibilität zu zerstören, dann los. Ansonsten muss es bei dem umständlichen #if !defined(__BORLANDC__) bleiben.

Tja, zu den fehlenden SEG012 bis SEG023 kann ich nichts sagen, aber das wird schon Absicht sein, vermute ich.

siebenstreich · (Dieser Beitrag wurde zuletzt bearbeitet: 20.02.2021, 22:17 von siebenstreich.)

Danke für die Erklärung zu D1_INFO, das ist einleuchtend (und ein wenig ärgerlich). Also hilft es wohl nichts, das "#if !defined(__BORLANDC__)" muss jedes mal hin.

Zu dem commit-hook: Ich kriege jetzt die von dir geänderte Meldung "Warnung: SEG013 is nicht im Disassembly der Original-EXE."
Für mich klingt das so, wie wenn der Verlust der Binärkompatibilität in seg013.cpp nicht überprüft wird (und ich vermute ähnliches für seg014.cpp bis seg023.cpp). Das kann doch nicht so gewollt sein?

Mein commit ist durch. Ich habe u.a. den Rechtschreibfehler 'heros' zu 'heroes' korrigiert, das betraf recht viele Dateien.

gaor · 20.02.2021, 22:37

Doch, es kann schon sein, dass 13 bis 23 keinen richtigen Code enthalten. In der bc_ready.sh steht was von BSS, und das würde dann bedeuten, dass die hauptsächlich aus 0 bestehen: https://de.wikipedia.org/wiki/Datensegment#BSS Also ich würde mich darum jetzt erstmal nicht kümmern.

siebenstreich · 20.02.2021, 22:48

Ich denke, du hast recht. Ich hätte auch erst mal richtig schauen sollen: seg012.cpp bis seg023.cpp gibt es ja gar nicht. Die einzigen Dateien in diesem Bereich sind seg013.h und seg013.asm. (evtl. kommt daher die Warnung über SEG013).

siebenstreich · (Dieser Beitrag wurde zuletzt bearbeitet: 25.02.2021, 14:24 von siebenstreich.)

gaor, ein kleines Rätsel für dich: Warum liefert 'make' einen Fehler, wenn ich diesen Kommentarblock "einkommentiere"? Ich verstehe es nicht.

In diesem Zusammenhang noch was: Spricht etwas was dagegen, assert.h einzubinden und sowas in assert(...) reinzusetzen? Die entsrpechenden Codestellen müssen natürlich durch eine Präprozessor-Variable abschaltbar sein, damit der BCC davon nichts mitbekommt.

Login
Benutzername:
Passwort:	Passwort vergessen?
	Merken