Maschinencode => PureBasic

[ZeHa]

weil der PBCompiler aus bestimmten Code-Fragmenten immer bestimmten ASM-Output erzeugen wird

Bin mir aber nicht sicher, ob man sich immer daran orientieren kann. Es kommt auch drauf an, was der Programmierer im ursprünglichen Zustand so für 'nen Code hatte. Wenn der total wirr und unlogisch ist, ist auch der ASM-Output wirr und unlogisch. Und Sachen wie Funktions-Calls und Berechnungen werden in anderen Sprachen auch nicht großartig anders in Maschinencode umgesetzt wie in PB, daher bezweifel ich wirklich, ob das Rückübersetzen SOOO viel wesentlich einfacher sein soll als in C etc.

Und was hat das mit den Libs zu tun?? Wenn sie direkt eingebunden werden, liegen sie ebenfalls in Maschinencode vor, und wenn es DLLs sind, dann sind es halt DLLs. Wie stützt das jetzt die Aussage?

[ts-soft]

Lib A in Maschinencode wird immer gleich aussehen.
Das es einfacher geht, ist doch einfach nur logisch. Oder haste Dir noch nie eine mit PB erstellte Exe angesehen

Da findeste z.B. pb_toolbar_id usw.

[Kaeru Gaman]

durch den optimierungsvorgang ist diese menge an "bestimmten code-segmenten" verdammt schwindelerregend groß, weil ja unterschiedliche befehlskombinationen unterschiedlich optimiert werden.
das was ZeHa über unterschiedlichen Stil sagt, kommt noch dazu.

also, wenn du eine 57-Teraquad-Datenbank hast, wo alle möglichen code-kombinationen mit allen entsprechenden assemblerumsetzungen drinstehen, und du ein Null-Grav-Erzeuger hast, in dem die Zeit schnell genug abläuft, um die hundert Jahre rechenzeit in wenigen minuten durchzujechtern, dann kannst du den Code präzise zurückholen....

...aber immer noch ohne entsprechende variablennamen.. :p

[ts-soft]

Wer spricht von Präzise?
Nur PB-Syntax hab ich gesagt, das damit auch InlineASM usw. bei ist, ist ja wohl klar.

[ZeHa]

das damit auch InlineASM usw. bei ist, ist ja wohl klar.

???

[ts-soft]

Wenns dann so aussieht:

Code: Alles auswählen

Enumeration
  #B_EQUAL
  #B_GREATER
  #B_LESS
EndEnumeration 

Procedure Compare(A,B)
  If A=B:ProcedureReturn #B_EQUAL:EndIf
  If A>B:ProcedureReturn #B_GREATER:EndIf
  If A<B:ProcedureReturn #B_LESS:EndIf
EndProcedure


Procedure Test()





Eax=MessageBox_(00000000,"Test ?","Test",4)
 Ebx=Eax
result=Compare( Ebx,6)
If result=#B_LESS Or result=#B_GREATER: Goto  Label0:EndIf




Eax=MessageBox_(00000000,"Cool","",00000000)
Label0:
 Eax!Eax
; ERROR: POP Ebx
ProcedureReturn Eax
EndProcedure

Test()

Code ist nicht von mir
ist es immer noch PB-Syntax

[Kaeru Gaman]

was für ein thema

[Zaphod]

Auch die Decompiler für C/C++ produzieren nicht wirklich brauchbaren C/C++ code, also wen interessiert es?

Normalerweise ist es weniger aufwand ein Programm einfach neu zu schreiben als mit dekompiliertem code zu arbeiten.

[ZeHa]

Sorry aber ich find das ist totaler Schwachsinn. Man muß sich schon entscheiden, entweder übersetze ich den Maschinencode ZURÜCK in PB oder ich lasse ihn gleich als Maschinencode stehen. Aber wozu so einen Mischmasch? Wem bringt das was? Und vor allem: wo setzt Du da die Grenze? Wie willst Du festlegen, was letzten Endes als PB und was als ASM Code dastehen soll? Und egal wie Du die Grenze festlegst, kein Mensch wird damit zufrieden sein, weil jeder andere Ansprüche hat. Also wenn schon Maschinencode nach PB, dann auch wirklich nach PB.

Zum Thema insgesamt: denke auch, daß man mit so einem rückübersetzten Code nix anfangen kann. Allein schon eben, weil sämtliche Variablennamen und Funktionsnamen fehlen. Da wird das Verständnis schon bei 'nem 1000 Zeilen Programm 'ne üble Sache... dazu kommt übrigens, daß man sich seinen Code ja meistens in mehrere Files aufteilt - nach einer gewissen Logik natürlich. Wenn ich nun aber ein einziges PB-File habe, das aus 20.000 Zeilen besteht und in dem ich keine Chance habe, auch nur einen einzigen Variablennamen zu identifizieren - damit kann ich dann sicherlich nix anfangen. Bei Java geht das noch einigermaßen, da sind die Dateien ja schon automatisch nach Klassen getrennt. Aber auch hier wird's kein leichtes Vergnügen.

[ts-soft]

Was meinste wie Froh ich bin, das es keinen Sinn macht