Posts tagged ‘PowerShell’

Triki z PowerShellem #5 – Skróty

2008-06-20 13:53

Pisząc skrypty w PowerShellu mamy dostęp do niemal całej platformy .NET, zawierającej grubo ponad dziesięć tysięcy klas, dlatego nieczęsto będziemy potrzebowali czegoś spoza tego wielkiego bogactwa. Ale takie przypadki też istnieją. Na szczęście PSh umożliwia też dostęp do innych narzędzi niż .NET – jak choćby do starych (nie)dobrych obiektów COM.
Przy ich pomocy można zrobić całkiem sporo, zwłaszcza jeśli chodzi o sterowanie aplikacjami, które udostępniają na zewnątrz odpowiednie interfejsy (a robi tak wiele większych programów, nie tylko Microsoftu). Ciekawsze jest chyba jednak łączenie technologii: “starego” COM-a i nowego .NET-a, aby razem zrobić coś użytecznego. Oto prosty przykład:

  1. # shortcuts.ps1
  2. # Szuka skrótów do nieistniejących plików w podanym katalogu
  3.  
  4. # Parametr: ścieżka do przeszukiwanego katalogu
  5. param([string]$path = ".")
  6.  
  7. # Szukamy plików skrótów
  8. $allLinks = [IO.Directory]::GetFiles($path, "*.lnk", [IO.SearchOption]::AllDirectories)
  9.  
  10. # Przeglądamy listę i szukamy nieistniejących
  11. $wsh = New-Object -ComObject WScript.Shell
  12. $invalidLinks = New-Object Collections.ArrayList
  13. foreach ($linkFile in $allLinks)
  14. {
  15.     $lnk = $wsh.CreateShortcut($linkFile)
  16.     if (-not ([IO.File]::Exists($lnk.TargetPath) -or [IO.Directory]::Exists($lnk.TargetPath)))
  17.         { $invalidLinks.Add($linkFile) | Out-Null }
  18. }
  19. return [string[]]$invalidLinks.ToArray()

Dziwnym trafem najprostsze przykłady użycia COM są zwykle związane z tworzeniem skrótów (plików .lnk) przy pomocy metody CreateShortcut obiektu COM o identyfikatorze WScript.Shell. Obiekt ten był dawniej używany w skryptach hosta systemu Windows (Windows Scripting Host) i, jak widać, nadal zdarza mu się być użytecznym ;-)
Co jednak robi powyższy skrypt? Otóż nie tworzy żadnych nowych skrótów, a wręcz przeciwnie: wskazuje kandydatów do usunięcia, czyli skróty pokazujące na nieistniejące pliki lub katalogi. Na wyjściu dostajemy ich zgrabną listę, którą możemy przekierować na przykład do polecenia Remove-Item.
A tak możemy sobie wyczyścić Menu Start:

  1. $startMenu = [Environment]::GetFolderPath([Environment+SpecialFolder]::StartMenu)
  2. . ./shortcut.ps1 -path $startMenu | Remove-Item

I pomyśleć, że kiedyś napisałem do tego cały osobny program… :)

Tags: ,
Author: Xion, posted under Applications » 1 comment

Triki z PowerShellem #4 – DirectX

2008-06-10 11:13

Jakiś czas temu pokazałem, że w PowerShellu można zrobić rzeczy, które są – jak na konsolkę tekstową – co najmniej niespotykane. Przedstawiłem na przykład sposób na wyświetlenie zwykłego windowsowego okienka. Nie było ono aczkolwiek zbyt interesujące, jako że w środku było zupełnie puste – chociaż, oczywiście, Aero robił co mógł, by wyglądało ono na atrakcyjniejsze niż było w rzeczywistości ;)
Jako że zajmowania się rzeczami zupełnie nieprzydatnymi nigdy dość, postanowiłem więc pewnego razu spróbować wnieść w stworzoną formę nieco więcej życia. Efekty okazały się raczej ciekawe, przedstawiając się następująco:

DirectX w PowerShellu - trójkąt (screen 1) DirectX w PowerShellu - trójkąt (screen 2) DirectX w PowerShellu - trójkąt (screen 3)

