Neustart eines Remote Rechners mit Inputbox

looxis

Hallo Liebe Com,

ich versuche gerade mit AutoIT einen Rechner neuzustarten, welcher in meiner Domain ist.
Den Namen möchte ich erst nach ausführen des Scriptes eingeben, quasi soll ein Popup kommen "Enter PC Name".

Was ich bisher habe, was aber nicht funktioniert:

$Username = "Mein Admin ACC"
$Domain = "Meine Domain"
$Password = "Mein PW"
$sTarget = InputBox ( "Enter PC Name", "Enter PC Name", "", "")

RunAsWait($Username ,$Domain ,$Password , 1, "cmd.exe /c shutdown -r -f -m \\$sTarget", @SystemDir, @SW_MAXIMIZE)

Wenn ich das ganze mit Shutdown -i mache und dort den PC Namen eintippe (ohne $sTarget) dann funktioniert es.
Mir wäre es aber wie gesagt lieber wenn ein Popup käme wo man nur noch den PC Namen eingibt, Enter und los gehts.

Danke euch

**autoiter**

Hallo @looxis,
Du hast nicht die Variable $sTarget im Befehl, sondern den String $sTarget..
ändere es in
" & $sTarget,

**alpines**

Zitat von autoiter

Du hast nicht die Variable $sTarget im Befehl, sondern den String $sTarget..

Es ist genauso wie autoiter es beschreibt. Wenn du den Inhalt einer Variable nutzen/manipulieren willst darfst du sie nicht innerhalb von String-Literalen (" " oder ' ') stehen haben.

Wenn du das allerdings so machen möchtest um nicht immer die Strings zu beenden und für Variablen neu zu starten, kannst du auch den Modus 'ExpandVarStrings' in der AutoItSetOption auf 1 setzen um z.B. "Hallo, ich heiße $sMeinName$" als Hallo, ich heiße blubb auszugeben.

Busti

Zitat von alpines

Es ist genauso wie autoiter es beschreibt. Wenn du den Inhalt einer Variable nutzen/manipulieren willst darfst du sie nicht innerhalb von String-Literalen (" " oder ' ') stehen haben.

Es Sei denn, man machts wie ich , noch mit nen "StringReplace( $String, "$sTarget", $sTarget ).
Find ich in gewissen Situationen ganz hilfreich. (Siehe den Parser). Aber ist warscheinlich auch wieder langsamer

**alpines**

Zitat von Busti

StringReplace( $String, "$sTarget", $sTarget )

Das ist aber vollgas am Ziel vorbei meiner Meinung nach. Bei deinem Parser verstehe ich das ja vielleicht noch aber nicht in einem Script wo man da fix per Hand selber lösen kann.
Zu so einer Situation sollte es ja sowieso nicht kommen wenn man am coden ist.

Busti

Zitat von alpines

Das ist aber vollgas am Ziel vorbei meiner Meinung nach. Bei deinem Parser verstehe ich das ja vielleicht noch aber nicht in einem Script wo man da fix per Hand selber lösen kann.Zu so einer Situation sollte es ja sowieso nicht kommen wenn man am coden ist.

Da hast du wie gesagt recht, aber es ging ja eher nur um dass, das es eine "möglichkeit" ist.

Er hängt ja nicht immer an dem Selben Script mit den selben Anforderungen, darum ist es nie falsch alle möglichen Wege nach Rom zu kennen =)

Aber wegen der Ineffizienz, stimm ich dir voll und ganz zu.

**alpines**

Zitat von Busti

Aber wegen der Ineffizienz, stimm ich dir voll und ganz zu.

Die musst du aber in einen gewissen Kontext setzen. Wenn mir das Kopieren eines Objektes 0.0000005 Sekunden Zeit in Anspruch nimmt und ich beim ByRef die Veränderungen rückgängig machen muss um das ursprüngliche Objekt zu haben sieht das ganze schon wieder ganz anders aus.

