Beiträge von Andy

Über die WMI gibts da einiges, hier mal beispielsweise rauskopiert aus AutoIt-Scriptomatic gefiltert nach "user" ergab u.a. einen Treffer Win32_LoggedOnUser
Das Script wurde komplett von Scriptomatic erstellt

Hi, der Tip mit der prospeed.dll kam ja von mir, ich habe mich jetzt schon einige Zeit mit deinem Problem rumgeschlagen. Ich hatte mal eine funktionierende Lösung, allerdings weiss ich nicht mehr, ob das in AutoIt war
Ich bleib am Ball und suche weiter....

hast du dir die gesamte prospeed-software runtergeladen? Da ist Hilfedatei und Demo usw dabei..

Zitat von progandy

Edit: Ich hab mal 2 weitere Buttons erstellt und die Funktion etwas optimiert, ich hoffe dass das in Ordnung geht

Und wie das in Ordnung geht!

Zitat von sprenger120

Ich persönlich finde das die GUI eigentlich ganz i.o. ist. Es soll ja ein Debugger sein und kein Kanidat für Germany's Next Topmodel

eigentlich braucht man doch idR nur die Register und die Flags, ggf noch den Stack, da kann die "normale" GUI recht klein und übersichtlich bleiben.
Um die Register der FPU und /oder XMM darzustellen, könnte man entweder weitere Buttons anhängen, oder bspw. per Parameter in der _ASMDBG_("-XMM") oder _ASMDBG_("-FPU") einschalten.
Den XMM-Teil würde ich gerne sowieso noch grösser machen, weiterhin könnte man dann auch per _ASMDBG_("-MEM0xABCDEFAB") einen Speicherbereich darstellen.

Zitat

die .bin-Datei sollte aber noch gelöscht werden

wenn man wollte, könnte man den darin enthaltenen Programmcode "normal" mit einem Debugger (wie z.B. IDA Pro free) debuggen oder in andere Programme "einfügen" *husthusthust*, oder sogar als lauffähige *.com-Datei umbenennen...

Hi,
in der prospeed.dll ist Wegefindung auch in komplizierten Labyrinthen integriert.

Hallo zusammen,

AssembleIt ist ja schon ein guter Weg, Assemblercode in AutoIt zu integrieren. Allerdings besteht immer das Handicap, dass der Assemblercode nicht so funktioniert wie er soll.
Welcher Wert steht in welchem Register, wie siehts zzt auf dem Stack aus, wie ist der aktuelle Zustand der Prozessorflags, warum stürzt der Code ab?
Die Antwort auf diese Fragen war bisher nur durch Klimmzüge herauszufinden, daher habe ich mir gedacht, schreib mal schnell einen Debugger, der diese Daten während der Laufzeit des Programms anzeigt.....
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Dazu war nötig, aus dem Assemblerscript während der Laufzeit in eine AutoIt-Funktion zu springen und die Daten im DEBUG-Fenster anzuzeigen, also das Script dort "anzuhalten". Soweit nicht sonderlich schwer, allerdings ergab sich das Problem, dass das in der Callbackfunktion angezeigte DEBUG-Fenster wohl Probleme mit dem Messagehandler von Windows hatte. Wenn man versucht, per GuiGetMsg()- oder Endlos-Schleife Nachrichten zu bekommen, erscheint die gefürchtete "Keine Rückmeldung"-Nachricht im Fenstertitel.
Dies konnte umgangen werden, indem ein Fenster mit eigenem Messagehandler, ein sog. "modales" Fenster angezeigt wurde, z.B. eine Messagebox. Erst nach schliessen dieses modalen Fensters läuft das Script und somit der Assemblercode weiter. Dank progandys Hilfe gelang es, dieses modale Fenster als Button auszubilden (ein Control wird Windowsintern wie ein Fenster behandelt). Danke dafür!

Daher "hängt" der "NEXT...."-Button so seltsam unter dem Fenster....
Apropos, um die Debug-GUI zu schliessen d.h. das ASM-Programm läuft dann ohne Stop bis zum Ende, RECHTSKLICK auf den Next-Button, das ist nicht schön, aber selten....
/EDIT/ progandy hat freundlicherweise eine "3-Button-Version" geschrieben (siehe Bild oben), damit lässt sich der Debugger während der Runtime des Assemblercodes ausschalten (End Debugging) und auch der gesamte Prozess schliessen (Kill)

Anwendungs Beispiel:
Um die Debug-Gui anzuzeigen reicht es, mitten im Assemblercode die Zeile

_ASMDBG_()

einzufügen. Dann hält das Assemblerprogramm an dieser Stelle an und zeigt die Debug-Gui. Mit Linksklick auf den "Next..."-Button oder Betätigen der "Enter"-Taste gehts dann weiter bis zum nächsten _ASMDBG_()

