Autoit Frage

1. offizieller Beitrag

    Hallo die frage interessiert mich schon lange.

    Wenn ich ein AutoIT Skript habe, und es in eine EXE kompiliere, dann funktioniert es auf anderen PCs ohne AutoIt auch...-> logisch

    aber damit es auf anderen Rechnern funktioniert, muss es ja in ein Windowsstandardisiertes Format gebracht werden...
    Das könnte zb Visual Basic oder sonst was sein...
    Weiß jemand in welche Sprache das konvertiert wird, würds nämlich sehr gerne mal mit dieser Sprache öffnen, um den unterschied zwischen autoit und einer anderen programmsprache zu sehen^^
    Oder hab ich mir da ein komplett falsches Bild gemacht?

    AutoIt ist zwar in C++ geschrieben, das funktioniert aber anders:
    Beim "Kompilieren" packt der "Compiler" den Interpreter zusammen mit dem Skript in eine exe-Datei. Es wird also eigentlich garnicht kompiliert.

    Twitter: @L3viathan2142
    Benutze AutoIt persönlich nicht mehr, da ich keinen Windows-Rechner mehr besitze.

    "Richtig" compiliert wird ja bei Autoit nicht.
    Das Skript muss durch einen Interpreter, der das Skript in C++ übersetzt.

    Dieser wird bei der .exe mitgeliefert und somit kann das Skript auch auf Computern ohne Autoit-Installation genutzt werden.

    Hi,
    die *.EXE ist bereits das "Windowsstandardisierte Format". In der Exe steht der ausführbare, für den Prozessor lesbare Code, welcher normalerweise von einem Compiler erzeugt wird.
    Bei AutoIt kommt noch etwas anderes hinzu. In der von AutoIt "compilierten" Exe steht nicht ein "richtiges" Kompilat des Scriptes in Maschinensprache, sondern grob gesagt ein Interpreter mit angehängtem Orginalscript.
    D.h. beim Start der *.EXE wird der Interpreter geladen, dieser lädt wiederum das "Script" und arbeitet es ab....
    Daher ist/war es möglich den Scriptcode aus der EXE herauszubekommen, was bei "richtigen" Compilern nicht funktioniert.

    • Offizieller Beitrag
    Zitat von nuts

    "Richtig" compiliert wird ja bei Autoit nicht.
    Das Skript muss durch einen Interpreter, der das Skript in C++ übersetzt.

    Nur um das klarzustellen, weil es auch zur Ursprungsfrage gehörte: Konvertiert wird eben nichts. Ein Programm in C++ (der genannte Interpreter) arbeitet das Skript Zeile für Zeile ab. Es gibt auch intern keine Version des Quelltextes in einer anderen Sprache.

    Johannes

    Ok wenn wir schon dabei sind. Diesen Punkt verstehe ich nicht so richtig.
    Das Autoit Skript muss ja in eine Form gebracht werden, die der Prozessor lesen kann.
    Dies macht der Interpreter, d.h. der output vom Interpreter liegt schon in einer "anderen Sprache" vor.

    Wieso greift man diesen output nicht ab? Autoit ist doch deshalb so "langsam" weil das Skript zur Laufzeit interpretiert werden muss.

    ah oke..sehr interessant das mal zu lesen...gibts dann Möglichkeiten das Skript trotzdem in ein C++ format zu bringen?
    also das man es auch mit einem C++ editor öffnen kann, oder wiederspricht sich das irgendwie mit diesen interpreter?

    jaa schon^^
    aber wenn ich nen c++ editor öffne, wird der ja garantiert auch nen interpreter mit reinlegen, aber es geht mir auch hauptsächlich darum den Quellcode von AutoIt mal in einer anderen Skriptsprache zu sehen...rein aus neugier, wie dort so die sachen aufgebaut ist, obs komplizierter ist, bla bla^^

    Du kannst dir die Exe mit einem Debugger/Disassembler anschauen. z.b. Win32dasm oder olly. Dabei wird der binärcode wieder auf assembler-code abstrahiert.

    MFG FireFlyer

    *Paradox ist, wenn man sich im Handumdrehen den Fuss bricht* :D

    Ok, um das mal ein bisschen weiter auszuführen...
    Die einzige "Sprache" die ein Prozessor direkt versteht ist die Maschinensprache. Da es aber relativ mühselig und unübersichtlich ist in Maschinensprache (Assembler) zu programmieren und auch jeder Prozessor andere Maschinensprachebefehle hat, wurden die sogenannten "Hochsprachen" erfunden.
    Das heisst, irgendwann hatte ein Programmierer die Nase voll von reihenweise Stack-gefummel, Bitschieberei und Speicheradressenabzählerei in Maschinensprache und wollte gleichzeitig auch noch ein Programm, welches mit identischem Code auf verschiedenen Prozessoren lauffähig war.
    Er wollte Code haben, der auch von Nichtprofis relativ leicht lesbar und einfach änderbar war. Nun musste dieser Code aber in die Maschinensprache übersetzt werden, damit der Prozessor überhaupt etwas damit anfangen konnte. Nun gibt es zwei Möglichkeiten:

    1). Der "Übersetzer" liest das Hochsprachenprogramm ein, analysiert es komplett und übersetzt es ein fix- und fertiges Maschinespracheprogramm. Das hört sich simpel an, tatsächlich war diese Prozedur (und ist nach 40 Jahren m.E. eher schlimmer als besser geworden) ein aufwändiges Unterfangen.
    Der sogenannte Compiler wandelt also einen Hochsprachenquelltext (C,Basic, Fortran uswusf..) in ein eigenständig lauffähiges Maschinespracheprogramm (*.EXE oder *.COM-Datei) um, welches man NICHT in eine Hochsprache (ausser in Assembler) zurückverwandeln konnte. Der Quellcode ist nicht auf Anhieb nachvollziehbar.

    2.) Da ein "einfaches" compilieren schon relativ aufwendig war (lange Laufzeiten des Compilers und Linkers) wurde oft eine andere (einfachere) Variante bevorzugt. Der Interpreter hat den Quellcode abgearbeitet und zur Laufzeit die Befehle analysiert und ausgeführt. Das hat zwar von der Ausführungsgeschwindigkeit etwas länger gedauert, dafür konnte man sofort (ohne den langwierigen Compilerlauf) mit dem Programm loslegen und auch das debugging vereinfachte sich enorm. Nachteil: für jedes Programm im Quellcode war auch zwingend der Interpreter (also mindestens zwei Dateien) notwendig. Weiterhin war der Quellcode von jedem einsehbar.

    Mittlerweile gibt es reihenweise Zwischenlösungen, etwa Java und teilweise auch .Net, welche in einen "Pseudocode" übersetzt werden. Der Vorteil liegt auf der Hand, egal welche Prozessorarchitektur verwendet wird, wenn es für diesen Prozessor einen Pseudocode in Maschinesprache-Übersetzer gibt, dann ist das Programm auf diesem Prozessor lauffähig.(Soweit die Theorie :rofl: )


    AutoIt ist eine der cleveren Lösungen! Das "compilieren" dort macht aus dem Quellcode keine Maschinesprache, sondern packt nun einen Interpreter und den etwas aufbereiteten Quellcode zusammen in eine Datei! Wenn man also eine per AutoIt "compilierte" EXE startet, dann startet der darin enthaltene Interpreter und führt den ebenfalls in dieser Datei enthaltenen Quellcode aus.

    Zitat

    gibts dann Möglichkeiten das Skript trotzdem in ein C++ format zu bringen?

    schreib "einfach" einen AutoIt2C-Konverter, und du wirst viele Freunde haben^^.
    Es gibt schon reihenweise solcher Konverter von einer Hochsprache in eine andere, einer der bekannteren ist z.B. BCX

    Zitat

    Wieso greift man diesen output nicht ab? Autoit ist doch deshalb so "langsam" weil das Skript zur Laufzeit interpretiert werden muss.

    Die einzige Alternative wäre ein "richtiger" Compiler, welcher direkt den AutoIt-Code in Maschinensprache transferiert. Ob dieses Projekt irgendwann angegangen wird, wage ich zu bezweifeln. Mehrere hunderte Mannjahre (unbezahlte) Entwicklung in ein Projekt zu stecken damit vielleicht ein Promille der Anwender ein "schnelleres" Script haben, halte ich für überflüssig. Wer mit aller Gewalt ein SCHNELLES Programm braucht kann (soll) sich auf dem Markt an einem der vielen Compiler orientieren oder die benötigten "schnellen" Funktionen in AutoIt per Assembler ausführen. Das nötige Knowhow natürlich vorausgesetzt :D

    Zitat von Andy

    Die einzige Alternative wäre ein "richtiger" Compiler, welcher direkt den AutoIt-Code in Maschinensprache transferiert. Ob dieses Projekt irgendwann angegangen wird, wage ich zu bezweifeln.


    Genau den Punkt verstehe ich nicht.
    Schließlich gibt es diesen Übersetzer ja schon (der Interpreter).
    Wieso muss zwingend zur Laufzeit interpretiert werden? Wieso nicht (einmalig) davor?

    Zitat

    Genau den Punkt verstehe ich nicht.
    Schließlich gibt es diesen Übersetzer ja schon (der Interpreter).
    Wieso muss zwingend zur Laufzeit interpretiert werden? Wieso nicht (einmalig) davor?

    Weil das "zur Laufzeit interpretieren" relativ einfach ist. Du musst nur den Code analysieren und dann das was dort steht per (in diesem Fall C) eigenem Befehl ausführen. Im Prinzip könntest du einen C-Interpreter in AutoIt schreiben.

    [autoit]

    #include <String.au3>
    $zeile_C=' printf("Fehler: Datei nicht gefunden.");' ;eine Zeile C-Code

    [/autoit][autoit][/autoit][autoit]

    if stringinstr($zeile_C,"printf") then
    $a=_stringbetween($zeile_C,"printf(""",""");")
    consolewrite($a[0])
    endif

    [/autoit]

    So, jetzt schreib das mal so in Maschinesprache, daß es ausführbar in eine Datei geschrieben werden kann....wie gesagt nicht "interpretiert" sondern in reiner Maschinensprache! Ich hab mir mal die Mühe gemacht^^. Damit man mal sieht wie kurz ein Programm in Maschinensprache sein kann (43 Byte abzüglich 21 Byte Text^^) , als *.COM-Datei am besten auszuführen auszuführen in einer DOS-Box.
    autoit.de/wcf/attachment/6797/ ich musste die Datei zippen, weil *.COM Dateien nicht hochgeladen werden dürfen^^