In Anwendungen die sehr rechenlastig sind kommt man um ByRef eigentlich nicht rum, da sich diese Zeit zum kopieren deutlich vergrößert und einen nennenswerten Vorteil bringt.
In AutoIt (was für meist nicht rechenintensive Aufgaben genutzt wird) ist es eher stil- und komfortbasiert.

Busti

Zitat von alpines

1)Die musst du aber in einen gewissen Kontext setzen. Wenn mir das Kopieren eines Objektes 0.0000005 Sekunden Zeit in Anspruch nimmt und ich beim ByRef die Veränderungen rückgängig machen muss um das ursprüngliche Objekt zu haben sieht das ganze schon wieder ganz anders aus.
2)In Anwendungen die sehr rechenlastig sind kommt man um ByRef eigentlich nicht rum, da sich diese Zeit zum kopieren deutlich vergrößert und einen nennenswerten Vorteil bringt.
In AutoIt (was für meist nicht rechenintensive Aufgaben genutzt wird) ist es eher stil- und komfortbasiert.

1)
Da hast du recht.
Etwas wiederherzustellen, was man grad effektiv verändert hat,
ohne Kopie/sonst was, ist nicht nur in der Programmierung eklig

2)
Kann man in AutoIT nicht, die rechenlastigen aufgaben, an irgenteine C++ Bibliothek übergeben, und sich das Ergebnis holen?
Ich mein, für AutoIT würde das wahnsinnig Sinn ergeben, da das langsame Script, einfach die 'Standart' aufgaben erledigt und die Hochkomplexen-Polygon-Muster die 3D Animiert sind und sich bewegen, lässt man chillig über die C++ Bibliothek ausführen und geniesst voll speed- bei easy AutoIt Code?

3)
Warum ist AutoIt überhauptso god damn slow? hab gehört hat mit dem Aufbau und dem Linearen Scriptablauf zutun?
Soweit hab ich mich dann noch nicht über AutoIt informiert, bzw mit jemand darüber geredet, der den Anschein macht das auch wirklich alles zu verstehen. Was wichtig ist, man will ja auch kein Mist abspeichern.

**BugFix**

Zitat von Busti

Kann man in AutoIT nicht, die rechenlastigen aufgaben, an irgenteine C++ Bibliothek übergeben, und sich das Ergebnis holen?

Ist auch durchaus üblich, bei denen, die rechenintensive Aufgaben abarbeiten. Da wird z.B. ASM genutzt oder wie ich gerade selbst bei einem Projekt bemerkt habe, kann man die schnarchende Langsamkeit bei rekursiven Dateioperationen einfach von Powershell erledigen lassen, in einem Bruchteil der Zeit, die AutoIt braucht.
Das ist letztlich aber alles OK: AutoIt bietet ein einfach zu nutzendes Interface und wenns schnell gehen muss, wird der Auftrag weitergereicht.

**alpines**

Zitat von Busti

Kann man in AutoIT nicht, die rechenlastigen aufgaben, an irgenteine C++ Bibliothek übergeben, und sich das Ergebnis holen?
Ich mein, für AutoIT würde das wahnsinnig Sinn ergeben, da das langsame Script, einfach die 'Standart' aufgaben erledigt und die Hochkomplexen-Polygon-Muster die 3D Animiert sind und sich bewegen, lässt man chillig über die C++ Bibliothek ausführen und geniesst voll speed- bei easy AutoIt Code?

BugFix hat es schon angeschnitten. Mit AutoIt hat man die Möglichkeit ASM-Code auszuführen oder DLLs zu callen. ASM ist die schnellste Variante, denn man ruft CallWindowProc (glaube ich) auf und führt den ASM Code aus, dieser wird rasend schnell ausgeführt da er in Maschinensprache direkt vorhanden ist und nicht als AutoIt Code interpretiert werden muss was ich dir beim nächsten Punkt erläutern werde.

Ich hatte vor einer Weile ein Tutorial geschrieben womit man C# DLLs in AutoIt callen kann um rechenintensive Aufgaben zu verlagern. Das ganze klappt mit C++ auch!
Man erstellt eine DLL die z.B. etwas sehr aufwändiges berechnet und nutzt sie mit AutoIt indem man DllCall verwendet. Der ausgeführte Code liegt in Maschinensprache vor und muss nicht interpretiert werden.

