Decompilertest an dem Programm Green Line 4 von Heureka Teachware

Ich habe gestern meinen zu 80% fertigen Decompiler an dem Programm "Learning English - Green Line 4" von Heureka Teachware getestet.

Im Anhang ist das Decompilat im PetCat Format und eine lauffähige Version als D64 Datei. Bitte mit dem Notepad++ oder einem äquivalentes Tool ansehen und/oder bearbeiten.

Für Interessierte geht nun auch ganz klar hervor, wie die Kopierschutzabfrage im Basic Programm gestartet- und das Ergebnis der Abfrage weiterverarbeitet wird.

Ich denke mal, dass das Decompilat recht gut geworden ist. Auf ein Renumber und einem Basic-Packing habe ich verzichtet. Jeder Befehl hat soweit wie möglich eine separate Zeile.

So ist alles übersichtlich und man kann den Basic Code auch gut bearbeiten. Der Decompiler kann, wenn alles fertig ist, auch ein Packing und ein Renumber, nur eignet sich der Basic Code dann nicht mehr zum edieren.

Die Datei "LEA" im D64 ist das Austrospeed Originalcompilat (P-Code). Der PetCat Basic Code ist das Decompilat von der Original "LEA" Datei im D64.

Ja Larry, so langsam wird der Decompiler was. Ist auch ein Akt, den Code soweit wie möglich zurück in einem guten/brauchbaren Basic-Code zu wandeln.

@JeeK

Es ist die Datei "LEA" im D64, die ich decompiliert habe. Ziel ist es , ein Decompilat zu erzeugen, welches nach einem weiteren Compilieren auch fehlerfrei

arbeitet, ohne den Basic Code von Hand zu edieren.

Viele Decompiler erzeugen unnötige "cmd,;" Befehle oder unnötigen "for..next" Basic Code.

19956 j=1

19957 forj=1to16

Wobei Zeile 19956 nutzlos ist.

Kurz gesagt, haben alle Decompiler mehr oder weniger blöde macken. Bei Basic Extensions decompilieren fast alle Decompiler nur Müll. Das Problem habe ich bereits gelöst.

Bezugnehmend auch auf den älteren Thread

Kopierschutzverfahren gelüftet

PS: Larry, den original Quellcode hätte ich auch gerne.

Ja, kann ich gleich mal ansehen.

Mal eine andere Frage für die Basic Profis. Warum funktioniert obriges Decompilat nicht. Warum funktioniert das darunterliegende Decompilat.

Ich muss den Decompiler so coden, dass dieser funktionsfähigen Code erstellt. Im Moment steige ich da nicht so ganz durch, weil beide Basic Codes doch gleich sind.

12336 open15,8,15

12348 print#15,"u1:";

12355 print#15,5;

12357 print#15,0;

12359 print#15,35;

12362 print#15,11

12336 open15,8,15

12348 print#15,"u1:";5;0;35;11

Parser.

Hier Bitteschön.

Bei Beispiel 2 sind alle werte hinter print#15 an einem print#15 mittels ; gehangen. Die Syntax ist ansonsten mit der mehrzeiligen Basic Variante identisch.

Ich muss den decompiler vermitteln, wann alle print#15 zu einem print#15 zusammengefast werden müssen, damit der basic-code funktioniert.

5 ist der Floppy Buffer.

Es geht darum, dass Codebeispiel 1 nicht funktioniert. Codebeispiel 2 funktioniert aber, obwohl beide das Selbe machen.

Ich muss hierfür eine Lösung für den Decompiler finden, weil dieser im Moment nach Beispiel 1 decompiliert.

Danke, das funktioirt seltsamerweise leider nicht. Larry sucht gerade in seinen Büchern nach der Lösung.

Das funktioniert. Kannst du im Winvice Bildschirm reinpasten und starten. Vorher aber eine Diskette einlegen.

12336 open15,8,15

12341 open5,8,5,"#"

12348 print#15,"u1:";5;0;35;11

13000 close15:close5

Das funktioniert nicht . Kannst du auch im Winvice Bildschirm reinpasten und starten.

12336 open15,8,15

12341 open5,8,5,"#"

12348 print#15,"u1:";

12355 print#15,5;

12357 print#15,0;

12359 print#15,35;

12362 print#15,11

13000 close15:close5

Beide Codes machen exakt dasselbe, nur eine Version funktioniert. Ich muss nur wissen, ob das nur bei "U1",U2","M-R" ect. Befehlen so ist,

um eine Decompilerdirective zu coden. Z.B. wenn "Ux"or"B-x"or"M-x" then strip all Print#x to one.

Der Decompiler erstellt den Basic Code nach Code-Prinzip , obere kurze Version, weil untere lange Version in diesem Fall nicht funktioniert.

Ich suche auch schon in meinem Basic-Code Sammelsurium nach eine Erklärung. Ich bin mir aber ziemlich sicher, dass ein "PRINT#xx" bei Zugriffe auf externe Hardware, nur

einmal gesendet mit werden darf. Also "PRINT#xx" plus Befehlsstring. Ein mehrmaliges Senden des "PRINT#xx" Befehls, verursacht, vielleicht aufgrund eine Floppy-DOS Bug

diesen Fehler.

Wie war das noch

10 rem gO

list

OK, dass das kein bug ist, hatte ich gerade durch teste festgestellt. Das der Befehl in einem Stück gesende werden muss, wusste ich nicht.

Danke für den Hinweis. Von Basic habe ich nun nicht mehr das große Wissen.

PS: Warum muss der Befehl in einem Stück gesendet werden? Interessehalber mal diese Frage.

Und warum wird nach

10 rem gO

list

das angezeigt?

10 rem gdata

ready.