Relinker: hoe software leert praten met een ander besturingssysteem
Stel je voor dat een verhuisbedrijf dozen aflevert op basis van een oud adresboek: "Kerkstraat 12" betekent bij hen altijd "derde verdieping, linkerdeur". Verhuist de hele straat naar een nieuwe wijk, dan werkt dat adresboek niet meer — tenzij iemand elke regel herschrijft naar de nieuwe straatnamen en huisnummers. Een relinker is precies zo'n adresboek-herschrijver, maar dan voor software: een programma dat de interne "adressen" waarmee een app naar onderdelen van het besturingssysteem verwijst, aanpast zodat die app ook op een ander systeem de weg blijft vinden.
De term duikt de laatste tijd op rond pogingen om apps van het ene platform op het andere te laten draaien, bijvoorbeeld Android-apps die oorspronkelijk voor een virtual-realitybril zijn gemaakt en die iemand ook op een heel ander apparaat wil gebruiken. Een relinker is daarbij nooit de hele oplossing — het is één tandwiel in een grotere machine die "compatibiliteitslaag" heet — maar wel een cruciaal tandwiel: zonder correcte koppeling naar de juiste systeemfuncties start een overgezette app simpelweg niet op, of crasht hij zodra hij iets probeert te doen dat verder gaat dan een lege startscreen.
Wat is het precies?
Elk programma dat je opstart, bestaat lang niet alleen uit de code die de ontwikkelaar zelf schreef. Een app roept voortdurend kant-en-klare bouwstenen aan van het besturingssysteem: functies om een bestand te openen, geluid af te spelen, een 3D-omgeving te tekenen, enzovoort. Die bouwstenen zitten in aparte bestanden, bibliotheken genoemd (herkenbaar aan extensies als .so op Linux/Android of .dylib op macOS/visionOS).
Wanneer een programma wordt gecompileerd — vertaald van broncode naar machinecode — legt de compiler niet de volledige inhoud van die bibliotheken vast in het uiteindelijke bestand. In plaats daarvan schrijft hij alleen op: "op het moment dat dit programma draait, heb ik functie X nodig uit bibliotheek Y". Het daadwerkelijk aan elkaar knopen van die verwijzingen aan de echte functies gebeurt pas bij het opstarten, door een onderdeel van het besturingssysteem dat de dynamic linker of loader heet.
Een relinker grijpt in dat proces in, of loopt eromheen. Hij neemt de lijst met verwijzingen uit het oorspronkelijke programma en herschrijft die, zodat ze niet meer wijzen naar bibliotheken van het originele systeem (bijvoorbeeld Android's Bionic-C-bibliotheek), maar naar functionerende tegenhangers op het nieuwe systeem — hetzij echte systeembibliotheken van het doelplatform, hetzij nagebouwde vervangbibliotheken die zich hetzelfde gedragen. Soms gebeurt dit door het uitvoerbare bestand zelf aan te passen (statische relinking), soms door op het moment van opstarten de aanvragen live om te leiden (dynamische relinking).
Dit is iets anders dan binaire vertaling, waarbij processorinstructies van de ene naar de andere chiparchitectuur worden omgezet (bijvoorbeeld x86 naar ARM). Relinking speelt zich een niveau hoger af: het gaat niet over losse rekeninstructies, maar over welke systeemfunctie welk stukje code precies aanroept. In veel compatibiliteitsprojecten zijn beide technieken tegelijk nodig, omdat een app zowel een andere processortaal spreekt als andere systeemfuncties verwacht.
Wat wil men ermee bereiken?
Het uiteindelijke doel is steeds hetzelfde: software die voor platform A is gebouwd, laten draaien op platform B, zonder dat de oorspronkelijke ontwikkelaar er ook maar iets voor hoeft aan te passen. Dat klinkt bescheiden, maar heeft grote gevolgen. Ontwikkelaars van games, VR-toepassingen of professionele software brengen hun product vaak maar voor één of twee platformen uit, simpelweg omdat opnieuw programmeren voor elk apparaat tijd en geld kost. Een goed werkende relinker (als onderdeel van een bredere compatibiliteitslaag) haalt die drempel weg voor de gebruiker: die krijgt toegang tot een grotere bibliotheek aan software, zonder op de ontwikkelaar te hoeven wachten.
Voor makers van nieuwe apparaten — zoals een nieuwe VR- of AR-bril — is dit ook strategisch belangrijk. Een gloednieuw platform heeft aanvankelijk weinig eigen apps. Als gebruikers via een compatibiliteitslaag toch bij bestaande Android- of desktopsoftware kunnen, is de drempel om zo'n apparaat te kopen veel lager, ook al is er nog geen grote eigen appwinkel.
Er kleeft wel een blijvende spanning aan: een relinker maakt een app draaibaar, maar garandeert niet dat alles perfect werkt. Functies die het doelplatform niet kent, functies die net iets anders reageren, of prestatieverschillen kunnen blijven bestaan. Relinken is dus zelden een kwestie van "eenmalig fixen en klaar" — het blijft nauwkeurig, foutgevoelig onderhoudswerk, zeker als het oorspronkelijke platform zelf blijft veranderen.
Voorbeelden uit de praktijk
Relinking als techniek is niet nieuw en duikt in verschillende vormen op binnen bekende compatibiliteitsprojecten:
- ReLinker (KeepSafe, sinds 2015) — een opensource Android-bibliotheek die is gemaakt omdat Android's eigen manier om native bibliotheken te laden op sommige toestellen en Android-versies onbetrouwbaar bleek. ReLinker neemt dat laadproces zelf ter hand in plaats van te vertrouwen op de systeemloader, en is een van de meest concrete, publiek gedocumenteerde voorbeelden van "handmatig relinken" in de Android-wereld.
- Wine (sinds 1993, actief onderhouden door onder meer CodeWeavers) — laat Windows-programma's draaien op Linux en macOS door aanroepen naar Windows-bibliotheken (DLL's) te herkoppelen aan eigen, nagebouwde implementaties. Dit is in essentie relinking op grote schaal, al gebruikt het project de term zelf zelden expliciet.
- Darling (opensourceproject, sinds ongeveer 2012) — een minder bekend maar illustratief project dat probeert macOS-programma's op Linux te draaien. Het herschrijft verwijzingen naar Apple's Mach-O-bibliotheken (dylibs) zodat ze verwijzen naar Linux-equivalenten.
- Box86/Box64 (ontwikkelaar ptitSeb, sinds 2021) — gericht op het draaien van x86-software op ARM-Linuxapparaten (zoals de Raspberry Pi). Naast het vertalen van processorinstructies leidt het project ook bibliotheekaanroepen om, een vorm van relinking die nodig is omdat ARM-Linuxsystemen andere systeembibliotheken gebruiken dan x86-Linux.
- Apple Rosetta 2 (2020) — vooral bekend als vertaler van Intel- naar Apple Silicon-instructies, maar moet daarbij ook bibliotheekaanroepen van overgezette programma's laten aansluiten op de Apple Silicon-versies van macOS-systeembibliotheken, wat raakvlakken heeft met relinktechnieken.
Rond het specifieke, actuele voorbeeld van Android-VR-apps die via een compatibiliteitslaag op andere brillen zoals Apple Vision Pro worden geprobeerd, is de publieke documentatie vooralsnog beperkt: het gaat vaak om verspreide, door hobbyisten gedeelde projecten en forumdiscussies in plaats van uitgebreid gedocumenteerde, officiële software. Dat maakt het lastig om daar op dit moment een specifiek, gezaghebbend project bij te noemen — een eerlijke onzekerheid die hoort bij een technisch veld dat nog volop in de experimenteerfase zit.
Hoe ver is de techniek?
Relinking op zichzelf is een volwassen, decennialang beproefde techniek — de basisprincipes van dynamisch linken bestaan al sinds de jaren tachtig en zijn goed begrepen binnen de informatica. Grote, gevestigde projecten als Wine laten zien dat het op grote schaal en betrouwbaar kan werken, mits er genoeg mensuren in onderhoud worden gestoken.
Waar het spannender en onzekerder wordt, is de toepassing op nieuwe, snel veranderende platformen zoals VR- en AR-brillen. Elke nieuwe versie van een besturingssysteem als visionOS of Android kan interne bibliotheken wijzigen, waardoor eerder werkend relink-werk weer stukbreekt. Dat betekent dat dit soort compatibiliteitsprojecten zelden "af" zijn; ze vragen doorlopend onderhoud, vaak door kleine teams of individuele vrijwilligers.
Een ander obstakel is juridisch en praktisch van aard: platformbeheerders zoals Apple en Google staan niet altijd te juichen bij compatibiliteitslagen die hun eigen appwinkel omzeilen, wat de verspreiding en officiële ondersteuning van dit soort tools kan bemoeilijken. Daardoor blijft veel van dit werk in een grijs, informeel circuit van open source en hobbyprojecten, in plaats van als officieel ondersteunde functie.
Wie werken eraan?
Relinktechnieken worden zelden door één centrale partij ontwikkeld, maar zijn typisch het domein van gespecialiseerde bedrijven en open source-gemeenschappen. CodeWeavers (Verenigde Staten) is al decennia de belangrijkste commerciële kracht achter Wine en het daarvan afgeleide CrossOver. KeepSafe (Verenigde Staten) publiceerde ReLinker als onderdeel van zijn eigen Android-apps en stelde het vervolgens open source beschikbaar voor de bredere Android-ontwikkelaarsgemeenschap.
Grote platformbedrijven als Apple en Google ontwikkelen zelf ook varianten van deze technieken, maar dan vooral om hún eigen overstapscenario's te ondersteunen — zoals Apple met Rosetta 2 bij de overgang van Intel- naar Apple Silicon-Macs. Daarnaast draait een substantieel deel van dit werk op individuele open source-ontwikkelaars en kleine gemeenschappen, zoals bij Box86/Box64 en Darling, vaak gefinancierd via donatieplatforms in plaats van bedrijfsbudgetten. Universitaire betrokkenheid is in dit specifieke deelgebied beperkt; het is vooral praktijkgedreven, systeemtechnisch werk dat dichter bij software-engineering dan bij fundamenteel onderzoek staat.