Zitat von Busti

Warum ist AutoIt überhauptso god damn slow? hab gehört hat mit dem Aufbau und dem Linearen Scriptablauf zutun?
Soweit hab ich mich dann noch nicht über AutoIt informiert, bzw mit jemand darüber geredet, der den Anschein macht das auch wirklich alles zu verstehen. Was wichtig ist, man will ja auch kein Mist abspeichern.

AutoIt ist deshalb so langsam, weil es eine interpretative Sprache ist. AutoIt-Code wird NICHT zu Assembler konvertiert und in Maschinencode in eine Exe-Datei gespeichert, sondern eine AutoIt-Exe besteht immer aus dem Interpreter und dem AutoIt-Script.

Der Interpreter interpretiert zur Laufzeit des Scriptes die Befehle und führt die entsprechenden Routinen aus, und du kannst dir vorstellen das das ganze dann deutlich langsamer ist wenn man das mal in einem Vergleich zu C++ anschaut:

am schnellsten: 1) Hardcore Assembler, beste menschenmögliche Optimierung ==== übersetzen ====> Maschinencode
schnell: 2) C++ Programm (main.cpp) ==== Compiler übersetzt in Assembler und optimiert so gut es kann ====> Maschinencode
langsam: 3) AutoIt Script (main.au3) ==== C++ Interpreter interpretiert das Script zur Laufzeit und führt entsprechende Routinen aus ====> Maschinencode des Interpreters nur vorhanden

Du siehst also das AutoIt niemals so schnell sein kann wie ein "normales" C++ Programm, denn das Script wird interpretiert und es liegt nicht als Maschinencode vor.
Die Optimierung des Interpreters bestimmt im großen und ganzen die Geschwindigkeit deines Scriptes.

Aber das Designziel von AutoIt war es nie Routinen so schnell wie möglich abzuarbeiten sondern eine Scriptplattform zu bieten mit der man sehr schnell gute Resultate erreichen kann.
Schau dir mal an wie man in C++ oder C# z.B. globale Hotkeys setzt. Das ist ein Albtraum!! In AutoIt gibts dafür HotKeySet().

Busti

Ich Bedanke mich mal wieder für die mehr als ausführliche Antwort !

Was ich so schade finde, ist das AutoIt einfach geil ist :P.

Gibts mittlerweile ein Sinnvolles Multithreading für AutoIt?

Egal auf welche Art, ob nun Selbstaufrufe mit ExecuteLine oder mit ner C++ DLL, bzw der C++ function.

Hab hier iwo paar scripts rumliegen, hab mich aber noch nicht von ihrem nutzen überzeugt.

Weil wenigstens durch ein paar Fake-Threads(Oder auch richtige, was halt auch derzeit möglich ist), kann man bestimmt auch einiges an Geschwindigkeit gutmachen.

Also natürlich unvergleichbar mit fasm/c#++. Aber du weißt was ich mein, es so gut hinkriegen, das es einfach nicht störrt und wie geschmiert läuft :-).

Jetzt gibtsschon Objecte in Autoit, warum dann nicht auch echtes Multi-Threading

**alpines**

Zitat von Busti

Gibts mittlerweile ein Sinnvolles Multithreading für AutoIt?

Ja, du kannst tatsächlich mit AutoIt multithreaden. Dazu gabs schon genug Helden die das versucht haben, aber es läuft instabil und sollte deshalb vermieden werden.
Wenn du wirklich parallel Sachen ausführen möchtest rate ich dir zu multiprocessing mit mehreren Scripten.

Zitat von Busti

Jetzt gibtsschon Objecte in Autoit, warum dann nicht auch echtes Multi-Threading

Die Entwicklung der Sprache geht auch eher schleppend voran da viele Entwickler (meines Wissens nach) das Interesse verloren haben.

Busti

Zitat von alpines