Als Goodie kann man noch einen Parameter mitgeben, zzt nur die 32-Bit-Register $edi, $esi, $ebp, $esp, $ebx, $edx, $ecx, $eax, und diese mit einer beliebigen Abbruchbedingung versehen!
Bei Einfügen von z.B.

_ASMDBG_("$eax=22")

in einer Schleife läuft der Assemblercode so lange, bis das EAX-Register den Wert 22 enthält und zeigt erst dann das Debug-Fenster an!

_ASMDBG_("$edx>35662")

lässt das Debugfenster erst erscheinen, wenn das EDX-Register grösser ist als 35662.
Alles was innerhalb der Anführungsstriche steht wird als logischer Ausdruck ausgewertet und bei TRUE wird das Debug-Fenster angezeigt!

Bekannte Einschränkungen:

• Die Zeile _("org " & FasmGetBasePtr($Fasm)) ist im ASM-Code erforderlich, sie veranlasst den Assembler den Bezug zu den Adressen richtigzustellen

• DllCallbackFree($_DBG_) sollte am Ende des Scripts aufgerufen werden

• /EDIT 07/04/2011 gelöst durch progandy  Ab und zu gibts einen Fehler, z.B. wird hin und wieder das vorderste Fenster beim Debuggen hinter/unter den NEXT...-Button verkleinert, lässt sich dann aber problemlos wieder vergrössern.

• Bei Verwendung des Debuggers innerhalb einer LOOP-Schleife (im Assemblercode) kommt es zu einer Fehlermeldung, da LOOP nur maximal +-127 Bytes weit springt, aber der intern abgehandelte Debuggercode wesentlich grösser ist. Das kann man umgehen, indem man den "LOOP Sprungadresse" durch
  
  
  Code

  DEC ECX 
  CMP ECX,0
  JNE Sprungadresse

  ersetzt und nach dem debuggen wieder durch "LOOP Sprungadresse" ersetzt. Ggf. baue ich diese Umwandlung sogar in den Debugger ein....

Naja, ganz fertig ist der Debugger noch nicht (welches Programm wird je fertig ), der Code ist total chaotisch, aber ich habe Hoffnung, dass es weitergeht.
Eins noch zum Schluss, ich persönlich finde die GUI echt hässlich, wer da meint, die Aufteilung /Ansicht besser gestalten zu können ist herzlich eingeladen!!!

/EDIT/ Debuggerupdate 12.05.2012

AssembleIt incl. Debugger und Testdatei:
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Zitat

Ich weiß leider nicht, wie ich dem Server sagen soll, das sich ein benutzer abgemeldet hat.

ich löse das so, indem ich in einer Schleife die bestehenden Verbindungen abfrage. Einmal pro Sekunde (alle x Sekunden) reicht da imho völlig.
Das kann man z.B. per AdlibRegister() automatisieren.
Bekommt man innerhalb der Schleife beim Abfragen einen @error, dann nimmt man diesen Client aus der Liste.

Glücklichen Herzwunsch und alles Gute zum Geburtstag!

Glücklichen Herzwunsch und alles Gute zum Geburtstag!

Zitat

kann man Assembler auch anders als in AutoIt programmieren, also in nem eigenen Programm (sowas wie Visual C++ für C++)

Ja, entweder der FASM oder auch MASM, der ist sogar völlig in die Visual-Umgebung zu integrieren, schau mal im MASM-Forum!
Relativ einfach ist es auch, wenn man c++ kann, den Assemblercode zu "inlinen". Da fährt man dann nicht mit Rollschuhen spazieren sondern fügt zeilenweise Assemblerbefehle in den c++-code ein^^

Eins noch, der in AutoIt integrierte Assembler ist bei weitem nicht so Leistungsfähig wie der "echte" FASM. Der kann Macros verwenden, Libs einbinden, DLL´s erstellen, hat eine eigene IDE (*hust*) simpelste Zugriffe auf die Windows-API uswusf...

Das "ASM-Tut" ist von mir nicht für Anfänger geschrieben worden sondern richtet sich an Anwender, die wissen wollen, wie man den Assembler in AutoIt integrieren kann.

Allerdings sind in den ersten Absätzen Artikel und auch sehr gute Tut´s verlinkt, die auch Anfänger ansprechen....
AssembleIt ist imho schon eine Vereinfachung, zzt. ist ein Debugger bei einigen hier im Forum in der Testphase, der es erlaubt, zur Laufzeit der Assemblerprogramme auf Prozessorregister, Flags, Speicher usw. zuzugreifen

