A teraz drogie dzieci... kilka słów o sterownikach w Windows (i pingwinie też)

"Użytkownicy mieli przez kilka miesięcy problem w Linuxie z kartami NVidii i określonymi wersjami sterownika. Zawinił kowal, powiesili cygana" - tak mniej więcej można podsumować to, co ostatnio zaserwował nam na tym portalu jeden z kolegów.

Pomyślałem, że napiszę kilka słów na temat sterowników w najlepszym z najlepszych systemie świata.

Jak dobrze wiemy, to co nazywamy dzisiaj Windows 10, powstało jako kolejna iteracja połączonej bazy z dwóch linii oprogramowania, czyli

• Windows 9x (który to był nadbudówką na DOS-ie) i
• Windows NT (wynik pracy inżynierów podkupionych z Digital Equipment Corporation)

Przez lata w świecie PC dodawano kolejne kolejne technologie, takie jak Plug & Play, ACPI, USB, SATA czy NVME. Wywoływało to masę problemów (czy ktoś jeszcze pamięta blue-screen na prezentacji Windows 98 albo to, że USB w Windows 95 wymagało przynajmniej wydania OSR 2.1?) i związane było ze zmianą modelu sterowników. Niektóre z nich były mocno spektakularne - stąd np. firma Creative miała problemy z implementacją wszystkich funkcji w Viście. Wymienię tu tylko kilka nazw - VxD (Windows/386 2.x, Windows 3.x w trybie 386, Windows 9x / ME), WDM (Windows 98/ME, 2000 i późniejsze), XDDM/XPDM (dla kart graficznych w Windows 2000 / XP / Vista / 7) i WDDM (Vista i późniejsze). Kolejne kompilacje systemów wspierały kolejne wydania danego modelu (np. Windows 10 w wersji 1607 obsługuje WDDM 2.1, w wersji 1703 WDDM 2.2, w wersji 1709 WDDM 2.3, itd.), a kolejne wersje sterowników od Microsoftu miały nowe funkcje (np. obsługę dysków twardych o większej pojemności).

W wielkim uproszczeniu obecny model stara się być kompatybilny do przodu (tzn. sterownik do wersji X systemu powinien poprawnie udostępniać swoje funkcje w wersji X+1, ale niekoniecznie musi działać w Windows w wersji X‑1), sterowniki na poszczególne platformy są oddzielne, wydania dla 32‑bitowych i 64‑bitowych x86 również są oddzielne (to chyba jednak coraz mniejszy problem, bo praktycznie wszędzie widać 64‑bitowe Windows), a wersje 64‑bitowe generalnie wymagają podpisu cyfrowego Microsoft.

Cechą charakterystyczną Windows jest obecność czytelnego Device Managera (w którym możemy znaleźć np. identyfikatory urządzeń, takie jak VID i PID, niezbędne do wyszukania odpowiedniego oprogramowania). Firma z Redmond stara się mocno zapewnić sterowniki "generyczne" (dają one minimum funkcji dla całej klasy urządzeń, np. dla podobnych do siebie kart graficznych), a ponieważ nowych technologii jednak jest jakby coraz mniej (nie liczę przejścia na ARM), to nie trzeba już się bawić w dyskietki ze sterownikami dysku. Dużo się zmieniło również w sposobie dystrybucji, i o ile kiedyś użytkownicy zawsze wchodzili na stronę producenta urządzenia i pobierali stamtąd pakiety, to obecnie często poprzestają na tym, co przychodzi z Windows Update (czasami, jak w Windows S, jest to jedyna możliwość, gdyż instalacja aplikacji zewnętrznych jest zablokowana).

Teoretycznie wygląda to jak bajka, ale nie do końca - stąd takie problemy przy kolejnych "większych" wydaniach Windows 10.

W przypadku części urządzeń wciąż panuje niepisana praktyka, że "ogólne" sterowniki producenta nie pracują ze sprzętem tego producenta zamontowanym w konkretnych zestawach (np. tylko ze względu na inne identyfikatory). Taka naganna praktyka panowała przez długie lata np. u Intela, ale nie tylko. Duże korporacje praktycznie wszystkimi dostępnymi metodami (również brakiem wsparcia) próbowały "przekonać" użytkowników do zmiany sprzętu wraz z nową wersją systemu. Prowadziło to doprawdy do kuriozialnych sytuacji - czy ktoś pamięta jeszcze program Vista Ready, gdzie wiele komputerów większość czasu i wszystkie zasoby poświęcały na mielenie dyskiem i przetwarzanie zadań systemowych?