(1)
Ja, du kannst tatsächlich mit AutoIt multithreaden. Dazu gabs schon genug Helden die das versucht haben, aber es läuft instabil und sollte deshalb vermieden werden.Wenn du wirklich parallel Sachen ausführen möchtest rate ich dir zu multiprocessing mit mehreren Scripten.

(2)
Die Entwicklung der Sprache geht auch eher schleppend voran da viele Entwickler (meines Wissens nach) das Interesse verloren haben.

(1)
Ja, das mit multi-processing wusst ich, aber beim Threading hatte ich noch ein alten Standpunkt, damals, hatte es meines wissens nach noch keiner geschafft.
Hab letztens nur ma was überflogen, und da meinte einer er hat das Stabil hinbekommen, ohne probleme. Darum die neugier

(2)
Da bin ich jetzt schon etwas ::shocked:: :O
Das ist doch mit Abstand die geilste Sprache, auch wenns nur ne Scriptsprache ist, sie ist ne Scriptsprache mit Schuhen für Erwachsene haha

looxis

Danke, es hat geklappt.
Habe zu dem ganzen jetzt testweise eine GUI erstellt mit Buttons usw.
Problem ist jetzt nachdem ich ein Case ausgeführt habe z.B. Fahre den \\XXXXX Pc herunter geht das Programm zu,
was muss ich ergänzen das es offen bleibt?

Vielen Dank

**alpines**

Zitat von looxis

Danke, es hat geklappt.
Habe zu dem ganzen jetzt testweise eine GUI erstellt mit Buttons usw.
Problem ist jetzt nachdem ich ein Case ausgeführt habe z.B. Fahre den \\XXXXX Pc herunter geht das Programm zu,
was muss ich ergänzen das es offen bleibt?

Vielen Dank

Das Script zu posten wäre ganz hilfreich.

Busti

Zitat von looxis

Danke, es hat geklappt.
Habe zu dem ganzen jetzt testweise eine GUI erstellt mit Buttons usw.
Problem ist jetzt nachdem ich ein Case ausgeführt habe z.B. Fahre den \\XXXXX Pc herunter geht das Programm zu,
was muss ich ergänzen das es offen bleibt?

Vielen Dank

monsieur, ich glaube sie haben ein "Exitloop" bei ihren Knöpfschn gesetzt hahahaah D;

looxis

Zitat von alpines

Das Script zu posten wäre ganz hilfreich.

Hey, anbei das Script.

AutoIt

#include <GUIConstants.au3>
#Region ### START Koda GUI section ### Form=
MouseMove(@DesktopWidth/2, @DesktopHeight/2, 0) ; instant
$Form1 = GUICreate("AdminTools", 500, 500, 500, 500)
WinMove($Form1, '', 700, 280)
$Background = GUISetBkColor (0x000000)
$Backpic = GUICtrlCreatePic('c:\Program Files (x86)\AutoIt3\Examples\GUI\200.jpg', 0, 0, 0, 0)
$State = GUICtrlSetState(-1, $GUI_DISABLE)
$Set = GUISetState(@SW_SHOW)
$Button1 = GUICtrlCreateButton("AD Center als Admin", 150, 25, 200, 25, 0)
GUICtrlSetColor(-1, $GUI_BKCOLOR_TRANSPARENT)
$Button2 = GUICtrlCreateButton("Remote PC / Server herunterfahren", 150, 0, 200, 25, 0)
GUICtrlSetColor(-1, $GUI_BKCOLOR_TRANSPARENT)
$Button3 = GUICtrlCreateButton("Admin CMD - Lokal", 150, 50, 200, 25, 0)
GUICtrlSetColor(-1, $GUI_BKCOLOR_TRANSPARENT)
$Button4 = GUICtrlCreateButton("Admin Computer Verwaltung - Remote", 150, 75, 200, 25, 0)
GUICtrlSetColor(-1, $GUI_BKCOLOR_TRANSPARENT)
$Username = InputBox ( "Bitte deinen Admin-Usernamen eingeben", "Bitte deinen Admin-Usernamen eingeben", "", "")
$Domain = "Meine Domain"
$Password = InputBox ( "Bitte dein Passwort eingeben", "Bitte dein Passwort eingeben", "", "*")
WinMove($Form1, '', 700, 280)
GUISetState(@SW_SHOW)
MouseMove(@DesktopWidth/2, @DesktopHeight/2, 0) ; instant
#EndRegion ### END Koda GUI section ###


