Beiträge von misterspeed

Erstmal wäre es sinnvoll wenn du mehr als nur diesen Code Schnippsel posten würdest, denn von Checkboxen seh ich da schonmal garnichts. Zu dem was du da gepostet hast:

$msg = GUIGetMsg()

Liefert dir die letzte GUI Nachricht, welche noch nicht zuvor abgefragt wurde (z.B. ein Klick auf einen Button), sofern es keine Nachricht gibt wird 0 zurückgegeben. Da du keine Schleife verwendest um die GUI Nachrichten in sehr kurzen Intevallen abzurufen ist es ziemlich wahrscheinlich, dass du hier an dieser Stelle immer eine 0 zurückbekommen wirst, außer diese Funktion wird in einer Schleife aufgerufen (der Rest des Scriptes fehlt, also keine Aussage hierzu möglich).

$msg = GUIGetMsg()
Switch $msg
Case $msg

Du scheinst den Sinn einer Switch Case Verzweigung nicht verstanden zu haben. Du machst hier folgendes:

1. Du bekommst eine GUI Nachricht $msg (wie oben bereits angedeutet sehr wahrscheinlich nur eine 0)
2. Der Case $msg ist immer erfüllt, völlig egal welchen Wert $msg nun hat, ist ja auch logisch, denn ein "case" einer switch case Verzweigung stellt nur eine if Bedingung von mehreren dar. Solche Verzweigungen sind Sinnvoll wenn man einen Variablen Wert ($msg) mit mehreren verschiedenen konstanten Werten Vergleichen will. So würde es als if Bedingung ausschaun:

$msg = GUIGetMsg()
if $msg = $msg then .... ; das ist immer true!

Du erkennst deinen Fehler?

Poste also bitte mal das ganze Script, dann kann man dir auch Lösungen aufzeigen die eher sinnvoll sind.

Google Suche "autoit owner folder"... erster Treffer:

