Jak uruchomić skrypt w ukrytym oknie?

Skrypciarze odpowiadają na Wasze pytania

Jak uruchomić skrypt w ukrytym oknie?

Cześć, Skrypciarze! Jak uruchamia się skrypt w ukrytym oknie?

-- OT

Cześć, OT! Dzisiejszy dzień jest trochę pechowy dla Skrypciarzy, a na pewno dla piszącego to Skrypciarza. Cały obszar Seattle był ostatnimi czasy ostro zalewany strugami deszczu. Zaczęliśmy więc zacierać ręce. Nie to, żebyśmy byli fanami deszczu, wielokrotnie przecież na łamach zdarzało mi się utyskiwać na naszą pogodę. Mieliśmy jednak nadzieję, nadzieję na jakiś rekord jeżeli chodzi o opady na dzień, a tu nic… Zdobyliśmy jedynie „prawie rekord”, czyli wszystko po staremu, zdaje się, że Seattle wszystko ma „prawie”, no może oprócz grunge’u:

Mamy tu „prawie lotnisko”, więc zapraszam na wakacje, mimo tego, że lato nie jest latem, ale prawie-latem. Nie przejmujcie się też korkami – mamy przecież prawie-plan rozwiązania problemów komunikacyjnych. Z czego słyniemy? Jak to? Mamy prawie-profesjonalną drużynę koszykówki (bo nie wiem czy wiecie, ale Supersonics od 2006 r. należą już do Oklahoma City). Taka prawdziwa Nibylandia, więc jeżeli jesteście fanami Piotrusia Pana to serdecznie zapraszamy…

Spróbujemy teraz prawie odpowiedzieć na Twoje pytanie, OT, dotyczące uruchamiania skryptu z ukrytego okna. Jest na to wiele prawie-metod. Możesz na przykład użyć poniższego prawie-skryptu:

Set objShell = CreateObject("Wscript.Shell")

objShell.Run "Wscript.exe C:\Scripts\Test.vbs"

To zazwyczaj działa, ponieważ host Wscript nie używa okna polecenia. Jeżeli więc uruchomicie skrypt za pomocą Wscript, zobaczycie, ze na ekranie absolutnie nic się nie dzieje. Oczywiście prawie nic się nie dzieje, bo w pewnym momencie wyskoczy Wam okno komunikatu. Stanie się tak za każdym razem, gdy wywołamy polecenie Wscript.Echo. Jeżeli jednak będziecie się trzymać z daleka od wszystkiego, co może wywołać takie okno komunikatu na ekranie, skrypt może zostać uruchomiony w hoście Wscript i nikt tego nawet nie zauważy.

Teraz myślicie sobie zapewne: „tylko dlaczego ten artykuł taki długi, pewnie dał jeszcze sporo anegdot na temat deszczu?”. Żadnych anegdot już nie będzie, Skrypciarze są zawsze przewidujący i przewidują więcej niż jeden scenariusz działania. Powyższy skrypt jest niezawodny dla skryptów .VBS, ale na nasze i Wasze nieszczęście, działa tylko dla skryptów .VBS. (Jest to nawet sensowne – nie można przecież uruchomić narzędzia wiersza polecenia za pomoca hosta Windows Script Host).

Oto inny skrypt, ten powinien działać w ukrytym oknie w prawie każdym przypadku:

Const HIDDEN_WINDOW = 0



strComputer = "."



Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")



Set objStartup = objWMIService.Get("Win32_ProcessStartup")

Set objConfig = objStartup.SpawnInstance_

objConfig.ShowWindow = HIDDEN_WINDOW



Set objProcess = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")



objProcess.Create "Cscript.exe C:\Scripts\Test.vbs", null, objConfig, intProcessID

Zaczynamy od zdefiniowania stałej o nazwie HIDDEN_WINDOW i ustawienia jej wartości na 0; będziemy jej używać w celu poinstruowania skryptu, że chcemy, aby nasz drugi skrypt (lub narzędzie wiersza polecenia) został uruchomiony w ukrytym oknie. Po zdefiniowaniu naszej stałej łączymy się z usługą WMI na komputerze lokalnym.

Tak, można także uruchomić ten skrypt na komputerze zdalnym, ale to byłaby już przesada. Dlaczego? Ponieważ nie musimy konfigurować wszystkich opcji rozruchu (co zamierzamy zrobić), jeżeli zamierzamy uruchomić skrypt na komputerze zdalnym. Wielokrotnie pisaliśmy przecież o tym, że każdy proces uruchomiony na komputerze zdalnym zawsze działa w ukrytym oknie. Oczywiście możecie zostawić ten skrypt w obecnej formie i uruchomić go na komputerze zdalnym, wystarczy tylko przypisać nazwę tego komputera zmiennej strComputer:

strComputer = "atl-fs-001"

Po połączeniu się z usługą WMI przechodzimy do następującego wiersza kodu:

Set objStartup = objWMIService.Get("Win32_ProcessStartup")

Set objConfig = objStartup.SpawnInstance_

objConfig.ShowWindow = HIDDEN_WINDOW

Jest to ten fragment kodu, w którym konfigurujemy opcje rozruchu. W tym celu najpierw tworzymy nawiązanie do klasy Win32_ProcessStartup, która to właśnie umożliwia konfigurowanie opcji startowych procesu. Po połączeniu się z nią wywołujemy metodę SpawnInstance_ (uwaga na podkreślnik po nazwie metody); daje nam to „pusty” obiekt startowy, który możemy konfigurować wedle upodobania. W niniejszym skrypcie mamy właśnie upodobanie, żeby ustawić wartość właściwości ShowWindow na 0 (przy użyciu stałej HIDDEN_WINDOW):

objConfig.ShowWindow = HIDDEN_WINDOW

Co to nam daje? Zgadza się, spowoduje, że skrypt (albo narzędzie wiersza polecenia) uruchomi się w ukrytym oknie.

Tak przy okazji, wiele ciekawych rzeczy można jeszcze zrobić przy użyciu klasy Win32_ProcessStartup. Można na przykład rozpocząć proces w zminimalizowanym lub maksymalizowanym oknie, można rozpocząć proces z wyższym (lub niższym) priorytetem niż normalny. Więcej informacji na ten temat znajdziecie w WMI SDK (j.ang.) na MSDN. Żeby tylko podsycić Wasz apetyt, oto kod, który konfiguruje każdy skrypt lub aplikację, która jest uruchomiona w oknie polecenia. W tym przypadku okno polecenia:

• Będzie miało nazwę okna Test Window.
• Będzie miało jasne czerwone tło.
• Będzie umieszczone w lewym górnym rogu ekranu.

Oto kod:

Set objStartup = objWMIService.Get("Win32_ProcessStartup")

Set objConfig = objStartup.SpawnInstance_

objConfig.Title = "Test Window"

objConfig.FillAttribute = 192 

objConfig.X = 0

objConfig.Y = 0

Macie już apetyt? W takim razie jeszcze raz polecam WMI SDK.

Co zaś tyczy się naszego skryptu, to po skonfigurowaniu opcji rozruchu używamy poniższego wiersza kodu, aby połączyć się z Win32_Process:

Set objProcess = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")

Teraz przywołujemy metodę Create aby uruchomić nasz skrypt (lub narzędzie wiersza polecenia) w ukrytym oknie:

objProcess.Create "Cscript.exe C:\Scripts\Test.vbs", null, objConfig, intProcessID

Musimy teraz nadać metodzie Create następujące parametry:

• Cscript.exe C:\Scripts\Test.vbs. To całkowita ścieżka skryptu .VBS, który chcemy uruchomić. Poprzedzając tę ścieżkę poleceniem Cscript.exe sprawiamy, że skrypt będzie działał używając hosta CScript. Jest to dla nas dość korzystne, ponieważ każde polecenie Wscript.Echo będzie miało swoje echo w ukrytym oknie konsoli. Jeżeli uruchomimy Test.vbs za pomocą hosta Wscript, to każde takie polecenie będzie miało swoje echo w postaci okna komunikatu. Wszystko w porządku, ale tylko do momentu, kiedy uświadomimy sobie, że te okna komunikatu będą pojawiały się w ukrytym oknie, więc nie będą dla nas widoczne. Oznacza to, że będą tam „tkwić” na próżno przez wieki, czekając, aż ktoś na nie kliknie. Jeżeli zaś nikt nie kliknie (co jest bardzo prawdopodobne, nie klikałem jeszcze na żaden przycisk, który byłby niewidoczny), to skrypt też będzie czekał i czekał.
• Null. Określa katalog roboczy dla skryptu lub narzędzi wiersza polecenia. Jeżeli, tak jak tutaj, ustawimy Null, oznacza to, że chcemy, aby Test.vbs był uruchomiony w tym samym katalogu roboczym co skrypt, który go uruchomił.
• objConfig. Nawiązanie do obiektu startowego.
• intProcessID. Parametr wyjściowy przechowujący identyfikator przypisany do naszego nowego procesu. Podajemy po prostu nazwę zmiennej; metoda Create poda jej wartość automatycznie.

Tylko tyle musimy zrobić: uruchomić powyższy skrypt, a to uruchomi nam Test.vbs, ale nikt (oprócz nas oczywiście) nie będzie o tym wiedział, ponieważ wszystko będzie się działo w ukrytym oknie.

Seattle jak Seattle, może i nie mamy największych opadów na dzień ani super drużyny koszykarskiej, mamy za to Jimmiego Hendrixa, Bena Harpera, Pearl Jam, Alice In Chains… Czy Wy w Oklahoma City też możecie się tym poszczycić???

Do początku strony