if winexists("AdminTools") Then
winactivate("AdminTools")
EndIf




While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
Case $Button1 ;hier bestimmst du welcher button in diesem fall eben button1
RunAs($Username ,$Domain ,$Password , 2, "cmd.exe /c dsa.msc", @SystemDir, @SW_HIDE), @SystemDir, @SW_MAXIMIZE) ;Hier bestimmst du wie die Funktion heisst die bei einem klick auf dem Button aus geführt wird


Case $Button2 ;hier bestimmst du welcher button in diesem fall eben button1
$sTarget = InputBox ( "Welcher Pc soll heruntergefahren werden?", "Welcher Pc soll heruntergefahren werden?", "", "")
RunAsWait($Username ,$Domain ,$Password , 1, "cmd.exe /c shutdown -s -f -m \\" & $sTarget, @SystemDir, @SW_MAXIMIZE) ;Hier bestimmst du wie die Funktion heisst die bei einem klick auf dem Button aus geführt wird


Case $Button3 ;hier bestimmst du welcher button in diesem fall eben button1
RunAs($Username ,$Domain ,$Password , 1, "cmd.exe", @SystemDir, @SW_MAXIMIZE) ;Hier bestimmst du wie die Funktion heisst die bei einem klick auf dem Button aus geführt wird


Case $Button4 ;hier bestimmst du welcher button in diesem fall eben button1
$sTarget = InputBox ( "Auf welchem PC soll die Computerverwaltung gestartet werden?", "Auf welchem PC soll die Computerverwaltung gestartet werden?", "", "")
RunAsWait($Username ,$Domain ,$Password , 1, "cmd.exe /c compmgmt.msc /computer:\\" & $sTarget, @SystemDir, @SW_MAXIMIZE), @SystemDir, @SW_MAXIMIZE) ;Hier bestimmst du wie die Funktion heisst die bei einem klick auf dem Button aus geführt wird


EndSwitch
WEnd
Func _Func1 () ;Hier wird eine Funktion gestartet und zwar die funktion die oben dem Button1 zugewiesen wurde
MsgBox(0, "Erfolgreich", "Somit wurde deine Button1 Funktion ausgeführt und die Gui beendet")
Exit
EndFunc
WinWaitClose ( "AdminTools" [, "text" [, timeout = 0]] )

Alles anzeigen

EDIT BugFix: Code in AutoIt-Tags gepackt

**autoiter**

Hallo @looxis,

ich konnte dein Skript gar nicht erfolgreich starten. Hast du wirklich diesen Code benutzt?

AutoIt

RunAs($Username ,$Domain ,$Password , 2, "cmd.exe /c dsa.msc", @SystemDir, @SW_HIDE), @SystemDir, @SW_MAXIMIZE)

Das gleiche später noch einmal und dann:

AutoIt

WinWaitClose ( "AdminTools" [, "text" [, timeout = 0]] )

Danach lief es (auch nach Klick auf Buttons).

**alpines**

Da sind einige Fehler im Code die ihn nicht mal lauffähig machen. Hast du von dem Code Teilt geändert / weggelassen als du ihn hochgeladen hast?
Ich schätz mal das dein Script sich beendet weil er bis zum Case läuft aber dann crasht.

@autoiter
Man kann ja Scripte trotz Errors ausführen lassen und sie bei einem Error crashen lassen. Compile das mal, dann läuft das auch bis dahin wie er es beschreibt.

**autoiter**

Zitat von alpines

Man kann ja Scripte trotz Errors ausführen lassen und sie bei einem Error crashen lassen. Compile das mal, dann läuft das auch bis dahin wie er es beschreibt.

Hi @alpines, so wird natürlich ein Schuh daraus.