Beiträge von Andy

Die AutoIt-internen Funktionen sind größtenteils WinApi-Calls oder aus den gängigen Biblotheken entnommen. Da wirst du nur sehr schwer etwas beschleunigen können.
Mit Sicherheit gibts für 99,8% der in AutoIt verwendeten Funktionen das entsprechende C++-Pendant.
Warum also die unkomplizierten AutoIt-Funktionen in C++ übertragen wenn´s die sowieso schon gibt?
Weil sie "einfacher" zu handhaben sind als C++? Nunja, wenn AutoIt einfacher ist als C++, aus welchem Grund sollte man dann alles nach C++ transferieren?
Es gibt nur einen Grund, hockkomplexe mathematische Berechnungen dauern bei AutoIt etwas länger, na und? Dann schreibt man sich eine DLL in einer beliebigen anderen Hochsprache und bindet diese dann ein.

Wenn ich Threads wie diesen (oder auch einige im amerikanischen Forum) sehe, die bspw. AutoItX in C includieren wollen, frage ich mich ernsthaft, was das soll....

Wie in Dietmars Link schon erklärt, hatten Dll´s ursprünglich die Aufgabe, Platz im Hauptspeicher zu sparen und Funktionen mehreren Programmen zugänglich zu machen. Eine Dll war als "Funktions-Bibliothek" gedacht.

Eine Programm-Funktion, die NICHT oft benutzt wurde, war z.B. in einer Dll enthalten. Wollte man nun diese Funktion aufrufen, hat man die Dll geladen, die Funktion ausgeführt und die Dll wieder entladen.
Weiterhin sind Dll´s eine einfache Methode, OFT gebrauchte Funktionen (s. die WinAPI-Funktionen) mehreren Programmen gleichzeitig zugänglich zu machen. So braucht nicht jeder Programmierer das Rad immer wieder neu zu erfinden (obwohl die allermeisten das machen...) sondern kann von den bereits ggf. sogar schon im Speicher stehenden Funktionen profitieren.

Mittlerweile werden die Dll´s zu fast allem mißbraucht. Bevor man heute eine schon bestehende Dll bzw.die darin enthaltene gesuchte Funktion zu seinem Problem gefunden hat, hat man meist schneller eine eigene geschrieben.

Noch ein kleines Beispiel, um ein "Negativ" zu erzeugen, wie es der ein- oder andere vielleicht noch von "richtigen" Fotos kennt....

und als Bytecode ohne FASM-UDF

Zitat

Ich habe mir das durchgelesen und auch so gemacht wie er es geasgt hat

aha...durchgelesen...

Zitat

geht aber trotzdem nicht

woran das wohl liegen mag?
Etwa daran:

Zitat

EDIT: @error gibt immer 10049 zurück
So mache ich das

Da ist dann wohl jede weitere Antwort überflüssig. Wer nicht in der Lage ist, eine einfache "Gebrauchsanweisung" Schritt für Schritt auszuführen, sondern irgendwelchen Mist verzapft ohne zu wissen was er da gerade tut und dann noch frech behauptet "geht aber trotzdem nicht", der disqualifiziert sich selbst für jede weitere Hilfestellung. Lernresistenz sollte nicht auch noch weiter unterstützt werden...

Glücklichen Herzwunsch zum Geburtstag!

Und die besten Wünsche für Gesundheit und Wohlbefinden! Auf dass AutoIt.de noch lange Zeit so spitzenmäßig betreut werden wird!

Schau mal hier unter "Kreuzpeilung". Sobald du mit einem Handy (oder Laptop mit UMTS-Stick) in einer Funkzelle angemeldet bist (und meistens nicht nur in einer, sondern in mehreren) ist diese Peilung relativ einfach möglich. Weiterhin sollte jedem klar sein, daß der Standort des Handys von den Providern/Funknetzbetreibern über einen längeren Zeitraum aufgezeichnet wird (incl. sämtlicher Daten, die das Gerät identifizieren! )

_WinAPI_SystemParametersInfo()

oder in einem Consolenfenster mit SET var=wert
Mach mal eine "Eingabeaufforderung" (DosBox) auf und gib mal SET ein

