Binary Compatibility #1 - Áttekintés

A szép kis fenti prológus után még annyit bocsátanék előre, hogy a leirtak a személyes véleményemet képezik, amelyet húsz év programozási tapasztalat, tizen-egynéhány operációs rendszer és vagy féltucat processzorarchitektúra megismerése alapján alakítottam ki - ennek ellenére nem kizárt, hogy tévedek, tehát nyugodtan tessék egyet nem érteni, és persze minden egyes megállapításom után odaképzelni, hogy "szerintem".

És akkor most in medias res - a bináris kompatibilitás márpedig jó dolog. Néhány nagyon egyszerű példával illusztrálhatjuk hogy miért: kapásból itt van a processzorok utasításkészlete. A hardveripar legnagyobb és legismertebb cégei évente sokmillió dollárt fordítanak arra, hogy a következő generációs processzorok a belső fejlesztéseik ellenére képesek legyenek futtatni az elődeik - sokszor egészen távoli elődeik - számára készített programokat is. Igen, az hogy a legújabb Core2 Quad futtatni képes egy 8086 számára készített programot is, a bináris kompabilitás ékes példája. Másik példa: az internet - és mellékesen az összes számítógép hálózat. A számítógép hálózatok működését jól definiált bináris protokollok biztosítják. Nem is lehet másként, hiszen ezek hardverközeli dolgok, a hardver pedig csak a bináris, és általában a számokkal leírt dolgokat érti meg. Aztán a következő jó példa a fájlformátumok. Képzeljük el mi lenne, ha egy zlib, vagy másféle tömörítő új változata nem lenne kompatibilis az előző verziójával betömörített állományokkal... Biztosan nem sokan használnák a továbbiakban. Hasonló a helyzet a különféle kép-, video- és zeneformátumokkal, a DVD lemezek, vagy akár a fájlrendszerek formátumaival is. Ezek mind-mind egy-egy bináris kompatibilitási réteget képeznek. Összefoglalva, egy bináris kompatibilitási réteg nem tesz mást mint hardverközeli módon meghatározza, hogy az adatok milyen formában kerülnek tárolásra, vagy átadásra a rendszerek, vagy a rendszerek részei között. Szerintem túlzás nélkül kijelenthetjük - bináris kompatibilitási rétegek nélkül számítástechnika szimplán működésképtelen lenne. Akkora káosz uralkodna, hogy nagyobb rendszereket képtelenség lenne üzemeltetni és ezeket a rendszereket rémálom lenne egymáshoz kapcsolni. A bináris kompatibilitási rétegek olyan támpontokat adnak amire a fejlesztők - és rajtuk keresztül a felhasználók is támaszkodhatnak. Viszonylagos rendet biztosítanak, egy természeténél fogva bonyolult, ezáltal némiképp kaotikus rendszerben.

Természetesen, minden bináris kompatibilitási rétegnek megvan az árnyoldala is: mint minden fixen rögzített pont, nem csak biztonságot ad, mint egy korlát, hogy ne zúgj le a lépcsőn, vagy lépj le a busz elé az iskola (vagy a kocsma) előtt - hanem gátolhat is céljaid elérésében. Adott esetben tehát kerülgetni kell - a rosszul definiált vagy teljesen elavult bináris interfészek jelentős problémát, késéseket és pluszmunkát okozhatnak egy egy új fejlesztés során. Tipikus példája ennek az x86 utasításkészlet amivel az eszmefuttatásunkat kezdtük - kevés korlátoltabb és elavultabb bináris interfészt támogat a globális iparág napjainkban, mégis szükség van rá, mert nélküle a már megírt és széles körben használt szoftverek nagyrészét lehúzhatnánk a vécén. A fentiek alapján könnyű belátni, hogy a bináris interfészek a kód újrafelhasználhatóság terén sokkal jelentősebb tényezőnek számítanak, mint például az OOP nyelvi elemek, amelyet olyannyira szeretnek hangoztatni a témában látszólag járatosak.

