Windows 11: co robi, gdy nikt nie patrzy? Część 5

System Windows uruchamia i utrzymuje wiele procesów pracujących w tle i/lub podczas bezczynności, ale jest to także przypadłość wielu popularnych programów. Dlaczego aplikacje robią tak wiele za naszymi plecami i czy mamy z tego jakąś korzyść?

Głównym zajęciem wykonywanym w tle przez aplikacje w Windows 11 jest aktualizacja, drugim - telemetria. Wynikają one, wbrew pozorom, z doraźnego łatania braków funkcjonalnych w Windows. Microsoft przez wiele lat obiecywał rozwiązanie wielu problemów, nigdy nie dostarczając w pełni żadnego rozwiązania. Zarówno w kwestii aktualizacji, jak i inwentaryzacji i zgłaszania błędów. Dlatego twórcy oprogramowania muszą radzić sobie sami.

Aby zrozumieć te powody, należy przyjrzeć się mechanizmom aktualizacji dostępnym w Windows. Chodzi zarówno o usługi, jak i o format samych pakietów instalacyjnych. W przypadku usług mowa o Windows Update i sklepie Microsoft Store. Producent zewnętrznego oprogramowania ma ograniczony zbiór możliwości ich użycia. Windows Update nie umożliwia dystrybuowania aktualizacji do produktów innych niż Windows i kilka innych produktów Microsoftu (Office w większości przeszedł już na własny aktualizator).

Dalsza część artykułu pod materiałem wideo

Podpięcie zewnętrznych dostawców jest możliwe tylko w przypadku sprzężenia stacji z mechanizmem WSUS, stosowanym wyłącznie w przedsiębiorstwach i dużych organizacjach. Dystrybuowanie pakietów tą drogą wymusza także na dostawcy przygotowanie repozytorium i pakietu w odpowiednim formacie. Ponieważ ten sposób instalacji jest niedostępny dla klientów indywidualnych, a nikt nie lubi utrzymywać wielu instalatorów, tylko nieliczne programy są możliwe do instalacji w taki sposób.

Sklep Windows ma inne problemy. Historycznie, był bardzo mało dostępny, co zmieniało się niezwykle powoli. Początkowo oferował jedynie aplikacje korzystające z API WinRT ("kafelkowe"). Później otworzył się również na klasyczne aplikacje, pod warunkiem dystrybuowania w formacie MSIX. W dalszej kolejności usunął (w większości przypadków) konieczność korzystania z konta Microsoft. W końcu możliwe stało się także publikowanie klasycznych instalatorów - co z kolei pozbawiło możliwości dostarczania do nich aktualizacji. Ze względu na niedostępność lub nieobecność sklepu w wielu wariantach Enterprise i Server, popularność publikowania i aktualizowania gier przez Sklep jest jeszcze niższa. Przez wiele lat sytuację pogarszał również wysoki udział rynkowy systemu Windows 7.

W rezultacie wiele aplikacji aktualizuje się samodzielnie. Robią to za pomocą własnych usług, wzbudzanych na żądanie z Harmonogramu Zadań lub z samej aplikacji. Minęły już na szczęście czasy aktualizatorów pracujących w tle cały czas (Java), ale obecność np. pięciu usług aktualizujących po jednej aplikacji nie jest optymalnym rozwiązaniem. Robią tak między innymi Firefox, Thunderbird i Adobe Reader, Microsoft Edge, Office a od pewnego czasu także OneDrive. Braki w procesie udostępniania sterowników i firmware'u przez Windows Update omijają także aktualizatory sterowników dostarczane przez producentów sprzętu (Lenovo, Dell, Gigabyte).

W tle pracują także aktualizatory, które samodzielnie zarządzają licencjonowaniem oprogramowania. Przede wszystkim jest to Adobe Creative Cloud, Steam oraz wszelkie "launchery" do gier, jak np. EA Desktop lub Battle.net. Autorskie mechanizmy DRM byłyby niestety niemożliwe do udostępnienia przez systemowe mechanizmy aktualizacji.

