Hi,
bei einem anderen Thema hier, ist mir die Frage gekommen, warum eigentlich noch 32bit Versionen meiner Skripte erstellen?
Momentan erzeuge ich nur 32bit Skripte. Wenn es zu Problemen kommt, kommt noch eine 64bit Version hinzu.
Ist das sinnvoll?
Hat man Nachteile, wenn man nur 64bit Versionen erzeugt? (Klar die laufen nur unter 64bit OS).
Wie handhabt ihr das?
Bin gespannt auf eure Erfahrungen damit
Hat man Nachteile, wenn man nur 64bit Versionen erzeugt? (Klar die laufen nur unter 64bit OS).
Es kann bei Bugs zu Crashes bei den 64-Bit DLLCalls kommen (wie bei _GDIPlus_EffectCreate z.B.)
Der einzige "Nachteil" der mir einfällt ist, dass 64-Bit Exen größer sind aber das ist vernachlässigbarer Unterschied.
Ich habe bis jetzt keinen echten Geschwindigkeitsvorteil mit den nativen AutoIt Funktionen messen können. Ansonsten sehe ich auch keinen Nachteil x64 Programme zu erstellen.
x32 läuft auch auf x64 BS, aber eben nicht umgekehrt.
Bugs entstehen nicht, weil x64, sondern weil man nicht richtig getestet hat. 
Naja, ich würde meinen wenn die x64 Versionen keinen Vorteil bringen, dann kann man ja auch bei den x86 Versionen bleiben, ausser man muss unbedingt den ganzen verfügbaren Speicher ausnutzen,
dann ist eine 64-Bit Version unverzichtbar.
Ausserdem laufen die 32-Bit Versionen auf den meisten Systemen, es wurden auch enorm viele
Windows 7 und Windows 8 Versionen als 32-Bit Version an den Mann (die Frau) gebracht.
Deshalb behalte ich immer die Sourcecodes gut auf, dann kann ich immer nach der jeweiligen
Situation entscheiden ob 32-Bit oder 64-Bit besser ist.
Bei reinem AutoIt-Code bleibe ich auch bei der 32-Bit-Version. Die AutoIt-Limits (siehe Hilfe) treffen sowieso auch auf die X64-Version zu (bis auf MAXCALLRECURSE).
In Assembler ist das etwas anderes, aber bei reinem AutoIt-Code sehe ich keine gravierenden Vorteile bei der X64-Version.
Da AutoIt als reiner Interpreter auf den Bibliotheken der M$-Compiler basiert, gibt es definitiv KEINE Vorteile einer 64-Bit-Version eines Scriptes gegenüber einer 32Bit-Version.
Vorteile von 64Bit würden ja implizieren, dass für die erstellten Funktionen (aus den Bibliotheken) anderer, d.h. schnellerer bzw. auf 64-Bit optimierter Code GESCHRIEBEN (NICHT(!) compiliert (!) ) wurde. Und das ist mal definitiv nicht so!
Nur weil ein Programmierer einen Compiler mit einem Häkchen in den Einstellungen dazu zwingt, explizit für eine 64-Bit-Plattform zu kompilieren, entstehen keine Wunder. Der auf die Verwendung mit 8088/86-Prozessoren geschriebene Sourcecode wurde nicht verändert, somit bleibt dem Compiler nur die Möglichkeit, geringfügig (!), bspw. durch Verwendung einer größeren Anzahl zur Verfügung stehenden Registern, den compilierten Code anzupassen.
Wenn man allerdings 64-Bit-Programme für einen Compiler SCHREIBT(!), dann kann man auch Faktor 2-3 , ggf. auch noch mehr, an Geschwindigkeit aus der Hardware herausholen.
Imho machen ja die Programmierer in den Hochschulen und Forschungseinrichtungen der Industrie gerade vor, wie man solchen Code schreibt. Google/Amazon/Intel kaufen seit geraumer Zeit humanoides Know-How in Form "kleinerer" Firmen, welche den "großen" zeigen wo der Hammer hängt (bzw. hängen KÖNNTE)!
Die Softwareindustrie ist nicht mal annähernd in der Lage, aktuelle oder auch 10 Jahre alte Hardware optimal zu nutzen. Braucht sie auch nicht. Wenn du willst, dass das Programm 10% schneller läuft, kauf für 500€ einen neuen Prozessor. Damit ist der Softwarehersteller aus dem Schneider. DEN würde es nämlich Millionen kosten, sein Programm 10% schneller zu machen. Abgesehen davon dass er das gar nicht KANN, denn WER sollte das "schnellere" Programm bzw. den Code dazu erstellen? Wenn der vorhandene Programmierer dazu in der Lage wäre (Compilerschalter anhaken reicht wie gesagt nicht), dann würde er das sowieso schon tun. Oder etwa nicht?
x32 läuft auch auf x64 BS, aber eben nicht umgekehrt.
Und wenn es keine Vorteile gibt, wieso dann benutzen?
Naja, ich würde meinen wenn die x64 Versionen keinen Vorteil bringen, dann kann man ja auch bei den x86 Versionen bleiben, ausser man muss unbedingt den ganzen verfügbaren Speicher ausnutzen,
dann ist eine 64-Bit Version unverzichtbar.
Generell stellt sich dann die Frage, ob ein/der (AutoIt-) Interpreter die richtige Wahl für ein Programm darstellt!?
Wenn man mehrere Gigabytes Speicher mit einem Script/Programm (NICHT API-Funktionen(!)) bearbeiten muss, dann ist ein Compiler sowieso "must have". Dann noch für 64Bit compiliert/optimiert, und der Geschwindigkeitsvorteil zu AutoIt liegt bei Faktor 100 bis 1000. Und ob das Compilat nun 80kb groß ist oder 800kb interessiert heutzutage auch niemanden mehr^^
Für die generelle Verwendung von AutoIt spricht die schnelle und einfache Code-Erstellung und die vielen Vorteile wie bspw. der Variant-Datentyp, GUI-Erstellung, Arrays, fast die komplette Win-API ist gewrappert (nicht zu vergessen dieses hervorragende Forum 
) uswusf.
Wer "hardcore" 64-Bit-Software schreiben will, soll sich an einen für alle Sprachen/Dialekte erhältlichen Compiler halten!
Aber so ein Problem wie hier ist zumindest bei mir nur mit einer 64Bit-exe zu umgehen.
Wenn es funktioniert, dann mach es!
Allerdings hat das imho nichts mit dem Unterschied 32/64-Bit AutoIt-"*.EXE" zu tun, sondern eher mit Win10 und deiner individuellen Konfiguration.
Wenn das Problem bei anderen nicht auftritt hast du für dein System einen Workaround gefunden, das eigentliche Problem aber nicht gelöst. Glücklicherweise hat AutoIt die Option dazu^^