Ha már a nyelvi elemeknél tartunk, van mégegy terület, ahol jelentős szerepet kap a bináris kompatibilitás, ez pedig a fordítóprogramok. A magas szinten dolgozó programozók hajlamosak elfeledkezni, mi is történik akkor, mikor lefordítják a programjukat, pedig ha megértenék és a munkájuk egyik szempontjaként fejben tartanák az ekkor zajló folyamatokat, biztosan jobb szoftverek születnének. A fordítóprogramok munkájában két elem kap kulcsszerepet, az egyik az API, a másik az ABI. Az API-t vagyis az Application Programming Interface-t természetesen a programozók használják, a forráskód szintjén, és egy átlagos program jobbára API hivások tömkelegéből áll. A legtöbb széles körben felhasznált felhasznált API-nál törekednek az állandóságra és visszafele kompatibilitásra, illetve fordítva: egy API általában azért terjed el, mert jól megtervezett, állandó és visszafele kompatibilis. Az ABI szerepe nem ilyen látványos, pedig legalább ilyen fontos: az Application Binary Interface, amely a mélyben dolgozik, és azt definiálja a processzor nyelvén, hogy a már lefordított programrészek, függvények, milyen módon hívhatják egymást, melyik paraméterek melyik regiszterben kerülnek átadásra, vagy milyen formában kerülnek például a stackbe. A régebbi architektúrákon, mint amilyen az x86 is, kezdetben nem volt szigorúan definiált ABI. Az assembly programok korában mindenki úgy használta a regisztereket ahogy jól esett, egy központi szabvány hiányában pedig a fordítóprogramok és az operációs rendszerek saját ABI-kat definiáltak maguknak. Vagyis az ABI sokszor változott, és általában minden operációs rendszernek saját ABI-ja van, esetleg egy rendszer többet is használhat a régebbiek közül, attól függően, hogy az adott alrendszert milyen régen tervezték. Más fiatalabb processzorarchitektúrákon azonban ennél jobb a helyzet, hiszen az első fordítóprogramokkal általános célú ABI-t is terveztek és publikáltak, amelyet azóta is használnak a rendszerek és a rá írt fordítóprogramok, és az ezekkel a rendszerekkel dolgozó programozók élvezik az állandó, egységes és kiszámítható szoftverkörnyezet előnyeit. Mindenesetre, valamilyen jól definiált ABI nélkül lehetetlen, vagy rettentő körülményes lenne a moduláris programozás, és nemcsak a dinamikus, de még a statikus függvénykönyvtárak használata is. Legyen bármilyen kaotikus is az éppen fordított kód és a felhasznált API, odalent a lefordított kód mélyén, az ABI szintjén a fordító szép egységes definiált sémákat, binárisan kompatibilis hivásokat fordít belőle.

Összegezzük tehát:
* a bináris kompatibilitás amellett, hogy szükséges, jó is, mert a jól megtervezett bináris interfészek támpontot adnak, és a korábbi bináris modulok újrafelhasználhatósága miatt - bár adott esetben extra munkát jelentenek a kód írásakor - nagyságrenddel több munkát spórolhatnak meg.
* valamennyi hardverarchitektúra és fordítóprogram figyel a bináris kompatibilitásra, hiszen enélkül a rendszerek működésképtelenek lennének
* összességében aki ezekután szándékosan a bináris kompatibilitás ellen dolgozik az szimplán egy retardált hülye, aki tudatlanságból vagy rosszindulatból szopat másokat.

Postsorozatunk következő részeiben megnézzük, hogy is működik a processzor szintjén egy bináris interfész, az egyes operációs rendszerek hogyan viszonyulnak a bináris kompatiblitás kérdéséhez és problémájához, valamint tervezünk egy bináris interfészt is, hogy személtessük milyen szempontokat is kell figyelembe venni egy ilyen interfész tervezésekor, valamint mekkora feladatot jelent egy ilyen interfész karbantartása. Megmutatjuk, hogy sajnos milyen tipikus hibákat szokás elkövetni egy bináris interfész tervezésekor, valamint ez hogyan vezet ahhoz, hogy a bináris interfész karbantartása nehézkes lesz, kompatibilitása pedig rövid időn belül megszűnik és talán érinteni fogjuk azt a roppant érzékeny kérdést is, hogy ezekben az esetekben mennyi minden múlik a programozó hozzáállásán és szakértelmén.

(És ha valakinek van még ötlete, milyen kérdést érintsünk még, miközben körbejárjuk a témát, ne tartsa magában.)