Beiträge von Andy

Hi,
Oscar , ich kapere jetzt einfach mal deinen Thread...

Anlass ist meine Überlegung, mein XP32, welches mich letzter Zeit nach den M$-Updates sporadisch mit seltsamen "Hängern" nervt, gegen ein Win7/64 einzutauschen. Da die Daten sowieso auf einer eigenen Platte hausen, würde ich gerne das Win7 auf eine SSD installieren und ein Dual-Boot System aufsetzen.
Hat damit schon jemand Erfahrung?
Ist es besser Win7/SSD als "Master" zur BS-Auswahl zu haben oder das XP? Ich frage deshalb weil ich "früher" einfach beim Umzug auf ein neues System die alte Partition auf die neue Platte geklont hatte, reboot, XP hat sich ggf. einige neue Treiber gezogen, aktiviert, fertig. So ist mein "altes" XP schon auf 3 neue Rechner umgezogen
Geht das mit der SSD auch so geschmeidig? Habe schon seitenlange Installationsanleitungen über aligning, kloning, überschreiben von MBR´s und div. Tools überflogen, begeistert bin ich davon nicht...ich würde einen "Platte rein, läuft"-Weg vorziehen!

Zitat

ja schon genug

Zitat

aber nicht mit browsern und proxies

was hat das denn damit zu tun? Du kannst dich auch zwischen einen Fernseher und einen Router hängen...
Sieht wohl eher wieder mal so aus, als ob die Grundlagen völlig fehlen
Zeig mal das komplette Script, sonst werden wieder Stunden und Tage damit verbracht, an Info´s zu kommen und im 62. Post wird dann ein Vierzeiler gepostet der bei Vorlage des kompletten Scriptes im 2. Post gestanden haben könnte!

Hi,
wie Oscar hier schön gezeigt hat, ist es kein Thema, auch in AutoIt 20 "parallele" Funktionen durcharbeiten zu lassen.
Es ist halt, wie meistens, alles eine Frage des Knowhow´s.
Und wenn ich mir die Fragestellung im Startpost anschaue, dann stelle ich mir ernsthaft die Frage ob auch nur rudimentäres Wissen zum Thema "Multithreading" vorhanden ist. Denn auch dieses würde das Problem nicht ansatzweise lösen können....soviel dazu!

Multithreading funktioniert nur mit threadsicheren Funktionen, wer da nicht in der Lage ist etwas entsprechendes zu programmieren, der sollte in jeder (!) Programmiersprache die Finger davon lassen! Oder direkt die entsprechenden WinAPI-Funktionen nutzen....

Glücklichen Herzwunsch und alles Gute!

Hi,

Zitat

crt0 ist die Standardlibrary von C und enthält u.A. hochoptimierte Versionen für strcpy

ehrlich gesagt, dachte ich auch einmal so....

Aber schau mal hier(es geht um die Prozessorbefehle movsb und stosb), wenn du diesen Artikel nicht lesen kannst, renn mal schnell ins nächste Schreibwarengeschäft und lese dir die 2 Seiten in der c´t zu diesem Thema durch....Nur dieser Artikel ist den Preis für das Heft wert!
Da ist ein Sch*** optimiert, gerade im Gegenteil, die Compiler tun alles dafür, eine KORREKTE Antwort auf den Aufruf von memcpy() und strcpy() zu gewährleisten!
Die bisher gefertigten Prozessoren sind nämlich alles andere als fehlerfrei und somit müssen die Compiler "hunderte von Fallunterscheidungen" einbauen, um je nach Prozessor die Bugs zu fixen.
Was dazu führt, dass in den meisten Fällen die Antworten auf die o.g. Befehle zwar immer öfter korrekt ausgeführt werden, aber leider mit dem Handicap von massiv aufgeblähtem Code und langsamer Verarbeitung

Hi,

Zitat

Es gibt eine UDF bei der man Threads erstellen kann die AutoIt Funktionen ausführen!

Die aber nicht funktioniert, da keine der Standard-Funktionen und somit auch kaum ein AutoIt-Script threadsicher ist.
Um threadsichere Funktionen zu gewährleisten und in mehreren Threads in AutoIt zu benutzen würde ich diese Funktionen in einer anderen (threadsicheren) Hochsprache erstellen und bspw. per DLL einbinden.
Multithreading per Inline Asm oder C ist ziemlich easy, Beispiele habe ich hier im Forum schon gepostet.

Hallo Oscar!
Dein Script zeigt perfekt, dass es nur eine "Zeit" und somit nur einen "Timer" gibt
Wer auf das schmale Brett mit Hyperthreading bzw. Multithreading (-tasking) kommt, sollte sich mal fragen, wie diese Technik überhaupt funktioniert....nämlich mit genau EINEM Timer!