Hi,
die Assemblersprache ist einfach gesagt die Maschinensprache, die dein Prozessor direkt verarbeiten kann.
Der Assembler transferiert das Programm in die berühmten Nullen und Einsen, die der Prozessor verarbeitet.
Dabei werden die Prozessorregister gelesen und geschrieben, genauso wie jedes einzelne Bit im Speicher oder einem Laufwerk.

Einen Assembler (guck mal nach, wie das aus Englisch übersetzt wird) nennt man auch das Programm, dass diese Maschinensprache in lauffähige Programme umsetzt.

Ein Compiler dagegen übersetzt aus einer Hochsprache (egal welche) in lauffähigen Code, in dem er das ganze Programm Zuhilfenahme der Assemblerbefehle in Maschinencode übersetzt.
Interpreter (so wie AutoIt) übersetzen die Hochsprachenbefehle (Scripte) Befehl für Befehl nacheinander in die entsprechenden Maschinencodes, die dann vom Prozessor ausgeführt werden. Das so übersetzte Programm läuft idR wesentlich langsamer als ein von einem Compiler (oder assembler) übersetztes Programm.

Mit Assembler bist du am dichtesten am Prozessor dran, ein Assembler übersetzt 1:1 genau das, was du programmierst, in Prozessorbefehle. Ein Bit eines Registers oder Flags falsch gesetzt, zack, Ausnahmefehler. Im heute verwendeten protected mode gibts da glücklicherweise eine Fehlermeldung, früher war ein Hardreset angesagt.
Heutzutage gibt es nur noch sehr wenige Anwendungsfälle für diese Art der Programmierung, wobei Spezialisten immer noch gesucht werden. Die Compiler sind mittlerweile in der Lage, sehr schnellen Code zu generieren. Wenn allerdings sehr kompakter Code erstellt, oder das letzte an Geschwindigkeit aus einem Programm rausgekitzelt werden muss, bietet sich Assembler an.

AutoIt ist ein Interpreter, generiert also im Vergleich zu einem Compiler eher langsame Programme (was man auch nur in bestimmten Bereichen überhaupt bemerkt!). Muss man aber, z.B. für Bildbearbeitung oder komplexe mathematische Berechnungen, sehr schnellen Code erzeugen, bietet sich ein Weg an, Assemblerbefehle 8und damit extrem schnelle Programme) in AutoIt einzubinden.
Ein Tool dazu ist AssembleIt.
Es ermöglicht die Verwendung von x86-Assemblercode innerhalb von AutoItscripten!
Das heisst konkret, das "normale" Script wird vom Interpreter abgearbeitet, bis die AssembleIt()-Funktion erreicht wird. AssembleIt schreibt die vom FASM-Assembler assemblierten Maschinenbefehle aus dem Script in den Speicher, wo sie dann direkt vom Prozessor ausgeführt werden können. Das führt in bestimmten Bereichen zu Geschwindigkeitsverbesserungen um den Faktor 1000, also tausendmal schneller als der gleichwertige AutoIt-Code. Das ist auch der einzige Grund (und ein bissl Wehmut bzgl der "guten alten Zeiten") warum ich (eigentlich just for Fun) Assembler einsetze.

Assembler ist eine eigene "Sprache", da sie sehr einfach aufgebaut ist, auch nicht weiter schwer. Mit ca. 20 Maschinenbefehlen wird sicherlich 90% der heute compilierten Software auskommen. Durch die Verwendung von Macros,Libraries und div. Schleifenkonstrukten ist auch sehr schnelle Entwicklung möglich, da unterscheidet sich Assembler imho nicht mehr viel von einer Hochsprache (mal von den esoterischen Sprachen abgesehen oder Sprachen die auf Software aufsetzen wie z.B Javascript, php usw)

Hi Moritz!
Lade dir doch mal die 30-Tage-trial von DERIVE herunter, damit ist das ein Kinderspiel....
Der Onlinekurs zu DERIVE http://www.austromath.at/daten/derive/

Hab in asm mal ein Grundgerüst gebastelt, in dem man die "Formel" nur noch Eintragen braucht.
Das sollte man auch nur mit Grundkenntnissen hinbekommen (oder fragen wie es geht, wenn man eine Idee hat^^)

Weil es sonst so langweilig wäre, habe ich mal einen "Zoom" eingebaut, per Pfeiltasten hoch/runter.
Wer die Äuglein aufmacht, sieht im Consolefenster wie sich während des "zoomens" die Variable im Bytecode ändert.

Dank AssembleIt kann man die AutoIt-Variablen natürlich auch im asm-code verwenden.
In diesem Fall sollte man, wenn man auf Assembleit verzichten und den CallWindowProc() verwenden möchte, vor dem Call die Variablen direkt in den Bytecode schreiben, Little Endian nicht vergessen

Zitat

