Nie było przesady w spostrzeżeniu, że sporo z najważniejszych nowości zaprezentowanych podczas tegorocznej wirtualnej odsłony konferencji Build dotyczyło integracji z systemami linuksowymi, bądź też implementacji w Windowsie funkcji zapożyczonych z systemów linuksowych. Nie mniej istotną zapowiedź stanowił także Project Reunion, który złośliwy mógłby określić jako przejaw bohaterskiego rozwiązywania przez Microsoft problemów, które sam wygenerował. Czym więc jest, a czym niestety nie Project Reunion?

Tło historczyne

Jego genezy musimy szukać jeszcze w erze Windowsa 8. Najbardziej przyciągającym uwagę (i zniechęcającym użytkowników) był tam interfejs zgodny z Metro UI, który nie przetrwał próby czasu. Znacznie bardziej żywotne okazało się API WinRT, które miało docelowo zastąpić Win32. WinRT dysponowało bowiem takimi mechanizmami, jak możliwość izolowania aplikacji w piaskownicach, co bezpośrednio przekładało się na bezpieczeństwo systemów rozwijanych przez Microsoft.

WinRT wyewoluowało w Windows Universal Platform, popularyzowany już w czasach Windowsa 10. Niestety, aplikacji UWP powstawało relatywnie niewiele, zaś przyzwyczajenia milionów użytkowników Windowsa kierowały ich przede wszystkim w stronę znanych programów Win32. Nie pomogła także chęć centralizacji dystrybucji oprogramowania w postaci pustawego Microsoft Store oraz porzucenie prac nad mobilnym wariantem Windowsa, który stanowił dla utrzymania UWP uzasadnienie.

Czas na Reunion

Osiem lat po premierze Windowsa 8 i 5 lat po premierze Windowsa 10 Microsoft musiał wypić piwo, którego sam nawarzył, dostarczając równolegle dwa deweloperskich API. W końcu w Redmond ktoś przejrzał na oczy i spostrzegł, że Universal Windows Platform nigdy nie zastąpi Win32 i trzeba coś z tym faktem począć. Tak właśnie powstał Project Reunion, który ma na celu ponowne złączenie dwóch dróg. Dzięki temu interfejsy Win32 i WinRT mają stać się jednością.

Aby zrealizować ten cel, Microsoft ujednolici dostęp do API Win32 i UWP. Dwa osobne byty zastąpi jedno Reunion API, do którego odwoływać się będą mogły zarówno aplikacje Win32 (lub desktopowe, jak woli nazywać je Microsoft), jak i programy z Universal Windows Platform. Ważną rolę w tym procesie ma także odegrać opisywany już na blogu framework WinUI, który już wcześniej zapowiadany był jako lekarstwo na rażącą dychotomię pomiędzy interfejsami UWP i Win32.

Czy to się może udać?

Project Reunion jest więc decyzją oczekiwaną od dawna, problem rozbieżności wynikających ze współistnienia dwóch interfejsów API w obrębie jednego systemu operacyjnego jest dostrzegalny od lat. Otwartym pozostaje pytanie o skuteczność zastąpienia dwóch API przez trzecie. Same nasuwają się porównania z próbami zastąpienia UWP przez Win32. Skoro bowiem UWP nie udało się zastąpić Win32, to dlaczego Reunion miałoby zastąpić Win32 i UWP?

Być może potrzebne jest zdecydowane cięcie, a nie rozłożone na lata próby łączenia tych lub innych funkcji obu interfejsów. Słowem – szybkie cięcie, które ukróci dotychczasowy nieład, a nie odpowiednik uporczywej terapii. Komentatorzy zauważają także pewną lukę w całym przedsięwzięciu, a jest nią, a jakże, jest Microsoft Store. Jakie losy czekają ten sklep i jaką funkcję będzie pełnił w nowych, reunifikowanych warunkach? A może zniknie, zastąpiony przez interfejs na Windows Package Managera? Czas pokaże.