Tak, to jest trójkąt. Tak, on się obraca. Tak, na pasku tytułowym okna jest napisane Direct3D… Wszystkie te trzy fakty nie są żadnym zbiegiem okoliczności :) Za wszystko odpowiedzialny jest ten ono skrypt:

  1. # D3D.ps1 - próba użycia Direct3D w PowerShellu
  2.  
  3. # Ładujemy assemblies
  4. [Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") | Out-Null
  5. [Reflection.Assembly]::LoadWithPartialName("System.Drawing") | Out-Null
  6. [Reflection.Assembly]::LoadWithPartialName("Microsoft.DirectX") | Out-Null
  7. [Reflection.Assembly]::LoadWithPartialName("Microsoft.DirectX.Direct3D") | Out-Null
  8.  
  9. # Tworzymy okienko
  10. $form = New-Object Windows.Forms.Form
  11. $form.ControlBox = $false # Bo zamykanie niespecjalnie działa :P
  12. $form.Text = "Direct3D"
  13.  
  14. # Tworzymy urządzenie
  15. $pp = New-Object Microsoft.DirectX.Direct3D.PresentParameters
  16. $pp.BackBufferCount = 1
  17. $pp.Windowed = $true
  18. $pp.SwapEffect = [Microsoft.DirectX.Direct3D.SwapEffect]::Discard
  19. $pp.DeviceWindow = $form
  20. $pp.PresentationInterval = [Microsoft.DirectX.Direct3D.PresentInterval]::Immediate
  21. $dev = New-Object Microsoft.DirectX.Direct3D.Device @(0,
  22.     [Microsoft.DirectX.Direct3D.DeviceType]::Hardware, $form,
  23.     [Microsoft.DirectX.Direct3D.CreateFlags]::HardwareVertexProcessing, $pp)
  24.    
  25. # Przygotowujemy się do rysowania
  26. $dev.RenderState.Lighting = $false  # Wyłączamy oświetlenie
  27. $tri = New-Object Microsoft.DirectX.Direct3D.CustomVertex+PositionColored[] @(3)
  28. $tri[0] = New-Object Microsoft.DirectX.Direct3D.CustomVertex+PositionColored @(
  29.     0.0, 0.0, 0.5, [Drawing.Color]::Blue.ToArgb())
  30. $tri[1] = New-Object Microsoft.DirectX.Direct3D.CustomVertex+PositionColored @(
  31.     0.5, -0.5, 0.5, [Drawing.Color]::Red.ToArgb())
  32. $tri[2] = New-Object Microsoft.DirectX.Direct3D.CustomVertex+PositionColored @(
  33.     -0.5, -0.5, 0.5, [Drawing.Color]::Green.ToArgb())
  34.  
  35. # Wyświetlamy
  36. [Windows.Forms.Application]::EnableVisualStyles()
  37. $form.Show()
  38. $time = 0
  39. $lastTickCount = [Environment]::TickCount
  40.  
  41. # Pętlimy się
  42. while ($time -lt 5000) {
  43.     # Przetwarzanie komunikatów
  44.     [Windows.Forms.Application]::DoEvents()
  45.     $time += [Environment]::TickCount - $lastTickCount
  46.     $lastTickCount = [Environment]::TickCount
  47.    
  48.     # Rysujemy
  49.     $dev.Clear([Microsoft.DirectX.Direct3D.ClearFlags]::Target,
  50.         [Drawing.Color]::Lime, [float]1.0, 0)
  51.     $dev.BeginScene()
  52.         # Ustawiamy macierz obrotu
  53.         $angle = (10 * $time / 1000.0) / (2 * [Math]::PI)
  54.         $dev.Transform.World = [Microsoft.DirectX.Matrix]::RotationZ($angle)
  55.        
  56.  
  57.         # Rysujemy trójkąt
  58.         $dev.VertexFormat = [Microsoft.DirectX.Direct3D.CustomVertex+PositionColored]::Format
  59.         $dev.DrawUserPrimitives([Microsoft.DirectX.Direct3D.PrimitiveType]::TriangleList,
  60.             1, $tri)
  61.     $dev.EndScene()
  62.     $dev.Present()
  63. }

Przyznam, że byłem mocno zaskoczony, iż taki trik jest w ogóle możliwy przy pomocy czegoś, co w założeniu jest tylko powłoką tekstową dla poleceń administracyjnych. A tu proszę: DirectX w całej (aczkolwiek zarządzanej) okazałości!
Nietrudno rzecz jasna zauważyć, że powyższy skrypt jest w dużym stopniu tłumaczeniem na język PowerShella odpowiedniego kodu, który mógłby zostać napisany w dowolnym języku programowania z platformy .NET. Trzeba było jedynie poradzić sobie z pewnymi niedogodnościami, jak na przykład koniecznością ręcznego załadowania assemblies czy jakimś obejściem braku sensownej możliwości reakcji na zdarzenia – tutaj “program” po prostu kończy się po 5 sekundach.

Właśnie ta niemożność sprawia, że tandem PowerShell + DirectX zapewne nie ma przed sobą świetlanej przyszłości w grach :) Przez chwilę zastanawiałem się, czy wobec tego nie da się go użyć do tworzenia dem… Niestety, już powyższy skrypt zajmuje ponad 2 kilobajty, nie potrafiąc przy tym zbyt wiele, więc ta możliwość też prawdopodobnie odpada.
Pozostaje zatem pokazywanie podobnych trików linuksowcom i wytykanie im, że ich bash czegoś takiego nie potrafi ;D