Pozostałością (czy też bardziej konsekwencją) tego myślenia są "własne" wersje sterowników np. od Della czy HP i przestarzałe wydania na stronach ich supportu (spojrzałem sobie przykładowo na stronę dla Precisiona 5510, a tam sterownik do grafiki Intela jest z 18.8.2020, i wątpię, żeby się zmienił, odkąd Intel dopuścił instalację "ogólnej" wersji), ciekawostką pozostaje brak czegokolwiek dla testowanego Mediona E4251 (można mówić, że to efekt taniej marki, z drugiej strony tak to powinno wyglądać od początku do końca i producent poza BIOS-ami nie powinien zbyt mocno "kombinować", skupiając się raczej na dobrym dopracowaniu samego sprzętu).

Nie jest idealnie, choć z drugiej strony myślę, że spokojnie powiedzieć, że obecnie zmniejsza się ilość sytuacji, gdy musimy szukać jakichś "dziwnych" wersji. Niespodzianki w sterownikach w przeszłości zdarzały się zresztą nawet największym (a przynajmniej o tych zrobiło się głośno swego czasu):

• https://www.howtogeek.com/307311/how-to-check-if-your-hp-laptop-has-th... - sterowniki Conexanta w 2015 i 2016 miały włączony debugging kodu
• keylogger w sterowniku HP Quick Launch Buttons (2017)
• https://www.techworm.net/2015/08/lenovo-pcs-and-laptops-seem-to-have-a... - aplikacja do update od Lenovo (która około 2015 doinstalowywała "niespodzianki")

W rozwiązaniu Microsoft dostrzec można dużą bezwładność - przykładem niech będzie to, że mikrokod do procesorów Intela potrafi być aktualizowany dopiero po pół roku (pisałem, jak sobie z tym poradzić). Zastosowany model powoduje również, że na dysku mamy zbyt wiele śmieci. Pakiety mają zbyt duże uprawnienia i robią co chcą, a i sam producent systemu doprowadza np. do tego, że w systemie z procesorem Intela na dysku leży sterownik do układu AMD. Zawsze mnie to ciekawiło - dlaczego np. nie można stworzyć API wymuszającego instalację sterownika w wersji X w wyznaczonym przez system katalogu (i tylko tam)? Albo dlaczego sterowniki mniej krytyczne nie mogą być z góry ograniczone tylko i wyłącznie do urządzenia ze swoim identyfikatorem? Chociaż https://www.windowslatest.com/2021/04/01/microsoft-wants-to-isolate-th... wygląda jak żart na Aprima Aprilis, to naprawdę by to się przydało...

System Windows to "stara szkoła", gdzie (przynajmniej na początku) próbowano oszczędzać zasoby używając wszędzie współdzielonych bibliotek. Nie powstał on od razu, i przez lata miał różne ograniczenia (np. na ilość uruchamianych równocześnie procesów czy ich wielkość). W Windows 9x każdy element miał dostęp do wszystkiego, dopiero potem zaczęto ograniczać dostępy, wprowadzać coraz więcej warstw, itp. I wszystko byłoby dobrze, gdyby nie to, że w którym momencie zatrzymano się w tym pędzie. Dzisiaj w dalszym ciągu mamy jeden proces paska zadań i explorera, i inne zaszłości. Zmieniono na szczęście chybioną decyzję o przeniesieniu sterownika grafiki do jądra, próby takie jak Windows 10 S (instalacja aplikacji i sterowników wyłącznie z Windows Store) idą duży krok do przodu, ale czy nie jest trochę późno? O dwudziestoletnim systemie plików i braku ReFS już wspominałem, tak samo o tym, że nie można po ludzku pobrać sobie wersji legalnie zakupionego systemu. A to przecież tylko wierzchołek góry lodowej.