Jest też wiele aktualizatorów pracujących całkowicie w przestrzeni użytkownika, obsługujących aplikacje instalujące się w niezwykle niekorzystnym pod względem bezpieczeństwa, acz niewymagającym żadnych uprawnień, katalogu AppData. Instaluje się tam większość aplikacji Electron, jak Slack, Discord, Chrome (!), GG, Visual Studio Code, Teams, Telegram i Signal. Ich aktualizacja polega na pobraniu w tle katalogu z nową wersją aplikacji i uruchomieniu aplikacji z nowej lokalizacji przy najbliższym restarcie. Proces ten przeprowadza sama aplikacja, często korzystając z odpowiednich ogólnodostępnych (acz nieobecnych w Windows) bibliotek. Przeprowadza go - bo nie ma w systemie mechanizmu, któremu jest w stanie to zlecić. Może najwyżej poprosić usługę BITS o pobieranie z kontrolą przepustowości i priorytetu.

Podobny problem występuje z dostępem do raportów o błędach. Domyślnie, raport kolekcjonuje systemowe narzędzie do zgłaszania błędów (WerFault) i wysyła zrzut pamięci z logami… do Microsoftu, a nie do twórcy oprogramowania. Ma to na celu zidentyfikowanie w Redmond, czy problem wynika z jakiejś wprowadzonej niekompatybilności. Ten sam raport bywa jednak przydatny także dla twórcy aplikacji. Windows jednak nigdy mu go nie wyśle. Dlatego aplikacja albo zbiera raport samodzielnie, albo dostaje się do poprzez API do magazynu zrzutów WER.

Połączenie obu zagadnień (aktualizacje i telemetria) jest stosowane w programie Google Chrome, gdzie poza aktualizatorem (GoogleUpdate) i reporterem błędów (GoogleCrashHandler) może pracować także inwentaryzator oprogramowania i rozszerzeń (Software Reporter Tool). Narzędzie to pracuje w tle dlatego, że Google odrobił lekcję, o której zapomniał Microsoft: wina za awarię ich oprogramowania wynikającą z działania programów trzecich i tak zostanie przypisana samej aplikacji. Dlatego Chrome sam sprawdza system pod kątem znanych złodziei pamięci podręcznej, złośliwych rozszerzeń, nieobsługiwanego sprzętu, problemów ze sterownikami audio/wideo i uszkodzoną konfiguracją.

Aplikacje działające w tle prezentują sobą dwa główne problemy: wprowadzają dodatkowe procesy/narzędzia, duplikujące te już istniejące i pracują bez informowania użytkownika na temat tego, co dzieje się pod spodem. Jak należałoby rozwiązać pierwszy problem? Microsoft musiałby pozwolić aplikacjom firm trzecich rejestrować swoje repozytoria do Windows Update tak, by system sam mógł aktualizować aplikacje. Jednak już w 2012 roku stało się jasne, że nagły skręt Microsoftu w stronę całkowicie konsumenckiego Sklepu oznacza, że nic takiego nie nastąpi, a problem pozostanie nierozwiązany na zawsze. Drugim ułatwieniem byłoby wprowadzenie mechanizmu dzielenia się zrzutami pamięci z błędów z dostawcami aplikacji. Te dwa rozwiązania znacząco zmniejszyłyby liczbę procesów pracujących w tle. Ale do takich wytycznych nie stosuje się nawet sam Microsoft - czego przykładem są Office, Teams, Skype, Edge i OneDrive.

A gdyby tak wyłączyć wszystkie te narzędzia? Niestety, ze względu na specyfikę rozwoju dzisiejszego oprogramowania, rezultat byłby inny niż myśli wielu zwolenników ekstremalnego uciszania i blokowania Windowsów. Brak raportów o błędach i aktualizacji poskutkowałby tym, że błędy są naprawiane wolniej, programy mają więcej problemów ze zgodnością i więcej użytkowników jest narażonych na dziury w zabezpieczeniach - co w przypadku przeglądarek internetowych i komunikatorów jest poważnym problemem.

Niestety, złożoność zagadnienia sprawia, że rozwiązaniem jest równanie do wspólnego mianownika. W rezultacie w przeciętnym systemie Windows pracują dziesiątki mniejszych aktualizatorów. Problem ten jest rozwiązany o wiele lepiej w systemach Android i pecetowych Linuksach, gdzie stosowany jest centralny punkt instalacji i aktualizacji oprogramowania. W Windowsie się na niego nie zanosi. Istnieje mechanizm, który wydaje się rozwiązywać wszystkie te problemy - zwany APPX AppInstaller - ale jego dostępność zależy od wersji systemu, a i samo protokół okazuje się cierpieć na przewlekłe problemy z bezpieczeństwem.