Aber einen winzig kleinen Verbesserungsvorschlag hätte ich noch^^

Func _StopAll()
_Timer() ;synchronisiert die Uhren im 10ms-Bereich
For $i = 0 To $iTimerCount - 1

Ohne die Synchronisierung kommt es vor, dass der Stop-event mitten in der For/To-Schleife innerhalb der Timer()-Funktion unterbricht und somit die Uhren zwei unterschiedliche Zeiten anzeigen. Bis zur Unterbrechung bereits die "neue" Zeit, und ab der Unterbrechung noch die "alte" Zeit.

Hi,

Zitat

Ja ich vergaß

wie, "vergaß"?
Schau mal links bei Downloads, OrganizeIncludes, wenn du das nicht installiert und auf eine der F-Tasten gelegt hast, gehört dir ehrlich gesagt nicht mal eine Antwort sondern ein Rausschmiss hier^^
Ich habe seit Jahren keine einzige #include-Anweisung geschrieben! Bevor ich das erste Mal ein Script per F5 starte wird reflexarig auf F2 (bei mir OrganizeIncludes) gedroschen. Thema Konstanten und Funktionen erledigt....

Hi,

Zitat

auch wenn es eigentlich dazu dienen sollte inline C++ einzuführen.

den Versuch gab es ja schon einmal hier

Im Prinzip müsste man nur den C-Compiler includen statt des Assemblers und AssembleIt2() würde zu CIt()

...und selbst wenn so etwas passiert, sollte auch jemand, der nicht sonderlich erfahren in AutoIt ist, in der Lage sein, einen EINFACHEN SYNTAXFEHLER zu erkennen und zu beheben
Und das auch noch, wenn das "richtige" Script vorliegt...

Um das mal DEUTLICH AUSZUDRÜCKEN: Selbst für c&P noch zu blöd!

Hi,

Zitat

Ich will quasi alle paar Sekunden alle Ports abfragen

wenn du so viel Zeit hast, ist das völlig unkritisch!
Ich würde alle x Sekunden einfach eine Schleife laufen lassen, welche jeden der Ports einzeln abfragt und auf das Ergebnis wartet.
Pseudocode:

Dim $var[5]
while Sleep(4000) ;alle 4 sekunden
For $i = 1 to 4 ;4 Ports
TCPSend($ConnectedSocket, "Getport " & $i) ;Anfrage an Socket
$var[$i] = "" ;Variable
do
$var[$i] = TCPRecv($ConnectedSocket, 100) ;Empfangspuffer auslesen
if @error then exit(MsgBox(0, 0, "Verbindungsfehler"))
until $var[$i] <> "" ;so lange, bis etwas gesendet wurde
ConsoleWrite('$var[' & $i & '] = ' & $var[$i] & @crlf);Variablen ausgeben
next
ConsoleWrite(@crlf)
wend

Aha, keine schlechte Idee immer dwords zu verwenden, da hätten gewisse Leute früher drauf kommen können...

Zitat von Cookbook

...Das Geschreibsel vor den Paramtern sollen die Datentypen sein. Jetzt kommt das dunkle Geheimnis: Das
ist totaler Unsinn. Diese Datentypen sind so unnütz wie sonst nichts, weil sie schlichtweg nicht existieren.
In der WinAPI lassen sich alle Funktionen eigenlich mit DWORD, also einem Double ansprechen. HWND
ist DWORD, LPCTSTR ist DOWRD und UINT ist aber wirklich ein ... DWORD.

Hi,
schau mal hier

Eigentlich wollte ich dir Punkte in der B-Note für das "Cookbook" abziehen, da meiner Meinung nach das Thema 16Bit viel zu viel behandelt wurde....
Aber dafür bekam ich im 32Bit-Bereich fast durchgehend ein Grinsen aufs Gesicht gemalt, nur unterbrochen von einigen brüllenden Lachern! Köstlich geschrieben