Tags: , ,
Author: Xion, posted under Applications » 13 comments

Triki z PowerShellem #3 – PowerGUI

2008-06-03 20:29

Logo PowerGUIW Windows większość czynności administracyjnych można wykonać przy pomocy interfejsu graficznego. Wraz z wprowadzeniem PowerShella częściowo się to zmieniło, bo – jak to już kilka razy pokazywałem – stanowi on bardzo ciekawą tekstową alternatywę. Istnieje jednak narzędzie, które zamyka to kółeczko i powraca do interfejsu graficznego – to PowerGUI.
Screen z PowerGUIPomysł wydawać się może dziwny, bo przecież GUI nigdy nie osiągnie tego, co jest największą zaletą dobrej konsolki i powłoki tekstowej – ogromnej elastyczności. PowerGUI radzi sobie jednak całkiem nieźle, oferując spore możliwości dostosowywania tego, jakie informacje chcemy przeglądać i jakie dodatkowe akcje możemy na nich wykonać. Obie te rzeczy koduje się po prostu za pomocą poleceń PowerShella; mamy tu elementy zwane script nodes, które wyświetlane są w formie drzewka i po wybraniu prezentują rezultaty jakiejś komendy, np. listę wszystkich uruchomionych procesów (Get-Process). Dodatkowo możemy przypisać im też akcje wykonywane na zwróconych elementach lub odwołania do innych kolekcji obiektów (np. usług zależnych od danej).
Ogólnie pomysł wydaje się całkiem zgrabny i ma potencjał oszczędzania czasu – zwłaszcza że klepanie dość rozwlekłych komend PowerShella może być raczej męczące.

Screen z PowerGUi Script EditorWedług mnie znacznie przydatniejszą częścią PowerGUI jest dołączony edytor skryptów. To nic innego, jak (niemal) pełnowartościowe IDE do skryptów .ps1. Oprócz kolorowania składni oferuje ono debugowanie przy pomocy pracy krokowej i breakpointów oraz podglądanie wartości zmiennych – czyli prawie wszystko, co programiście do szczęścia potrzebne :)
I właśnie ten edytor jest, jak sądzę, najważniejszych powodem, dla którego powinniśmy rzucić okiem na PowerGUI, jeśli przynajmniej od czasu do czasu używamy PowerShella. Nie od rzeczy jest też argument, że cały ten pakiet licencjonowany jest jako freeware, więc możemy go używać bez ograniczeń do dowolnych celów. Zanim więc druga wersja PowerShella (która ma oferować między innymi środowisko graficzne) wyjdzie w świat, jest to całkiem rozsądna propozycja.

Tags: ,
Author: Xion, posted under Applications » 2 comments

Triki z PowerShellem #2 – Szybki upload

2008-05-24 12:52