Ostatnio sobie czytałem https://madaidans-insecurities.github.io/index.html. Narzędzia Open Source może i bywają gorsze pod względem jakości, ale... bez nich różne dyskusje techniczne nie wchodziłyby na tak wysoki poziom. Pamiętajmy, że ludzie wykształceni technicznie wykorzystywali, wykorzystują i będą wykorzystywać luki w zamkniętym czy to otwartym oprogramowaniu, i ukrywanie problemów / robienie blokad pod płaszczykiem zamkniętego kodu i kruczków prawnych jest strzelaniem sobie w stopę (w tym konteście śmieszy "blokada" NVidii na kopanie walut).

Czy w tej sytuacji narzekanie, że ktoś trzyma dosyć twardą reką rozwój sterowników w Linuxie, jest na miejscu? Zrozumiałe jest, że firmy chciałyby robić wszystko... czego przykład dał Intel i inni (np. nie trzymające jakości poprawki do procesorów, dystrybuowanie Intel ME poprzez firmy trzecie albo Android, gdzie w skrajnym wypadku może się zdarzyć, że producent publikuje tylko jedną wersję... i koniec).

A czy narzekanie na rozwój ABI jądra linuksowego jest na miejscu? Pewne rzeczy zmieniały się w przeszłości szybko (zgoda), obecnie mamy kilka wersji "długodystansowych" jądra. Proszę nie zrozumieć mnie źle - nie jest idealnie (co potwierdza chociażby https://madaidans-insecurities.github.io/guides/linux-hardening.html#s...), za to równocześnie dużo się dzieje w tym kodzie, i jest to jeden z powodów, że są i zmiany w ABI. Dyskusje bywają gorące i są one dostępne dla publiczności - na pewno wywołuje to inny odbiór niż przedstawienie gotowych zmian przez Microsoft na zasadzie "resistance is futile" + "wszystko jest dopracowane".

To które rozwiązanie jest najlepsze?

Zgodnie ze starym powiedzeniem "czy Plus czy Era, jedna cholera".

Powtórzę: rozwiązania w jądrze linuxowym nie są najlepsze z możliwych (w sumie ciekawe, czy problemy z Wayland w Linuxie z kartami NVdii wynikają z jakości otwartego kodu czy jakości wsparcia tej firmy), ale przynajmniej wszystko dostaję na raz, bez setek MB, i jeśli mam najnowszą stabilną wersję jądra z tych krótko-okresowych, to nie jest to skansen.

Microsoft był kiedyś firmą, która swoimi złymi i dobrymi decyzjami pchnęła świat x86 do przodu. Obecnie jednak ten pociąg odjechał z Redmond, i nie można odcinać kuponów w nieskończoność. To boli - nie samym Windows użytkownicy żyją, jest Linux, ChromeOS i kilka innych mocnych alternatyw. Jeżeli korporacja chce być konkurencyjna, to i Windows musi się stać nowoczesnym systemem z prawdziwego zdarzenia, gdzie aplikacje są separowane jak należy.

Jak dla mnie ciekawe jest jedno - jak to się dzieje, że właśnie na przykład Intel potrafi przedstawiać różne specyfikacje? Panu Bogu świeczkę, a diabłu ogarek? I jak to się dzieje, że jest problem ze sterownikami do Rocket Lake pod Windows? Że były problemy z grafiką pod Microsoft Surface? I jak to się dzieje, że pod pingwinem często i gęsto widzę znacznie więcej informacji i ustawień dotyczących sprzętu?

Wielu z nas ma w głowie właśnie taki obraz użytkowników tego systemu, z drugiej strony również dzięki takim jak oni nie udało się wdrożyć zasady "płać i płacz".

Jego elementy widać jak na dłoni - udawanie, że problemów nie ma i odsyłanie od firmy do firmy (to jeden ze sposobów rozwiązywania ticketów serwisowych), albo... (moje ulubione) montowanie matryc X (z PWM) albo Y (bez PWM) w kolejnych egzemplarzach jednego modelu i brak możliwości sprawdzenia tego kluczowego faktu przed zakupem (konia z rzędem, kto znajdzie to w Chromebooku).

Moje podsumowanie - w wielu wypadkach przestaliśmy zwracać na problemy ze sterownikami w Windows, bo i używany przez nas sprzęt jest znacznie bardziej monotematyczny niż kilka lat temu (królują chociażby dosyć podobne laptopy, a technologie są bardziej na etapie dopracowywania niż dodawania). Żeby było naprawdę lepiej, Microsoft musiałby dużo zmienić i dostarczyć rewolucję na miarę przejścia z Windows 9x na NT.