PC-DOS 1.1 disassembling & re-assembling nach Änderungen - teilweise erfolgreich, aber EXE2BIN macht Probleme

  • Aufgrund von PC-DOS 1.1 / MS-DOS 1.25 - Probleme? und dem Fehlen einer deutschen PC-DOS 1.1 Version habe ich damit angefangen, aus den Binaries wieder Quelldateien zu erzeugen, mit zwei Zielen, 1.) zuerst wieder aus Assembler-Quellen genau das gleiche originale Binary-File erzeugen zu können, und danach 2.) eine deutsche Version daraus zu erzeugen, angelehnt an den Zeichenketten in der deutschen PC-DOS Version 2.0 (die habe ich auch vorliegen).

    Bei den Dateien IBMBIO.COM und IBMDOS.COM bin ich schon erfolgreich gewesen, habe Stufe 1) schon geschafft, und auch schon englische Texte in IBMBIO und IBMDOS in deutsche Texte übersetzt. Die Re-Assemblierung ist da auch erfolgreich gewesen. Der Test steht noch aus, weil ich auch noch COMMAND.COM ins Deutsche übersetzen möchte.

    Ich hänge aber bereits bei COMMAND.COM (von PC-DOS 1.1) bei der Phase 1), ich kann zwar fehlerfrei die COMMAND.ASM assemblieren, aber EXE2BIN scheitert am Schluß.

    Ich habe dazu MASM 5.1 genommen, nicht eine neuere Version, weil ich mich mit dieser Version besser auskenne.

    EXE2BIN sagt aber ohne weitere Erklärung nur, dass es die assemblierte EXE-Datei nicht in eine COM-Datei wandeln möchte (es "kann" es nicht).


    Die Schritte sehen für alle drei Dateien gleich aus (unterschiedlicher Dateiname logischerweise, der Rest halt ist gleich), hier am Beispiel von IBMDOS.ASM:


    masm ibmdos;

    link ibmdos;

    exe2bin ibmdos ibmdos.com

    del ibmdos.exe


    Wie gesagt, geht ohne Probleme mit IBMBIO und IBMDOS, geht *nicht* mit COMMAND - und ich weiß wirklich nicht warum...


    Anbei mal die COMMAND.ASM, die einwandfrei mit MASM Version 5.1 assembliert werden kann, mit LINK geht's auch weiter, aber EXE2BIN will nicht.

    Die Struktur der Assembler-Datei ist dabei eigentlich bei allen drei gleich, alle drei haben kein extra Stack-Segment (dann hätte EXE2BIN auf jeden Fall ein Problem), und alle drei erzeugen eine EXE-Datei, die kleiner als 64KB ist. Vielleicht gibt es ja eine Alternative zu EXE2BIN, ich kenne keine.

  • Leider nein. Wollte mich eigentlich nicht mit der MASM 6.11 anfreunden, aber da würde das natürlich gehen.

    Wäre nur blöde, dass dann das gleiche Problem an anderer Stelle mit MASM 6.11 auftauchen würde.


    Wenn alle Stricke reissen, mache ich mir die Mühe auch nochmal, das Problem ist die manuelle Nachbearbeitung der von SOURCER erzeugten Assembler-Dateien, das dauert alles (da kommt nix fehlerfreies raus, das muss immer nachbearbeitet werden).

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • Vermutlich wird da irgendwo über die Sourcer Macros (die ich nicht zur Hand habe) ein zweites Segment angelegt.

    Dann kann EXE2BIN nicht funktionieren.


    Ich würde

    - die SOURCER include Datei weglassen,

    - das einzige davon verwendete Macro jmpn anpassen (vermutlich ein einfacher jmp)

  • Man kann die SOURCER Include-Datei nicht weglassen, dann geht gar nichts mehr zu assemblieren, weil nicht nur ein Macro genutzt wird.

    Es hat leider auch absolut gar nichts mit dem einen JMPN Macro zu tun, da ich ja andere Dateien (mit dem gleichen Include) einwandfrei assemblieren kann, wo auch das Macro genutzt wird.


    Die Idee, das mit dem MASM 6.11 unter Berücksichtigung der /TINY Option zu probieren, schlägt mit 86Box fehl, weil immer ein R6915 Fehler (DOSX16: unhandled exception) hochkommt, das Ganze unter MS-DOS 6.22, einmal mit und einmal ohne EMM386 (nur HIMEM.SYS). Das alles ist irgendwie voll die Murkserei, man kommt irgendwie nicht weiter.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • ... merkwürdig - wen ich die include Zeile auskommentiere und jmpn in jmp ändere, kann mein MASM 5.1 das problemlos übersetzen.

    Ich sehe da auch sonst keine Makros in Benutzung.

    Vielleicht war die verteilte COMMAND.ASM Datei nicht Deine aktuelle Version.

    Egal, die MAP Datei zeigt jedenfalls, dass man nur 1 Segment hat, so wie es sein soll.

  • Auch wenn COMMAND.COM so heißt, wie es heißt - Es ist alles andere als eine "normale" .COM-Datei.


    Außer dem transienten Teil, der auch brav wie ein normales .COM-File bei 100h beginnt und seinem Datensegment, hat es noch ein residentes Daten- und ein residentes Codesegment, die nur beim ersten Laden auch geladen werden, ansonsten aber "recycled" werden, nachdem ein geladenes Program den transienten Teil aus dem Speiche gekickt hat.


    Wahrscheinlich kommt EXE2BIN eben damit nicht klar. Wie es aber wirklich erzeugt wird, ist mir auch nicht ganz klar - wahrscheinlich braucht man dafür ein spezielles Tool (Die Quellen auf Github haben ein "HEX2BIN.ASM" - vielleicht hilft ja das weiter, auch wenn es eine Datei im Intel-Hex-Format erwartet).

    Einmal editiert, zuletzt von tofro ()

  • ... merkwürdig - wen ich die include Zeile auskommentiere und jmpn in jmp ändere, kann mein MASM 5.1 das problemlos übersetzen.

    Ich sehe da auch sonst keine Makros in Benutzung.

    Vielleicht war die verteilte COMMAND.ASM Datei nicht Deine aktuelle Version.

    Egal, die MAP Datei zeigt jedenfalls, dass man nur 1 Segment hat, so wie es sein soll.

    Vielleicht hast Du nicht richtig gelesen, Assemblieren ist *kein* Problem, nie gewesen. Es ging darum, wenn das OBJ erzeugt wurde, und danach der LINKer lief, dass danach EXE2BIN nicht eine COM Datei erzeugen kann.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • P.S.: Mit einem aktuellen VMWare Workstation Player 16.x kann man übrigens Windows 98 (egal ob FE oder SE) nicht mehr installieren.

    Siehe auch https://www.vogons.org/viewtopic.php?f=61&t=68205 ... mit VMWare Workstation Player12.5.9 ging's auch nicht, Lösung war, eine noch niedrigere Version (10.x) zu nutzen. Wollte schauen, ob eventuell - wie bei Microsoft C 7.0 - es bei MASM 6.11 am DPMI Support liegt, und der Test wäre gewesen, das nochmal in einem Kommandozeilenfenster mit MASM 6.11 zu probieren.

  • Man kann die SOURCER Include-Datei nicht weglassen, dann geht gar nichts mehr zu assemblieren, weil nicht nur ein Macro genutzt wird.

    Dann hatte ich das wohl falsch verstanden...


    Das Problem kommt von den far proc her, die Du da an verschiedenen Stellen in Deinem Code hast.


    Also beispielsweise die int..._entries. Wenn Du die far Spezifikationen wegnimmst, sollte sich zumindest ein EXEBIN kompatibles Ergebnis erzeugen lassen.


    Ich verwende übrigens den Linkker 5.15, damit spare ich mir den extra Schritt mit EXEBIN.

    Dass ich da MASM 3.0 verwendet habe, ist nur, weil ich in meiner VirtualBox gerade nur den installiert habe.


    In Virtual Box sieht das dann so aus:


  • Und noch ein Fehler in MASM 6.11 gefunden :(

    Wenn in einer Assembler-Datei ADD AX,46h steht, macht der MASM 6.11 daraus ADD AX,+46 (eigentlich habe ich ADD AX,0046 erwartet) - das ist definitiv ein Fehler. Bei SUB AX,46h hingegen macht er tatsächlich auch SUB AX,0046 draus... ich verstehe gar nichts mehr.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.