AspirinJunkie, volle Zustimmung in allen Punkten!
Wie man sich die "Hacker und Cracker" erfolgreich vom Hals hält demonstriert zzt Apple. Die Programme sind entweder so billig (Apps für den Ei-Kram) daß sich ein Hack/Crack überhaupt nicht lohnt, oder dermassen "gehyped" (z.B. die Apple Standardanwendungen in Firmen), daß sich jeder zu Tode schämt, der nicht spätestens 1 Woche nach release die tolle neue Verpackung der allerneuesten Version auf dem Schreibtisch stehen hat!

chip, hast Recht, ich sollte meine Aussage ändern zu "Genau aus diesem Grund verschwanden auch die schweineteuren Hardware-Dongles bei für jedermann nützliche/verwendbare Software"

"Wir Klosterschwestern" sollten uns hier nicht streiten^^
Aber ich hake trotzdem nochmal nach

Zitat

dann sind wir aber beim Verändern des Binärcodes des Programmes ("Cracken") - im Gegensatz zum hier behandelten simplen Auslesen ( Stichwort "KeyGenerator").

wobei wir uns absolut eing sein sollten, daß auch jemand der "nicht in Mathe aufgepasst hat", wesentlich einfacher einen "Keygenerator" aushebeln bzw auskommentieren kann, als nachzuvollziehen, was der Code eigentlich macht!
Über Methoden, "sichere" Keys zu generieren, referieren hochintelligente Professoren mehrere Semester lang, wie man allerdings Sprungadressen in Programmen "verbiegt" und so die Passwortabfrage umgeht, dafür gibts sehr gut gemachte 5-Minuten-Tuts auf Youtube!

Zitat

Allerdings gibt es, wenn man bisschen in Mathe aufgepasst hat, Funktionen welche nicht invertierbar sind...

was dich nicht dagegen schützt, mit einem einfachen Abändern der Sprungadresse die "Passwortabfrage" (incl sämtlicher von dir beschriebenen "Schutzfunktionen") auszuhebeln. Genau aus diesem Grund verschwanden auch die schweineteuren Hardware-Dongles (erinnert sich noch jemand an reihenweise aufeinandergesteckte Dongles an der parallelen Schnittstelle^^ ? )
Fakt ist, man kann es als Programmierer dem Angreifer etwas schwerer machen, aber gänzlich "sicher" bekommt man sein Programm nie!
Eine sehr gute Schutzmethode, nämlich selbsmodifizierender Code, wurde ja leider seitens der Programmiererschaft "geächtet" und als "kein guter Programmierstil" bezeichnet. Ob das von denjenigen Programmierern initiiert wurde, die nicht in der Lage sind, selbsmodifizierenden Code nachzuvollziehen, lasse ich jetzt mal dahingestellt
Selbstmodifizierender Code erfreut sich bei den "guten" Virenprogrammierern jedenfalls steigender Beliebtheit. Was allerdings durch die Speicherverwürfelung und diverse andere Schutzmechanismen wieder kompensiert wird.

Wer mit genug Penetranz, KnowHow und dem Willen gesegnet ist, lange durchzuhalten, der "knackt" jedes Programm! Ob sich dieser Aufwand allerdings bei einem (ich lege mal den Finger in die Wunde) "WoW-Angelbot bei Ebay für nur 4,99!" lohnt?

Hi,
der ADD ESP,12 holt die 3 Parameter vom Stack, nichts ungewöhnliches, da cdecl-konform. Wenn das allerdings die gecallte Funktion (wie z.B. die WinAPI-Funktionen) schon gemacht hat, dann geht das natürlich in die Hose!
Abhilfe ist in C++, die Funktion statt in cdecl in stdcall aufzurufen (falls das klappt, hab keine Ahnung von C++), dann lässt der Compiler den Stack nach dem Call hoffentlich in Ruhe!

Zitat

WinWaitActive ( "Unbennant - Editor" )

RECHTSCHREIBUNG FTW!
Wegen so einem Müll einen Thread aufzumachen....schon mal was von FEHLERSUCHE in einem Script gehört?

Wie gesagt, bringt dann evtl. etwas, wenn man die "passende" Anwendung hat. Siehe Beispiel "Pixelsearch" im Assembler-Tut, das macht auch nichts anderes als Bytes zu suchen....