Den Hammer auf den Kopf-Smilie wirst du von mir nicht sehen, ich habe viel zu viel Respekt vor der offensichtlichen Arbeit die in LASM drin steckt!
(Wobei ich sagen muss, dass AssembleIt2 doch noch etwas schlanker ist, komplett ohne FASM-UDF-Gedöns und ohne dll-file auskommt (lädt die dll aus dem Script direkt in den Speicher) und 64 Bit kann ...../EDIT/ und keine # braucht )
Gesunder Wettbewerb ist klasse

Eine Frage hätte ich noch:
Wieso gibst du bei Jumps das "byte" mit?

jle byte swap

Und wieso bleibst du nicht bei dem "konventionellen" Datentyp,Wert,Datentyp,Wert,Datentyp,Wert bei der Übergabe?

Hi,
feines Projekt

Bei der Installation ist mein Virenscanner ausgestiegen wg. Packer in der LASM.EXE Indiskutabel.....

Die Beispiele funktionieren, allerdings steigt der Assembler aus mit folgender Fehlermeldung wenn im AutoItscript hinter dem Assemblercode die Consolewrite()-Anweisung steht (auch auskommentiert! )

!> [LASM] Error in line 22 (Debug Console): Unknown label: Console
!>17:36:52 AutoIT3.exe ended.rc:-1

Die Line (in diesem Fall 22) ist immer 1 mehr als die Anzahl der #
Steht Consolewrite vor dem Assemblercode ist Line =1

Weitere Tests folgen^^

_GUIScrollBars_ScrollWindow()

draufklicken und in der Hilfedatei das Beispiel nach eigenen Wünschen bearbeiten

Hi,
"ferig" wird es da nichts geben, aber was hindert dich daran den per Scrollbar jeweils ausgewählten Ausschnitt in deiner GUI darzustellen?

Wenn, dann nimm AssembleIt2, das hat einige Features die das "inlinen" schon sehr nahe bringen, bspw. fällt das gesamte FASM-UDF-Gedöns mit Funktionen usw. weg, aus

_FASMADD("move eax,ebx")
;wird
mov eax, ebx

Bei Syntaxfehlern im asm-code wird in Scite direkt in die entsprechende Zeile gesprungen, AutoItvariablen können einfach in den Asm-code geschrieben werden uswusf...spiel mal bissl rum^^

Du kannst auch am Anfang des Scriptes zum Testen per AssembleIt2() den Binär-Code erstellen lassen und später nur mit dllcalladdress() arbeiten, dann musst du, um AssembleIt() wegfallen zu lassen nur noch eine Zeile ändern, s. Beispiel.
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Hi,
"kompilieren" musst du ohnehin...
Der Witz ist aber doch, mittels AssembleIt() incl. Debugger den Code zu erstellen und auszutesten.
Wenn dann der Code einwandfrei funktioniert, DANN erst erstellt man mittels des

$_Assembleit_Flag = 0

vollautomatisch den Binärcode...und kann völlig auf den asm-sourcecode und Assembleit verzichten...

Hi, das hatte ich vor einiger Zeit schonmal umgesetzt, um Buttons auf einer sich verändernden Website anzuklicken. Übrigens sauschnell auch per AutoIt^^, mit asm wars dann unwesentlich schneller...

Selbst animierte Buttons werden gefunden.
PushTheButton

Zitat

ASMinit()
$asm_func=_ASMcreateFunc("_ASMcode")
ConsoleWrite("$asm_func="&$asm_func&@CRLF)

habe ich irgendetwas spezielles in deinem Code übersehen, oder wieso benutzt du nicht einfach

$_assembleit_flag = 0
$ret=_assembleit("int","_ASMcode","int",$w,"int",$h,"ptr",$p1,"ptr",$p2)

das setzen des Flags vor dem Aufruf von Assembleit führt zur vollautomatischen Erstellung von folgendem Code, der dann einfach nur per ctrl+v eingefügt werden muss...

Global $tCodeBuffer = DllStructCreate("byte[199]") ;reserve Memory for opcodes
DllStructSetData($tCodeBuffer, 1,"0x9BDBE38B5C24048B5424088B74240C8B7C241031C0660F6EC089D129C10FAFCB660F6EC931C0660F6ED0660F6FD831C9660F6EE1AD3B077513660F7ED040660F6ED0660F7EC939C87462EB2889D0660F7ED929C80FAFC3660F7EE129C848660F6EF8660F7EC9660F7ED029C1660F7EF839C8721983C704660F7EE14139D972B0660F7ED941660F6ED939D172A1660F7EC0408B74240C8B7C241089C10FAFCBC1E10201CE39D00F8269FFFFFF660F7EC0660F7EC9660F7ED339CB7503C21000B8FFFFFFFFC21000") ;write opcodes into memory
$ret=DllCalladdress("int",DllStructGetPtr($tCodeBuffer),"int",$w,"int",$h,"ptr",$p1,"ptr",$p2)

Damit braucht man dann weder Assembleit, noch FASM!

Btw, die Verwendung von AssembleIt() hat den großen Vorteil, dass man sich in keinem Fall um diese RET_Geschichte kümmern muss...