Oto zadanie: mamy plik, który chcemy komuś przesłać przez Internet i mieć przy tym jak najmniej zawracania głowy. Jest oczywiście e-mail, są komunikatory, podprotokół IRC-a o nazwie DCC serwisy typu RapidShare, itd. Każdy z tych sposobów wymaga jednak albo wymiany jakichś informacji typu adres czy numer identyfikacyjny, albo nie zawsze chce działać w różnych konfiguracjach sieci (zwłaszcza gdy jedna ze stron jest ukryta za NAT-em), albo… wymaga wpatrywania się w literki celem odróżnienia psów od kotów :)
Jeśli jednak dysponujemy serwerem FTP z zawartością dostępną przez HTTP (czyli po prostu hostingiem strony WWW), to możemy dzielić się plikami w prostszy i szybszy sposób. W tym celu posłużyć się można odpowiednim skryptem w PowerShellu, który potrafi samodzielnie połączyć się z serwerem FTP i wgrać na niego podany plik, a potem zwrócić jego URL. Następnie możemy przekazać go osobie, której chcemy przekazać plik.

  1. # Send.ps1 - wysyła podany plik na serwer FTP i zwraca jego adres HTTP
  2. # Parametr: nazwa pliku lokalnego
  3. param([string]$file = $(throw "File not specified"))
  4. $filename = (New-Object IO.FileInfo @($file)).Name
  5.  
  6. # Stałe
  7. $SERVER = "moj.server.pl"
  8. $FTP_LOGIN = "loginFtp"
  9. $FTP_PASS = "hasłoFtp"
  10. $FTP_PATH = "/public_html/pub/upload/" # Ścieżka FTP do katalogu z uploadami
  11. $HTTP_PATH = "/pub/upload/" # Ścieżka HTTP do tego samego katalogu
  12.  
  13. # Odczytujemy plik
  14. $stream = New-Object IO.FileStream @($file, [IO.FileMode]::Open,
  15.     [IO.FileAccess]::Read, [IO.FileShare]::Read)
  16. $content = New-Object byte[] @($stream.Length)
  17. $stream.Read($content, 0, $content.Length) | Out-Null
  18. $stream.Close()
  19.  
  20. # Uploadujemy na FTP
  21. $url = "ftp://" + $SERVER + $FTP_PATH + $filename
  22. $ftp = [Net.FtpWebRequest]::Create($url)
  23. $ftp.Credentials = New-Object Net.NetworkCredential @($FTP_LOGIN, $FTP_PASS)
  24. $ftp.Method = [Net.WebRequestMethods+Ftp]::UploadFile
  25. $ftp.ContentLength = $content.Length
  26. $req = $ftp.GetRequestStream()
  27. $req.Write($content, 0, $content.Length)
  28. $req.Close()
  29.  
  30. # Kopiujemy URL do schowka
  31. # (działa w Windows Vista i 2003 Server; niżej opis alternatywy dla XP)
  32. "http://" + $SERVER + $HTTP_PATH + $filename | clip

Całkiem zmyślnie, prawda? Wystarczy jedynie odczytać lokalny plik, a następnie użyć .NET-owej klasy System.Net.FtpWebRequest w celu wykonania “żądania FTP” w postaci uploadu tegoż pliku na serwer.

Co jednak zrobić z takim skryptem, aby był użyteczny?… Jako że jego parametrem jest ścieżka do lokalnego pliku, który chcemy załadować, możemy użyć następującej komendy:

  1. powershell -Command . 'C:\Sciezka\Do\Skryptu\Send.ps1' '%1'