Habe einige Testläufe gemacht und meine Befürchtungen wurden leider bestätigt.
Das Problem ist nicht der (wirklich sauschnelle) Assemblercode, sondern AutoIt, daß bei einem Dll-Aufruf eine KOPIE der Variablen übergibt/zurückgibt. Da dafür gerade bei extrem großen Strings (habe den gesamten Speicher ausgenutzt) entweder ein Memory overflow, oder eine Auslagerung auf Platte erfolgt, und das Speichergeschaufel SEHR viel Zeit braucht (bei mir ca 1 Sekunde! ) steht das in keinem Verhältnis zur eigentlichen Laufzeit des Assemblercodes. Ich hatte Testweise den Speicher mit einem String gefüllt >>100MB und alle darin enthaltenen Zeichen ersetzt, der absolute worst case also. Die Laufzeit betrug ca 50 ms. Bis allerdings AutoIt den String in die Ausgabevariable kopiert hatte, waren ca. 1-2 Sekunden vergangen!
Darauf gekommen bin ich, als ich die Stringadresse an das Assemblerscript übergeben hatte und dort nur ein einfaches RET aufrief. Da dauerte der Dll-call über eine Sekunde! Man kann das Vermeiden, indem man eine Struct anlegt und den superlangen String dort hineinkopiert. Allerdings dauert das natürlch genausolange, als wenn AutoIt den String selbst kopiert.....Das wäre also nur dann hilfreich, wenn man immer im selben langen String suchen/ersetzen würde. Weiterhin darf man den String keinesfalls per Rückgabeparameter "str" an AutoIt zurückgeben, da dann eine weitere "Kopie" erstellt wird!

Zitat

hab da noch was im internet gefunden

Da wir hier nicht im Kindergarten sind, wo man den anderen die Würmer aus der Nase zieht, letzte Chance!
Entweder du bringst für uns nutzbare Informationen, oder es gibt keine Hilfe. DU willst schliesslich etwas von UNS!

Ohne weitere Infos/Geräteinformationen/Treiber/API usw kann dir hier wohl keiner helfen.

Du kannst ja einfach mal eine PDF in einem beliebigen Editor (kein PDF-Viewer) öffnen und nach "ISBN XXXYYYYYZZZZZ" bzw "ISBN" im PDF-Quelltext suchen. Ist die ISBN auch dort hinterlegt, kann man per AutoIt (wie vonm Doc beschrieben) darauf zugreifen.
Ansonsten besteht die Möglichkeit, so du denn die Vollversion von Adobe Acrobat hast, z.B. per

$App = ObjCreate("AcroExch.App")

direkt PDF-Dateien zu bearbeiten.
Weiterhin könnte man den Reader mit AutoIt "fernsteuern" und Textpassagen wie z.B. die ISBN auslesen.
Du siehst, Möglichkeiten gibt es viele^^

Hallo Alina,
das hört sich so an, als ob du die "nur" 60000 Datensätze von Hand umschreiben wolltest....
Wie bereits geschrieben, schreit das nach AutoIt!
Ich würde mir zu allererst eine Validitätsprüfung schreiben, die sämtliche "Fehler" anzeigt, wie z.B. "Strase","straße", die dänischen "Sonderzeichen" usw.
Weiterhin würde ich sämtliche Excel-Adress-Listen zuerst in (wesentlich schneller handhabbare) Textdateien (CSV, oder was dir auch immer einfällt) umwandeln. Formeln usw inclusive.
Daß das hantieren mit 20k Zeilen in Excel kein Spass ist war für mich übrigens schon vor 15 Jahren ein Grund, dieses "Standardprogramm" in die Tonne zu treten und mir damals für den Preis von drei Excel-Lizenzen 15 StarOffice (heute OpenOffice) Lizenzen zu kaufen und damit eine komplette Firmenanwendung zu programmieren, die heute übrigens immer noch problemlos läuft. Aber das nur nebenbei als Tip, wenn Excel Probleme macht und nicht SEHR spezielle Funktionen in den Tabellenblättern aufgerufen werden, hilft es ggf. die XLS-Datei mit OO zu öffnen und damit zu bearbeiten. Der Excel-Import/Export Filter von OO ist mir in den letzten Jahren nie negativ aufgefallen.

Der "Poti" ist eine sehr schöne Idee!
Was hälst du davon den aktuellen "Füllgrad" als "Tortenstück" im inneren des Potis darzustellen (grün/gelb/rot je nach Füllgrad)