Nová macOS 10.15 Catalina je už venku nějakou dobu, dokonce v tenhle okamžik 10.15.1 s opravou snůšky vážných chybek a Safari. Nevím, jestli na to hodně lidí čekalo s nadšením nebo bez něj, to asi není zajímavé, ostatně nějaké změny mediálních aplikací, předělání upomínek, odebrání Dashboardu a další negativní zásahy do plynulosti ovládání nejsou asi až tak zásadní. O čem se málokdo zmiňuje, je konečně kompletní přechod macOS na plně 64bitovou architekturu x86_64. Oujé?
Možná se to zrovna teď, v roce kdovíjakým, už zdá hloupé, když se neustále mluví o nových ARMech (aarch64), případně o spekulacích s využitím RISC-V, a architektura x86 a s ní související x86_64 pomalu, ale jistě vymírá. Důvodů je rozhodně více, historická zátěž je pro přední výrobce limitující faktor, ale obecně architektura umírá na svou zpětnou kompatibilitu. Pamatuji si, že nástup prvních 64bitových x86 systémů ohlásili v AMD už docela dávno a někdy kolem roku 2006 se to celé už rozjelo naplno, s tím pak Intel začal leštit své stroje v tichosti přes EMT64. Apple nějak v té době taky opustil krásu PowerPC a přešel na x86 od Intelu, ale udělal chybu v tom, že první systémy byly pouze 32bitové a teprve až s modely 2010 a systémy Mac OS X 10.6 a vyššími se začalo tak nějak kutat s 64bitovými verzemi jader. No a co z toho tedy plyne? Že máme na zádech zase nějakou historickou zátěž, která by nebyla ani potřeba, kdyby Apple prostě jenom vyměnil architekturu svých počítačů, nabídl na chvíli zas nějakou translační vrstvu, jakou byla tehdy třeba Rosetta, no a byl by zkrátka klid. Jenže…
Ochota a neochota vývojářů přehodit svoje aplikace na jinou architekturu je jedna věc, to asi šetří pamětí nebo co, ono to totiž zkrátka funguje i tak, ale příchod x86 na Apple znamenal otevření trhu pro zatím velmi omezenou sortu aplikací, které byly doposud pouze ve světě Windows. Můžeme si pod tím představit vlastně jakýkoliv software, ale hlavně třeba taky hry, protože všechno bylo hrozně cool a DirectX a pak existoval vlastně jen Aspyr, co vytvářel nativní porty pro Macy. Intelová architektura všechno změnila možností (nebo spíše konečně smysluplností) spouštět na XNU/Mach systémech s CoreGraphics win32 kód přes WINE. A není snad nutné připomínat, že WINE není emulátor architektury nebo procesoru, ale pouze překládací vrstva volání pro jiná systémová jádra, a tedy vlastně umožňuje jakýsi běh aplikací Windows pod POSIXovými systémy. Ale zkrátka pak nastal boom v různých Cider-portech a Wine-lahvování, až po třeba otevřený PlayForMac wrapper, zkrátka pohoda.
No ale zajímavé na tom všem je samozřejmě to, že 32bitové aplikace potřebují 32bitovou platformu a 64bitové zas 64bitovou. 64bitový procesor se může za určitých okolností přepnout do 32bitového režimu a fungovat jako 32bitový, opačně to fungovat nemůže. Když se spustí 32bitová aplikace pod 64bitovými Windows, naběhne proces WoW64 (Windows on Windows-64) a běží prakticky izolovaně v něm, ne přímo pod hlavním jádrem. V POSIXových voláních pak WINE nabízí dvě binárky, a to wine a pak wine64, které mají podobný efekt. Obě z nich ale závisí na architektuře a bitovosti jádra skutečného operačního systému, které v macOS až do 10.14 podporovalo oba režimy. No a s Catalinou to končí, jádro bude jen 64bitové, a tedy nebude možné spustit jakoukoliv 32bitovou aplikaci, ať už je napsaná pro jakýkoliv systém. To je samozřejmě docela nepříjemné, ale v posledním měsíci nebo kolika udělali vývojáři z CodeWeavers hrozivě zajímavé pokroky, které tohle omezení dost možná pomohou odstranit. A nebo taky ne.
CodeWeavers je obecně vzato nadšenecká firma, co buduje placený software CrossOver, který zahrnuje ve svém nitru otevřená projekt WINE. Hodně spolupracují a přispívají všemu možnému, díky nim se několikrát celý svět i trochu pohnul a teď byli postaveni před zdánlivě nemožný úkol — bude možné pod macOS 10.15 používat win32 aplikace jako doposud? Půjdeme někdy v dohledné době vůbec s na víno s Katarínou? No, co říci, vyhlídky na to rozhodně nebyly nijak růžové, protože takový úkol je zkrátka… ohromný.
Zahození 32 bitů neznamená totiž jen použití konkrétního jádra, spolu se systémem zmizí 32-bitovost všech frameworků a knihoven, které jsou v něm k dispozici. Nemluvě o grafických vrstvách, co se navíc ještě starají o překlad DirectX do OpenGL nebo rovnou do Metalu. Ona ta bitovost jednoduše řečeno označuje nativní šířku pro maximální čísla, co může procesor zpracovávat, v důsledku taky to, kolik paměťového prostoru může ve skutečnosti uadresovat a efektivně využít (32 bitů umožňuje maximálně 4 GB, kdežto s 64 bity to jde natáhnout až na nějakých 256 TB, a to je už znatelný rozdíl). Z pohledu softwaru, programového kódu, jsou jednotlivé instrukce posloupností čísel právě o takové šířce a přestože interpretace 32bitových instrukcí je podobná jako interpretace těch 64bitových, není to zas tak jednoduché. Přestože Catalina do jisté míry stále umožňuje přepínat procesor do 32bitového režimu v jinak 64bitových procesech, je zásadním oříškem nějaký rozumný postup, jak mezi těmito režimy přepínat plynule, aniž by došlo k havárii a hlavně aby byly k dispozici všechny nutné knihovny a frameworky v dosahu adresovatelnosti ukazatelů 32bitového kódu.
Přístup vývojářů CodeWeavers je v tomhle ohledu neskutečně skvělý, neboť než aby předělávali WINE samotné, což by asi kvůli jeho komplexnosti nešlo, nahackovali si speciální Clang určený pro jeho sestavení tak, aby uměl používat jak 32bitové, tak 64bitové ukazatele, ba co víc, uměl mezi nimi zachovat převod oběma směry. Ono totiž není tak hrozné vyrobit z 32bitového čísla číslo 64bitové, ale směrem zpátky se při špatné rozvaze zkrátka polovina usekne a program skončí někde v neplatné paměti. V tomhle ohledu jejich modifikovaný Clang právě takové ukazatele najít umí a dovede pomocí nich vytvořit paměťově-omezený subkód (přesněji spíše něco jako pomocnou subrutinu, která injektuje pomocný výpočet do jiné již běžící subrutiny) pro převod 64b volání do 32b, kterému rozumí jak WINE, tak cílová windowsovská aplikace, ale také i 64bitové jádro OS hostitele — takže kdekoliv win32 aplikace potřebuje nějaké konkrétní volání, odvolá se na takový skrytě-generovaný kousek subkódu, který ale WINE už interně vidí jako 64bitový prostor — a s přepínáním režimů je pro ten okamžik vymalováno.
S tímhle plánováním se skutečně 31. října povedlo sestavit první alfa verzi CrossOver 19, která umožňuje znovu spustit win32 aplikace na macOS 10.15 Catalina. Je otázkou a doufáním, zda svoji snahu přenesou zpět do otevřeného kódu obenécho WINE, protože to by pak byla naprostá pecka a všechno by mohlo fungovat zas jako před deseti lety, tedy krásné UNIXové večery u sklenky vína a 98kový her od 3DO. Jestli tedy půjdeme s Katarínou na víno, je vyloženě v rukou těchto mágů z CodeWeavers, kteří si zaslouží potlesk za něco, co tu vlastně vůbec od začátku nemuselo být.
Pokud se to nepovede, asi hořkou pilulkou bude zkousnutí 64bitové pravdy odkázání se na plnohodnotnou virtualizaci s kompletními 32bitovými Windows. Asi ani to by nebylo v dnešní době tak zlé, výkon je proti dnům původních aplikací někde úplně jinde a pokud něco potřebujeme, stejně to zafunguje. Zajímavým kamenem úrazu bude zase den, kdy se změní celková architektura, ať už jí bude cokoliv — ARM, RISC-V, Pokémon… uvidíme. Protože kdysi na PowerPC snad nikomu win32 aplikace nechyběly.