Windows 7 musi odejść: oto powody utraty wsparcia

Użytkownicy mają na ten temat cały arsenał teorii, z których niemała część jest kompletnie nonsensowna. Jedną z popularniejszych, acz zarazem najbardziej nonsensownych, jest… spisek. Microsoft miałby bowiem dopuszczać się przekupstwa względem dostawców oprogramowania, celem skłonienia ich do wprowadzenia blokad powstrzymujących programy przed działaniem na Windows 7. Ta fantastyczna teoria miewa zaskakująco wielu zwolenników, choć jest z dość oczywistych powodów sprzeczna wewnętrznie i niespójna.

Wielu twórców oprogramowania pracuje w bezpośredniej konkurencji względem Microsoftu i tajne bratanie się z wrogiem nie miałoby uzasadnienia. Zresztą, nikt nie chce z własnej woli redukować zbioru potencjalnych odbiorców produktu. Wreszcie, niekompatybilności wcale nie są blokadami, a rzeczywistymi funkcjami, które po prostu nie działają.

Innym często przytaczanym powodem jest lenistwo. Programistom miałoby bowiem sprawiać zbyt wiele zachodu testowanie aplikacji na większej liczbie platform, wskutek czego wybierają najmniej wymagającą ścieżkę - czyli test wyłącznie na najnowszej wersji. Niniejsza hipoteza zakłada, że software jest najwyraźniej pisany hobbystycznie lub bez żadnej strategii - podczas gdy w procesie wytwarzania oprogramowania robi się po prostu wyłącznie to, co zarabia pieniądze.

Co jest więc powodem utraty kompatybilności z Siódemką, skoro - wedle popularnej opinii - nowsze Windowsy są gorsze, cięższe i pełne samych zbędnych rzeczy? Najlepszym sposobem na znalezienie odpowiedzi na to pytanie będzie porównanie zmian w kodzie między "wspieraną" a "niewspieraną" wersją jakiegoś dużego projektu o otwartych źródłach. Doskonałym przykładem jest Chromium. Z jego głównej gałęzi wypadają właśnie spore ilości kodu właśnie w związku z utratą obsługi Windows 7. Przyjrzyjmy się diffom załączonym do ticketa #1385856.

W plikach obsługi wejścia audio usuwane są ify zapewniające działanie w przypadku braku obsługi dźwięku 5.1 w Media Foundation AAC, debiutującej dopiero w Windows 10. Podobnie sprawa się ma z obsługą filtrów dla efektów dźwiękowych oraz interfejsem menedżera urządzeń dla DirectX Graphics Infrastructure. Zmianom ulega także działanie kamer internetowych - od teraz możliwe jest wykorzystanie systemowego API do sprawdzania czy kamera jest wbudowana i czy jest skierowana w stronę twarzy użytkownika. Na starych Okienkach nie działa również kodek VP9.

Zmiany w plikach obsługi żądań URL dotyczą wykrywania proxy. Jego obsługa była wyłączona w kodzie dla Windows 7 ze względu na nigdy niepoprawiony przez Microsoft błąd, w którym rozwiązywanie żądań proxy blokowało je na 30 sekund i zawsze kończyło niepowodzeniem. Z kolei w plikach z kodem rysującym główne okno usunięto ograniczenia maksymalnej rozdzielczości - Vista i 7 obsługiwały maksymalnie 4096x2048.

Porządki nie ominęły także silnika Blink. Usunięto wszystkie wyjątki w rysowaniu znaków za pomocą DirectWrite. Od teraz Blink korzysta z pełni możliwości tego API, zamiast wykrywać które jego funkcje są dostępne i dynamicznie dostosowywać wywołania. Blink działa w Chrome we współpracy z usługami, wykorzystując wejście np. z detektora kształtów lub tekstu. Po porzuceniu wsparcia dla Windows 7, usługi te wykorzystują natywne systemowe API, np. do OCR lub sprawdzania pisowni.

Wyrzucane są też wszystkie alternatywne sposoby rysowania okna zakładające, że kompozytowy menedżer okien (DWM) nie istnieje lub może zostać wyłączony. Obsługa całkowitego braku DWM pamiętała czasy XP, a wykrywanie jego działania - Vistę. Od teraz w Chrome cały kod rysujący zakłada, że DwmIsCompositionEnabled() zawsze zwraca prawdę, co pozwoliło usunąć sporo kodu obsługującego inne przypadki, upraszczając implementację.

Jedynie skromny zestaw wprowadzonych zmian dotyczy instalatora lub launchera, które zaopatrzono w sztywną weryfikację przeciw uruchomieniu na Windows 7. Zdecydowana większość niekompatybilności to porządki: usuwanie rzeczy zaimplementowanych podwójnie. Częściowo oraz kompletnie. Błędnie oraz poprawnie. W starym oraz nowym API. I tak dalej.

Podwójna implementacja oznacza, że od początku planowano się pozbyć tej słabszej. No dobrze, ale dlaczego uzależniać wobec tego wsparcie od obsługi technicznej, a nie od udziału w rynku? Można zrozumieć porzucenie Visty, ale Siódemki wciąż używa całkiem sporo osób. W przypadku projektów tak wielkich, jak Chromium w grę wchodzi nieco inny rodzaj wsparcia: wolę naprawy błędów odnalezionych podczas prac nad programem.

Od teraz, gdy Google znajdzie naprawdę zawstydzającą fuszerkę w Siódemce - błąd uniemożliwiający dalszą pracę - Microsoft rozłoży ręce i powie, że niczego nie będzie poprawiać. Dlatego lepiej porzucić wsparcie dla takiego systemu. Problemy z działaniem zostałyby przypisane Chrome'owi. I zaszłaby konieczność ich naprawy właśnie po jego stronie.

Oczywiście, powodów jest więcej - jak na przykład kompilatory i uciekający runtime. Nie da się w nieskończoność pisać programów w starożytnym dialekcie C++, który w dodatku tylko rymuje się najwyżej z jakimś standardem. A następnie kompilować tego na Visual Studio 2010. Ale nie trzeba się sięgać tak daleko. Zmiany w Chromium pokazują całkiem jednoznacznie, jak jest koszt utrzymywania starych systemów, z wybrakowanymi API i nienaprawionymi bugami.