w celu jego wywołania – o ile potrafimy sprawić, by system Windows zamienił nam symbol zastępczy %1 na rzeczoną ścieżkę. Jest to możliwe przynajmniej na dwa sposoby:

  1. Menu Wyślij do z dodaną komendę uploadu FTPMożemy dodać nowe polecenie do podmenu kontekstowego Wyślij do, wyświetlanego dla każdego pliku w Eksploratorze Windows. W tym celu wystarczy stworzyć plik wsadowy (.bat) w katalogu SendTo, zawierający powyższą komendę, i nazwać go odpowiednio intuicyjnie. Po odświeżeniu Eksploratora, we wspomnianym menu pojawi się nowa pozycja, której wybór uruchomi nam nasz skrypt dla wybranego pliku.
  2. Innym wyjściem jest po prostu dodać nową akcję dla każdego typu plików, przez co będzie ona wyświetlania w głównym menu kontekstowym, obok innych: Otwórz, Edytuj, Drukuj, itd. Aby tego dokonać, najwygodniej jest po prostu otworzyć Edytor Rejestru i przejść do klucza HKEY_CLASSES_ROOT/*/shell. Tworzymy tam nowy podklucz, nazywając go jakoś odpowiednio (np. upload) i wpisując jako wartość domyślną tekst polecenia, który chcemy zobaczyć w menu (np. Upload). Następnie tworzymy tam podklucz command, ustawiając jego wartość domyślną na polecenia uruchomienia skryptu. Odświeżamy Eksplorator i mamy już nowe polecenie w menu kontekstowym.

Dodawanie akcji uploadu dla wszystkich plików w RejestrzeSprytne i wygodne. I kto teraz powie, że tylko w systemach linuksowych można bezustannie kombinować, by dostosowywać je do swoich potrzeb ;-)

PS. Użyty w skrypcie program clip jest bardzo prosty: kopiuje on po prostu swoje wejście do Schowka. Niestety, to malutkie narzędzie nie jest obecne w Windows XP. Nie ma tam więc prostego sposobu na wpisanie tekstu do Schowka z poziomu PowerShella. Alternatywą jest wypisanie URLa- do załadowanego pliku bezpośrednio w oknie konsoli PSh. Wystarczy po prostu zmienić clip na Out-Host, a także zmienić wywołanie skryptu, dodając parametr -NoExit:

  1. powershell -NoExit -Command . 'C:\Sciezka\Do\Skryptu\Send.ps1' '%1'

To sprawi, że o wykonaniu operacji konsola PowerShella pozostanie otwarta wraz z wypisanym w niej URL-em, który można z niej skopiować.

Tags: ,
Author: Xion, posted under Applications, Internet » 5 comments

Triki z PowerShellem #1 – GUI

2008-05-15 14:41

Windows PowerShell jest oczywiście powłoką tekstową z wierszem poleceń. Wszystkie więc czynności, jakie możemy w nim wykonać, wiążą się z wpisywaniem tychże poleceń i odczytywaniem wyników, podawanych także w postaci tekstowej. Prosto, minimalistycznie i naturalnie.

I właśnie dlatego jednym z pierwszym eksperymentów, jakie przy użyciu tego narzędzia wykonałem, była… próba wyświetlenia okienka z GUI :) Najpierw miało to być skromne okienko komunikatu (message box), jednak szybko okazało, że nie będzie to wcale łatwe. Domyślnie w PowerShellu nie jest bowiem załadowane assembly System.Windows.Forms, które to jest niezbędnie potrzebne do zabawy z okienkami. Nie oznacza to na szczęście, że oprócz jego załadowania należy też korzystać z niewygodnego interfejsu refleksji, aby cokolwiek przy jego użyciu zrobić (np. stworzyć obiekt klasy i wywołać jego metodę). Wystarczy po prostu jedno wywołanie w stylu:

  1. [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
  2. # Od .NET 2.0 ta metoda jest deprecated, ale tutaj nam to chwilowo nie przeszkadza ;-)

Okno komunikatu w PowerShellui od tej pory można już zupełnie normalnie korzystać z Windows.Forms… No, prawie. Możemy w każdym razie uraczyć się okienkiem komunikatu:

  1. [System.Windows.Forms.MessageBox]::Show("Hello world!", "Message",
  2.     [Windows.Forms.MessageBoxButtons]::OK,
  3.     [Windows.Forms.MessageBoxIcon]::Information)

A gdy już na nie popatrzymy, to pewnie zechcemy też czegoś więcej – na przykład “prawdziwego” okna, czyli zwykłej formy. To także jest do zrobienia:

  1. $form = New-Object System.Windows.Forms.Form
  2. $form.Text = "GUI!"
  3. [System.Windows.Forms.Application]::Run($form)

Bez większego problemu można by zresztą dodać do formy kontrolki potomne, jak przyciski czy pola tekstowe… Jest jednak jeden poważny problem: właściwie nie ma sposobu na podpięcie pod nasze kontrolki procedur zdarzeniowych – nawet mimo tego, że przy użyciu wyjątkowo perfidnej sztuczki da się w PowerShellu tworzyć delegaty. Stworzone okienka pozostaną więc na wpółmartwe i specjalną funkcjonalnością nas nie zaskoczą.

Tags: ,
Author: Xion, posted under Applications » 2 comments

Konsolka dla okien

2008-04-14 20:59

Zasadniczo to systemy uniksowe znane są z intensywnego wykorzystania trybu tekstowego, czyli wiersza poleceń konsoli. W przypadku systemu Windows wydaje się, że jest to bardziej pozostałość po starym (nie)dobrym DOS-ie, która została prawie całkowicie zastąpiona przez interfejs graficzny. Problem jednak w tym, że nie wszystko da się zawsze wygodnie wyklikać – a co więcej, takie czynności niezbyt nadają się do zautomatyzowania (na przykład po to, aby wielokrotnie przeprowadzać zmiany w konfiguracji na wielu maszynach). Mając elastyczny tryb tekstowy, zwykle bowiem wystarczy napisać odpowiedni skrypt; w przypadku trybu graficznego nie ma takiej możliwości.
Ten mankament był w Windows obecny od dawna i różne były sposoby na jego obejście – począwszy od plików wsadowych (.bat) przez eksporty/importy Rejestru (.reg), pliki .inf czy skrypty WSH (Windows Scripting Host). Te ostatnie są na przykład znane z powodu… kilku wirusów, które zdołały się szeroko rozprzestrzenić, wykorzystując tę technologię (np. słynny I.Love.You).

Logo PowerShellWszystkie podobne pomysły rozwiązywały jednak cały problem dość średnio. Lecz od jakiegoś czasu istnieje Windows PowerShell, który wydaje się znacznie ciekawszym rozwiązaniem. Jest to tekstowa powłoka poleceń – wraz ze skryptowym językiem programowania – która nie tylko jest o wiele bardziej przydatna niż wcześniejsze wynalazki Microsoftu, ale też wypada wcale nieźle w porównaniu z innymi shellami, jak choćby bash. Ma ona bowiem kilka interesujących cech szczególnych:

  • Pozwala wykorzystać wszystkie trendy technologie windowsowe, jak COM, WMI (Windows Management Instrumentation) i przede wszystkim .NET. Większość czynności “systemowych” można wykonać, korzystając z któregoś z tych narzędzi.
  • Zamiast na tekście, w tym shellu operujemy na obiektach. Możemy je tworzyć, przekazywać jako dane wejściowe do poleceń, modyfikować, filtrować, a także dobierać się do ich składników – odczytywać właściwości i wywoływać metody. W szczególności operator przetwarzania potokowego | powoduje przekazanie między poleceniami (a dokładniej tzw. cmdletami) obiektów, a nie zwykłego tekstu.
  • PowerShell unifikuje też sposób dostępu do różnych składników systemu, jak system plików, Rejestr czy zmienne środowiskowe. Dzięki temu nie trzeba do każdego z nich stosować innych narzędzi.

W tym momencie zapewne przydałby się wymowny przykład, który może wyglądać choćby następująco:

  1. ps | where { -not $_.Responding } | kill

To polecenie najpierw listuje wszystkie procesy w systemie (ps), następnie wybiera spośród nich te, które nie odpowiadają, aby w końcu posłać je do Krainy Wiecznych Zwisów :) Operujemy tutaj na obiektach reprezentujących procesy, a jedną z ich właściwości jest, jak widać, Responding, którą można użyć do filtrowania.
W pełnej wersji komenda wyglądałaby tak naprawdę następująco:

  1. Get-Process | Where-Object -filterScript { -not $_.Responding } | Stop-Process

co być może wygląda wymowniej, lecz jest z pewnością bardziej rozwlekłe. Na szczęście PowerShell definiuje fabrycznie kilkanaście aliasów, które mapują się na polecenia odpowiadające z grubsza tym znanym z innych shelli – jak dir, ls, cd, rm, ps, man czy type. To pozwala w miarę szybko poznać podstawowe komendy i przyspiesza ich wpisywanie.

Na koniec trzeba stwierdzić, że przydatność PowerShella zależy prawdopodobnie przede wszystkim od tego, czy potrafimy wykorzystać całe to ogromne bogactwo klas .NET, COM i WMI, które powłoka ta udostępnia. Jeśli tak, to możemy znaleźć dla niej szerokie pole zastosowań. Polecam w każdym razie przyjrzenie się temu wynalazkowi (dostępnemu na każdą sensowną wersję Windows, tj. od XP SP2 wzwyż). Sam lubię używać go do zabijania procesów znacznie bardziej niż standardowego Menedżera zadań ;-)

Tags: ,
Author: Xion, posted under Applications » 3 comments
 


© 2023 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.