.NET Framework już natywnie na ARM, ale jest haczyk

Swoją premierę miała właśnie nowa wersja .NET Framework oznaczona numerem 4.8.1 Przejdzie ona do historii jako pierwsza wersja tego frameworku Microsoftu, która umożliwia opracowywanie aplikacji, które działać będą natywnie na architekturze Arm64. Można więc mówić o małym przełomie.

Arm64 już w .NET Framework

Dlaczego natywna obsługa Arm64 w .NET Framework jest tak ważna? Otóż może stanowić ważny impuls dla deweloperów, dużą zachętę dla nich, by zacząć już wydawać swoje aplikacje, dotychczas działające wyłącznie na x86.

A to dla Windowsa całkowicie nowe perspektywy i szansa, aby pójść w większym stopniu śladami Apple, co może być konieczne, jeśli Microsoft ma jeszcze zamiar kiedyś zawalczyć na poważnie o rynek konsumencki. To, biorąc pod uwagę na sukcesy Redmond w pracy z klientami korporacyjnymi, nie jest jednak ani wcale takie oczywiste, ani Microsoftowi szczególnie potrzebne.

Windows 10 i 11 działają na procesorach ARM już od dawna, część pamięta jeszcze zapewne Windowsa RT. Jednak nadal trudno w ogóle porównywać możliwości tego systemu na platformie ARM z jego możliwościami x86. Przede wszystkim za sprawą właśnie ubogiego ekosystemu deweloperskiego – dotąd wykorzystywać trzeba było emulację, co oczywiście miało narzut na wydajność i w ogóle komfort pracy nad oprogramowaniem, choćby przez to, że taki model był sprzeczny z respektowaną przez wielu deweloperów zasadą, aby rozwijać soft na takiej platformie, na jakim ma on docelowo działać.

To nie zachęcało deweloperów, by poświęcać czas na optymalizację, zwłaszcza że trudno też powiedzieć, aby liczba ARM-owego sprzętu z Windowsem była przytłaczająca. Nawet projektowane hybrydy Surface z linii Go nie stały się w zasadzie niczym więcej niż ciekawostką. Nie przysłużył się temu także chaos związany z klęską Universal Windows Platform i losy licznych frameworków, które na powrót zostały zunifikowane z Win32.

Nowe możliwości dla deweloperów

Należy zważyć, że natywne wsparcie dla Arm64 właśnie zaimplementowano w .NET Framework 4.8.1, niemniej w przypadku .NET Core także możemy już liczyć natywną kompatybilność z Arm64 zarówno na układach Apple M1, które przez ostatnie kilkanaście wyrosły na poważną platformę deweloperską, jak i innych, mniej popularnych.

Dotąd przez lata Microsoft wielokrotnie zmieniał koncepcję tego, jak ma być tworzone oprogramowanie na Windowsa i tego, jak ma ono działać. Wraz z unifikacją w ramach .NET, pogrzebaniem pamiętającym czasy Windows Phone’a reliktem w postaci Universal Windows Platform wraz z mostkami Project Cenntenial, Redmond demonstruje więc nie tylko chęć uporządkowania sytuacji, ale też oddaje w ręce deweloperów konktrente, działające narzędzia. 

Otworzenie ekosystemu swojego deweloperskiego na natywną kompatybilność z Arm64 zdaje się w takich okolicznościach być bardzo dobrą, wręcz konieczną decyzją, zwłaszcza jeśli przedsięwzięta przez Panosa Panaya misja dostarczania na rynek oprogramowania Microsoftu na autorskim sprzęcie na modłę Apple ma być w przyszłości traktowana poważnie. Wobec x86 w takim scenariuszu trudno bowiem żywić większe nadzieje, o czym pisałem w osobnym artykule.

Ograniczona kompatybilność 

Jednak jak to zwykle bywa, gdzie drwa rąbią, tam wióry lecą. Natywną obsługę Arm64 .NET Framework przepłacił bowiem ograniczeniem kompatybilności ze starszymi wersjami Windowsa. Nawet tych, które mają jeszcze aktywny cykl życia i są aktualizowane przez Microsoft. Na nic się to jednak zdało, gdyż z .NET Framework 4.8.1 skorzystamy jedynie na Windowsie 11, Windowsie 10 od wersji 20H2 w górę oraz systemie Windows Server 2022. W ostatnim przypadku mowa oczywiście o pracy na x86_64 i emulacji ARM, niemniej nie od dziś wiadomo, że prace nad serwerowym ARM-owym Windowsem trwają od dawna. 

Microsoft niestety nie wyjaśnia precyzyjnie, jakie przeszkody techniczne uniemożliwiły zapewnienie zwiększonej dostępności najnowszej wersji .NET Framework na większej liczbie własnych systemów operacyjnych, nawet jeśli miałby on na nich zostać okrojony z części funkcji. Zwłaszcza że problem nie jest błahy – frameworka w wersji 4.8.1 nie zainstalujemy na przykład na Windows Server 2019, który nadal jak najbardziej jest wspieraną i na bieżącą aktualizowaną platformą i mógłby nadal obsługiwać ARM przez emulacje, utrzymując dostępność najnowszej wersji .NET Framework.