Ich bin am überlegen ob ich die Berechnungen, etc in Assembler bringen soll aber wenn Andy oder Sprenger den Code sehen krieg ich eins aufs Dach

Wer sagt das?
Wir profitieren alle voneinander! Jeder kann vom anderen etwas lernen!
Aber unter uns, je mehr Leute hier mit Assembler arbeiten, desto mehr Spass macht es!
Und mit den wirklich einfachen Grafik-Bearbeitungen fällt der Einstieg nicht schwer

Zitat

Nein ich möchte eine beliebige datei in 1kB blöcke splitten, egal welche buchstaben etc drin vorkommen

so?

$a=FileRead("perlin.au3")
dim $block[500];blöcke
for $i=1 to stringlen($a) step 1000
$block[$i/1000]=stringmid($a,$i,1000)
next

Eingabe von
*runden*
als Suchbegriff in die Eingabezeile der AutoIt-Hilfe führt zu einigen Funktionen^^

Hi,
wenn ich das jetzt richtig verstehe, möchtest du aus einer Textdatei mit dem Inhalt
ABABABABAB....
zwei Einzelstrings
AAAAAAA... und BBBBBBB....machen und deise dann nachher wieder "zusammenkopieren"

Dazu könntest du z.B. per fileread den Text in eine variable speichern und diese per

$a=stringsplit("ABABABAB","",3)
_arraydisplay($a)

in einzelne Buchstaben aufsplitten.
dieses array dann in 2 oder auch mehrere Dateien aufzuteilen sollte dann kein Problem mehr sein

$a=stringsplit("ABABABAB","",3)
;oder $a=stringsplit(FileRead("textdatei.txt"),"",3)
$ersterstring=""
$zweiterstring=""
for $i=0 to ubound($a)-1
if mod($i,2)=1 Then
$ersterstring&=$a[$i]
else
$zweiterstring&=$a[$i]
endif
next
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ersterstring = ' & $ersterstring & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $zweiterstring = ' & $zweiterstring & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

Raupi

Zitat

Meistens spinnt dann die Clientanzeige vollkommen rum und das Bild wird invertiert.

Das invertierte Bild war das feedback für ein komplett neues Frame im Falle fehlerhaft übertragener Daten (lost Packets). Das kann aber auch im Script durch Austausch von SRCINVERT in SRCCOPY in ein "normales" Bild abgeändert werden.

Zitat

Mausklick wird mit ca 2-5 Sekunden Verzögerung weitergeleitet.

Das "Hauptproblem" ist das inzwischen abgeänderte Protokoll der Datenübertragung.
Wenn nicht gerade Videos übertragen werden, werden ca. 40-50x pro Sekunde einige Handvoll Bytes (jeweils nur die veränderten Daten und die auch noch komprimiert) übertragen. Da macht es dann garnichts aus, wenn mal Fehler bei der Übertragung auftreten, das nächste Frame gleicht das in Sekundenbruchteilen aus.
Bei Video sieht das dann ganz anders aus. Das Datenpaket ist dann unter Umständen einige hundert kB gross, und dann tritt bei fehlerhafter Übertragung folgendes Procedere auf: Um sicherzustellen, dass der TCP-Puffer definitiv leer ist, habe ich eine Wartezeit von bis zu 2 Sekunden (oder 500ms) eingebaut.
Habe so etwas ähnliches wie einen Handshake eingebaut, aber in der neuesten Version nicht mehr Geschwindigkeitsoptimiert.
Das Ganze schreit natürlich nach kleinen Blockgrößen, schaumal....

Zitat

Nur so nebenbei: habt ihr euch schon zlib / LZ77 angeschaut?

Ich hatte Huffmann als AutoIt-Script laufen (langsam^^), um das Einsparpotenzial herauszufinden. Ehrlich gesagt, lohnt für mich der Aufwand gegenüber der von uns verwendeten Komprimierungsfunktion nicht, welche aus der Windows-API entliehen ist.
Unsere "billige" Lauflängenkodierung und bissl Bitgeschiebe bringen zzt. schon Komprimierungsraten, die ohne größeren Aufwand nicht mehr weiter zu toppen sind. Habe auch testweise einige dll´s ausprobiert, aber ehrlich gesagt halte ich es nicht für nötig, etliche Kilobytes an externer dll anzuhängen, um einige Bytes einzusparen! Wer Videos übertragen will/muss, soll sich dementsprechende Software anschaffen^^

Jedenfalls bleibt noch reichlich zu tun, ich würde gerne den ASM-Teil auf 64 Bit bringen, damit man in Abhängigkeit vom System auch damit compilieren kann.
Das "Mausrad"-Problem ist auch schon in Mache, genau deswegen hab ich das gesamte Protokoll (Handshake usw) umgestrickt.