Dim $objSD
$varFolderName = "C:\Users"
$oWMIService = ObjGet("winmgmts:")
$oFolderSecuritySettings = $oWMIService.Get("Win32_LogicalFileSecuritySetting='" & $varFolderName & "'")
$intRetVal = $oFolderSecuritySettings.GetSecurityDescriptor($objSD)
If $intRetVal = 0 Then
MsgBox (0, "", "Owner: " & $objSD.Owner.Domain & "\" & $objSD.Owner.Name)
Else
MsgBox (0, "", "Couldn't retrieve security descriptor.")
EndIf

Edit:

Funktioniert im Übrigen auch mit Dateien und nicht nur mit Ordnern.

Nett, aber du hast vergessen eine Möglichkeit zum Neugenerieren der Zahlen wärend der Laufzeit einzubauen @ Andy

Zitat von Eistee

jetzt muss ich nur noch herausfinden warum sich der Button nur einmal drücken lässt, und man das prog dann erst neu starten muss für neue zahlen.

Weil du nur einmal am Anfang Zufallszahlen generierst? In deiner create Funktion setzt du nur diese Werte in die Inputfelder, die werden sich zur Laufzeit aber nicht mehr ändern, daher siehst du auch keine Veränderung wenn du mehrmals auf den Button drückst. Schau dir mein Script an, das sollte wie gewünscht bei jedem Klick neue Zahlen erstellen.

Ungetestet und nur schnell im Forum runtergechrieben...

Nice. Genau das Problem habe ich mit meiner Sidebar auch. Werd ich mal bei Gelegenheit testen, danke dafür.

Die meisten Setups bieten im übrigen auch silent Parameter für unbeaufsichtigte Installationen an. Sprich du brauchst dich meist nicht durch irgendwelche Setup GUIs klicken oder ein Script schreiben, dass dir diese Klickerei abnimmt. Gewisse Programme können auch bedenkenlos paralell installiert werden ohne dabei Probleme zu verursachen, dazu zählen z.B. Firefox, Thunderbird und wenn ich mich recht entsinne auch der VLC Player. Vorsicht ist bei Itunes oder anderen aufwendigeren Programmen geboten, diese sollte man tunlichst nacheinander installieren. Reboots sind hingegen normalerweise nicht zwingend sofort nötig, es genügt normalerweise erstmal alles zu installieren und einen einzigen abschließenden Reboot zu machen.

Eine gewisse Grundreihenfolge würde ich immer beachten:

1. OS plus wichtige Grundeinstellungen (z.B. temporär oder dauerhaft den Standbymodus abschalten oder Remotedesktop aktivieren für bequemere nebenher Installation)
2. Chipsatztreiber und alle weiteren Treiber
3. Windows Updates
4. Java / Flash usw.
5. Anwenderprogramme
6. Virenschutz + Backupsoftware
7. Bereinigung des Autostarts und Kontrolle (z.B. diverse automatische Updater entfernen sofern unerwünscht usw.)

Das meiste lässt sich sehr gut automatisieren, manches würde ich eher von Hand machen, auch wenn es etwas dauert. Einen Windows 7 Rechner bekommt man normalerweise in ca. 2-3 Stunden komplett fertig, wobei die meiste Zeit für die Windows Updates drauf geht, daher empfehle ich eine möglichst aktuelle Installations DVD bzw. besser einen USB-Stick mit den aktuellen Servicepacks und Updates. Ich musste sowas auch schon regelmässig machen, man spart auch viel Zeit wenn man 3-4 Rechner remote steuert und paralell einrichtet.

Naja ich würde mir an deiner Stelle einen Developer Account anlegen und mir das Developer SDK anschauen. Das wird aber sehr sicher in C / C++ / C# oder auch Java gehalten sein. Darüber sollte man aber genügend Informationen über die Gerätekommunikation sammeln können um das ganze auch in anderen Sprachen umzusetzen.

https://www.leapmotion.com/developers

Zitat von DaX

Sehr gut kann ich mir vorstellen, dass die meisten beim Spiele entwickeln dabei sein wollen. Jeder möchte Spiele programmieren.

Öhm eher nicht, also meine Wenigkeit kann sich jedenfalls nicht sonderlich für Spiele und erst recht nicht für Spieleprogrammierung begeistern. Ich halte es einfach für Zeitverschwendung, da solch ein Programm keinen wirklichen Nutzen außer Zeit totschlagen hat.

Für administrative Dinge bin ich hingegen schon eher zu haben, aber nicht wenn dabei das Rad neu erfunden werden soll oder das Ergebnis letztlich nur schlechter als der bereits vorhandene Standard werden kann. Ein Remotedesktopersatz in Autoit ist jedenfalls kaum machbar. Es gibt hier sogar ein entsprechendes Projekt (Deskstream?), welches für Autoit wirklich sehr gut und performant geworden ist, aber bei weitem nicht an eine Microsoft RDP Verbindung rankommt.

Wie dem auch sei mir fehlt ohnehin die Zeit um mich an Projekten anderer zu beteiligen, ich komme ja nichtmal dazu meine eigenen Projekte weiterzuführen. Aber da jeder seine Präferenzen und Erfahrungen in bestimmten Gebieten hat sollte man ein Projektteam immer auch Projekt bezogen gründen, denn was nutzt dir nachher ein Team aus drei Gamern einem Admin und einem Autoitanfänger wenn du dann letzlich ein Warenwirtschaftsprogramm schreiben willst? Dir wird schlichtweg das halbe Team wieder abspringen, weil entweder Fähigkeiten, Zeit und / oder Interesse am Thema fehlen.

Programmieren im Team ist ohnehin so eine Sache für sich, meine schulischen / ausbildungstechnischen Erfahrungen waren da nicht die besten, letzlich lief es darauf hinaus, dass ich das Ding alleine geschrieben habe und gewisse Dinge nicht implementieren konnte weil der Rest des Teams nicht die dafür nötigen Infos bereitgestellt hatte. Ich programmiere deswegen lieber alleine, da ist man von niemandem abhängig und kommt in der Regel schneller zum Erfolg (jedenfalls wenn es kein Mammutprojekt ist).

Wo ist dein Script und was funktioniert nicht? Sollen wir raten?

#AutoIt3Wrapper_usex64=n

Das sagt dem Compiler, dass das Script als 32bit Script kompiliert werden soll.

Die Funktion _timesync() setzt @error und gibt einen leeren String zurück anstatt der Zeit, wenn es zu einem Fehler bei der eigentlichen Kommunikation mit dem Zeitserver kam.
Du hast also zwei Möglichkeiten um einen Fehler abzufangen:

func zeit()
$time = _TimeSync()
if @error then return -1
; if $time = "" then return -1 ; oder eben so...
$split1 = StringSplit($time," ")
if $split1[0] < 2 then return -2 ; fängt Problem beim Split ab, wobei die Funktion von Oscar im Erfolgsfall aber denke ich immer einen fehlerfrei splitbaren String liefern sollte
return ($split1[2])
EndFunc

Dort wo du deine Funktion zeit() aufrufst musst du aber ebenfalls prüfen ob ein Fehler zurückkam (hier beispielhaft eine negative Zahl) oder ob alles ok war. Ansonsten verursacht dein Script vielleicht an anderer Stelle ungewolltes Verhalten.

Danke.

Ich hatte es damals aber auch schnell wieder aufgegeben, nachdem mir der Umfang klar wurde, denn in den RFC Dokumenten sind sicher noch sehr viel mehr Informationen zum Protokollablauf und den genauen Aufbauregeln vermerkt. Das alles durchzugehen würde Wochen benötigen, daher Hut ab vor all den Programmieren, die dieses Protokoll in der Vergangenheit vollständig umgesetzt haben.

Ich habe ebenfalls meine Zweifel, dass der TE dazu in der Lage ist, aber dieser Thread hilft vielleicht auch in Zukunft den groben Aufbau des Protokolls besser zu verstehen und zumindestens Ansatzweise zu analysieren. Hier liegt auch der Unterschied. Im anderen Thread gab es eine klare Aufgabenstellung die mit begrenztem Aufwand lösbar war, hier fehlt soetwas bzw. es soll einfach das komplette Protokoll unterstützt werden. Das ist schlichtweg nicht machbar ohne "gaaaanzzz viel Text" zu lesen und zu verstehen.

Davon ab fallen mir aber auch keine wirklichen Anwendungszwecke für einen eigenen DHCP Client/Server ein, außer die am Rande erwähnten Angriffsszenarien auf bestehende Netzwerke.

Ähm ja? Hast du dir mein Script angesehen? Dort wird in der Console das empfangene DHCP Paket eines beliebigen Netzwerk Gerätes ausgegeben, sobald dieses sich mit dem Netzwerk verbindet. Genau sowas muss dein Client auch verschicken, damit er vom Server eine Antwort bzw. IP zugewiesen bekommt.

Hier mal ein Beispiel:

0x01010600066C37B2000000000000000000000000000000000000000010683F364BDE00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000638253633501033D070110683F364BDE3204C0A80116390205DC3C0C6468637063642D352E352E360C18616E64726F69642D616366356561383563633364313136653709012103060F1C333A3BFF

Dieses Paket wurde von meinem Script empfangen als ich mein Android Smartphone mit dem WLAN verbunden habe.

Wenn wir die Nachricht nun wie im englischen wiki Artikel beschrieben zerlegen erhalten wir alle Einzelbestandteile der Nachricht, das schaut dann so aus:

OP:	01
HTYPE:	01
HLEN:	06
HOPS:	00
XID:	066C37B2
SECS:	0000
FLAGS:	0000
CIADDR:	00000000
YIADDR:	00000000
SIADDR:	00000000
GIADDR:	00000000
CHAADR:	10683F36 4BDE0000 00000000 00000000
192 octets of 0s:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Magic Cookie:
63825363
DHCP Options:
3501033D070110683F364BDE3204C0A80116390205DC3C0C6468637063642D352E352E360C18616E64726F69642D616366356561383563633364313136653709012103060F1C333A3BFF

Was das alles bedeutet sollte im Wiki Artikel erklärt werden, bzw. in den dort erwähnten weiterführenden Links. Gegen Ende der Nachricht findet sich immer ein Magic Cookie (63825363). Ab hier folgen dann die DHCP Options (Die eigentliche Nachricht des Clients... was will der client vom server?). Mein Script zerlegt diesen langen Options HEX String zuerst in Sätze anhand der Längenangaben, welche immer im 2. Octet stehen. Danach werden die Sätze einzeln ausgewertet und die enthaltenen Daten in lesbare Strings oder Dezimal Zahlen umgewandelt:

35 01 03
3D 07 01 10 68 3F 36 4B DE
32 04 C0 A8 01 16
39 02 05 DC
3C 0C 64 68 63 70 63 64 2D 35 2E 35 2E 36
0C 18 61 6E 64 72 6F 69 64 2D 61 63 66 35 65 61 38 35 63 63 33 64 31 31 36 65
37 09 01 21 03 06 0F 1C 33 3A 3B
RequestType:			DHCPREQUEST
Client Identifier (MAC):	10:68:3F:36:4B:DE
Requested IP:			192.168.1.22
Maximum DHCP message size:	1500
Class identifier:		dhcpcd-5.5.6
Hostname:			android-acf5ea85cc3d116e
Parameter request list:		Subnet Mask|Static routing table|Router|Domain Name Server|Domain Name|Broadcast Address|IP address lease time|Renew time value|Rebinding time value

Um die Options in lesbare Form zu bringen muss man wissen in welchem Format jede Option beschrieben ist, das ist meinem Link bezüglich der Options und zugehörigen RFC zu entnehmen und keinesfalls für alle identisch, also eine heiden Arbeit das alles zu supporten, daher habe ich mich in meiner SWITCH...CASE Abfrage auf die wenigen Options beschränkt welche meine Geräte tatsächlich versenden. Die nicht unterstützen Options werden nicht näher analysiert.

Fangen wir mal mit Satz 1 der Options an:

35 01 03

35 in Hex entspricht Dezimal ausgedrückt der Zahl 53 und steht für die Art der Option, diese kann man hier nachschlagen: http://www.networksorcery.com/enp/protocol/bootp/options.htm

53	1	DHCP message type.	RFC 1533, RFC 2132, RFC 3203, RFC 4388

Es handelt sich also um die Option "DHCP message type", welche immer 1 Octet lang ist (manche Optionen haben auch variable Längen). Das 2. Octet eines Satzes gibt die Länge aber immer an (wichtig bei variabler Länge), in unserem Fall "01", was dezimal einer 1 entspricht und sich mit der Beschreibung auf der genannten Webseite deckt. Das 3. Octet des Satzes sind dann die Daten, in unserem fall "03". Was bedeutet diese "03" nun? Dazu müssen wir die genaue Beschreibung im RFC Dokument nachschlagen:

Wenn wir im RFC 1533 nach "DHCP Message Type" suchen landen wir hier

9.4. DHCP Message Type


   This option is used to convey the type of the DHCP message.  The code
   for this option is 53, and its length is 1.  Legal values for this
   option are:


           Value   Message Type
           -----   ------------
             1     DHCPDISCOVER
             2     DHCPOFFER
             3     DHCPREQUEST
             4     DHCPDECLINE
             5     DHCPACK
             6     DHCPNAK
             7     DHCPRELEASE


    Code   Len  Type
   +-----+-----+-----+
   |  53 |  1  | 1-7 |
   +-----+-----+-----+

Die "03" steht also für "DHCPREQUEST".

Genau nach diesem Schema verfahren wir für alle Sätze und haben letzlich die Übersetzung (siehe oben). Wenn du nun ernsthaft immernoch einen DHCP Client programmieren willst wünsche ich viel Spaß beim Studium der RFC Dokumente, prinzipiell musst du "nur" den umgekehrten Weg gehen und das was du verschicken willst nach obigem Schema kodieren. Ein Client muss aber natürlich immer auch die Antworten verstehen, du brauchst also auch all das was ich zum Teil schon in meinem Script mache und hier gerade sehr ausführlich erläutert habe.

Mal so versucht?

$o = ObjCreate("System.Object")
$oData = $o.GetType().GetMembers()
if IsObj($oData) then
For $_ In $oData
ConsoleWrite($_.Name & " (" & $_.MemberType & ")" & @CRLF)
Next
else
consolewrite("Kein Objekt!" & @crlf)
endif
$o = 0

Klar müssen deine Nachrichten auch kodiert werden, es handelt sich schließlich um ein fixes Protokoll. Der Aufbau (Syntax) von den verschiedenen DHCP Paketen ist unter anderem im englischen Wikipedia Artikel dokumentiert:

http://en.wikipedia.org/wiki/Dynamic_H…ration_Protocol

In meinem Scriptteil beschränke ich mich wenn ich mich recht erinnere darauf alles nach dem "Magic Cookie" auszulesen, diese dort enthaltenen "Options" sind hier bzw. in den jeweiligen RFC dokumentiert:

http://www.networksorcery.com/enp/protocol/bootp/options.htm

Es ist jedenfalls nichts was man in ein paar Stunden programmiert hat und es erfordert auch sehr viel Einarbeitungszeit.

Die Frage ist aber wozu du das überhaupt brauchst. Windows beherrscht DHCP schließlich selbst und jeder 0815 Router bietet ebenfalls einen DHCP Server. Wenn es dir darum geht DHCP Traffic im Netzwerk zu analysieren bieten sich professionelle Networksniffer an, wie z.B. Wireshark. Auch für die Anwendungsfälle DHCP Requests abzufangen und zuerst zu beantworten (DHCP Rogue Server) oder das Netzwerk mit DHCP Requests zu fluten (DHCP Starvation Attack) gibts genügend "Hacker Software", sowas gehört hier aber ohnehin nicht her, siehe Forenregeln. Cisco ist im übrigen so nett in ihrem Lehrmaterial einige dieser speziellen Tools zu nennen.

Wie dem auch sei mir wäre es jedenfalls zuviel Arbeit das komplette Protokoll auseinanderzunehmen und zu verstehen.

EDIT:
Im englischen Wiki Artikel ist im übrigen auch ein Screenshot eines Software DHCP Servers für Windows zu finden: http://www.vercot.com/~serva/default.html
Vielleicht tuts das ja für deine Zwecke auch.

Du musst schon ein wenig mehr Aufwand betreiben, wenn du die DHCP Nachrichten möglichst vollständig zerlegen willst, dazu ist es notwendig das komplette Protokoll zu verstehen. Ich habe hier mal ein wenig damit rumgespielt:

https://autoit.de/index.php?page…4682#post334682

Im Quellcode findest du auch einen weiterführenden Link bezüglich des DHCP Protokolls.

ShellExecute ("restart twonky server.exe")

Das funktioniert so ganz sicher nicht, denn Shellexecute erwartet Parameter als Funktionsparameter. Davon ab kennt Windows keinen Befehl namens "restart", kann also überhaupt nicht klappen.
Einen Dienst beendet bzw. startet man so wie auch bereits in deinem anderen Thread beschrieben wurde:

Run(@ComSpec & " /c net stop twonkymedia")
; bzw.
Run(@ComSpec & " /c net start twonkymedia")

Es könnte auch sein, dass der Autoitbefehl "shutdown()" nicht blockierend ist und das sleep(60000) bereits ausgeführt wird solange der Rechner gerade in den Standby wechselt. Wenn das so sein sollte bin ich mir auch nicht sicher ob das Programm dann wirklich die vollen 60 Sekunden, nur noch einen Teil der 60 Sekunden oder garnicht mehr schläft beim aufwachen (die Zeitmessung könnte durch den Standby mode durcheinander kommen).

Mein Ansatz wäre daher das Windows Ereignisprotokoll zu prüfen, hier wird vermutlich jedes Aufwachen aus dem Standby vermerkt, d.h. man könnte im Falle eines shutdown() ein Flag setzen, welches in jedem Schleifendurchlauf durch auslesen des Eventlogs geprüft wird, ändert sich der Modus, sprich der PC ist wieder wach, dann schläft man kurz und erst dann wird wieder geprüft ob Netzwerkgeräte ein erneutes Standby erfordern (kein anderer Rechner online). Da ich die Energiesparsettings hier aber aus habe und meine Grafikkarte Probleme beim Aufwachen aus dem Standby hat kann ich das nicht testen.

Hier mal eine komplette Fassung der WMI Variante, Details zu den einzelnen Infos die abgefragt werden können siehe msdn. Bei mir bleibt der Großteil des Arrays aber leer, somit liefert es vermutlich auch nicht mehr Infos als das zusammengekürzte Script aus dem englischen Forum.

BugFix : Deklariert hat er das Array bzw. vielmehr die Platzhaltervariable (Zeile 23)

Ansonsten wie Bugfix sagte, du kannst nicht davon ausgehen, dass die Datei auf jedem System existiert und die Berechtigungen ausreichen um diese zu lesen, daher muss grundsätzlich ein Fehler von _fielreadtoarray() abgefangen werden.
Ergänzend dazu bist du beim nachfolgenden stringsplit() genauso unvorsichtig, was vielleicht sogar eher der Fehler auf diesen Systemen ist. Du gehst grundsätzlich davon aus, dass jede Zeile ein ":" enthält und splittbar ist, sollte das nicht der Fall sein ist das Ergebnisarray nur bis Index 1 ansprechbar (kompletter ungeteilter String), du sprichst später aber einen Index 2 des Arrays an, also auch hier musst du prüfen ob stringsplit erfolgreich war.

Weitere Anmerkung: Hast du im unteren Abschnitt Code entfernt? Wozu die innere Schleife, wenn sie keinen code enthält?

Hier mal eine Fassung die dir etwas Feedback gibt, sofern du den Scriptablauf nicht interaktiv verfolgen kannst solltest du statt msgboxen ein Logfile schreiben und ggf. per email versenden

if _FileReadToArray($sSysteminfo, $aFile) = 0 then
exit msgbox(0,"fehler","datei konnte nicht gelesen werden! --> Errorcode: " & @error) ; Programmende, da Datei nicht zugreifbar...

else

For $i = 2 To 33
$split = StringSplit($aFile[$i], ': ', 1)
if $split[0] < 2 then
msgbox(0,"fehler", $aFile[$i] & " konnte nicht gesplittet werden!")
continueloop ; überspringt diesen Fehlerhaften Dateieintrag
endif
For $j = 1 To UBound($split) -1 ; ?????????????????????? hier passiert nix...
Next
$split[2] = StringStripWS($split[2], 1)
IniWrite($sInisave, "Systeminfo", $split[1], $split[2])
Next

endif