Co się dzieje z PowerShellem? Nowych wydań coraz mniej

Środowisko PowerShell kończy w tym roku dwadzieścia lat. Jego architekt, Jeffrey Snover, chciał połączyć zalety skryptów powłoki Unix z potęgą programowalnego mechanizmu obiektów i komunikacji międzyprocesowej (DCOM) z Windows. "Plikowe" podejście znane z Uniksa oraz ograniczenia windowsowego wiersza poleceń sprawiły, że zamiast rozszerzać natywne środowisko, zdecydowano się stworzyć nowe i oprzeć je o .NET.

Dziesięć lat później, PowerShell został wydany jako open source, podobnie jak nowe wersje .NET. Ani jedno, ani drugie nie zostało dołączone do nowych wersji Windows. W przypadku frameworku .NET, powód tej decyzji był jasny. Choć środowisko było dołączone do systemu, nie było gwarancji, że jest odpowiednio nowe (.NET FX był aktualizowany częściej niż Windows), więc oprogramowanie wymagające go zawsze i tak dostarczało własną kopię. W rezultacie oraz wskutek przejścia rozwoju .NET na szybszy harmonogram, zadecydowano, że aplikacje będą dostarczać .NET samodzielnie - i to nawet niekoniecznie doinstalowując go do systemu, a trzymając kopię runtime'u "u siebie".

W przypadku PowerShella to wytłumaczenie jest słabsze. De facto powody nieaktualizowania tego środowiska były odmienne. PowerShell 6 przeszedł na nowy .NET, więc musiałby albo doinstalowywać go i utrzymywać, albo dostarczać go ze sobą w postaci wielkiej paczki. Na początku .NET nie był aktualizowany przez Windows Update, a systemowy sklep umiał zarządzać tylko aplikacjami WinRT/UWP. PowerShell pozostał bez mechanizmu utrzymywania go w systemie.

Siłą inercji w Windows pozostał więc stary PowerShell. Formalnie powodem była kompatybilność. PowerShell był środowiskiem uruchomieniowym tysięcy skryptów administracyjnych, dla których zmiana ABI mogłaby się zakończyć masowymi problemami. Z drugiej jednak strony PowerShell stał się zamrożony na wersji sprzed wielu lat. Zadania administracyjne wymagające nowego PowerShella musiałyby najpierw zainstalować go, co może prowadzić do problemu jajka i kury.

Ponadto, przez długi czas, nowy PowerShell nie był wcale taki łatwy w dystrybucji. Do scenariuszy nienadzorowanych przeznaczone były pakiety MSI, czyli dość "klasyczna" metoda masowych wdrożeń. Dopiero nadchodząca wersja 7.7 będzie stosować instalatory MSIX, umożliwiające więcej scenariuszy dystrybucji. Ale… już jest z nimi problem. Oprogramowanie dostarczane przez MSIX w celu powstrzymania programistów przed wykonywaniem arbitralnych czynności pozwala na mniej.

Jest to otwarty problem, który może wręcz opóźnić wydanie wersji finalnej 7.7. Format MSIX jest nowoczesny, ale dla niektórych scenariuszy jest "za nowy". Powstał gdy narzędzia systemowe uznawano za element… systemu. A nie sklepu. Ten sam problem dotyczy Visual Studio Code i jego wersji sklepowej. Systemowa piaskownica i brak wyjątków nawet dla systemowych aplikacji okazują się przeszkadzać.

Podczas gdy PowerShell 7 jest narzędziem administracyjnym, którego nie da się zainstalować, PowerShell 5.1 jest nierozwijany. A PowerShell 2.0 został usunięty - Microsoft planuje pozbyć się obsługi języka Visual Basic Script, także bardzo rozpowszechnionego środowiska dla skryptów administracyjnych. W rezultacie, choć Windows Terminal otrzymuje kolejne nowości, środowiska które eksponuje stoją w miejscu.

Ale spójrzmy na to z innej strony - taki Bash też nie rozwija się specjalnie żywiołowo. Nie jest tak, że skoro PowerShell 5.1 pochodzi z 2016 r., to nie da się w nim zrobić nic nowszego. Większość funkcji systemowych jest eksponowana jako interfejsy i obiekty COM/CIM lub inne programowalne API, do których "stary" PowerShell może swobodnie sięgać. Z pewnego punktu widzenia nie ma żadnej potrzeby, by coś tutaj zmieniać.

Czyni to jednak nowego PowerShella problematycznym środowiskiem, którego bardzo często po prostu nie warto używać, mimo usprawnień. Choć jest doskonałym środowiskiem programistycznym o rozbudowanym zbiorze pakietów trzecich, oprogramowanie będzie raczej celować we wspólny mianownik, jakim jest wersja 5.1. Nowy PowerShell znacznie lepiej odnajdzie się jako zaawansowana powłoka (w tym na Linuksa!) niż administracyjne narzędzie do masowych automatyzacji nienadzorowanych.