V podstate tam mas toho napisaneho o sw kompatibilite dost, ale nie vo vsetkom suhlasim:
Rozlisujeme binarnu kompatibilitu v userlande a v jadre. Userland su kniznice a aplikacie, v jadre sa to tyka modulov.
Zacneme userlandom. Podotykam, ze presne rovnake principy ako v Linuxe platia aj vo Windows, aj v dalsich systemoch!
Autori aplikacie zvycajne nepisu celu aplikaciu od zakladov, ale pouzivaju uz existujuce funkcie, ktore sa na danej platforme nachadzaju. Tieto funkcie su ulozene vo forme kniznic, ktore mozu byt staticke alebo dynamicke.
Funkcie zo statickych kniznic sa pri linkovani aplikacie skopiruju priamo do spustitelneho suboru aplikacie.
Funkcie z dynamickych kniznic sa pri linkovani neprekopiruju, ale do spustitelneho suboru aplikacie sa umiestni odkaz, ze dana funkcia sa vola 'void foo(int bar)', je umiestnena v subore 'libbar.so.1' (alebo 'bar.dll', alebo 'bar.framework/Versions/1/bar'). Ano, v unix-like systemoch je cislo verzie pouzitej kniznice sucastou nazvu kniznice.
Vyvoj kniznice 'bar' vsak tiez nie je na bode mrazu, inovuje sa aj ta. A tak vyde kniznica 'libbar.so.2' ('bar2.dll', 'bar.framework/Versions/2/bar'), ktora ma stale funkciu foo, ale tentokrat 'void foo(int bar, int bar2)'. Pri kompilacii vsetko prebehne v poriadku, pretoze je tam na to makro, alebo sa jednoducho upravi zdrojak. Samozrejme, povodna binarna aplikacia takuto kniznicu uz nemoze pouzivat, musi mat stale k dispozicii v1. A to je ta 'kompatibilna vrstva', ktora bola vysvetlena na priklade RH 6 vs 7. Stare verzie kniznic boli vypustene zo systemu, pretoze v ramci systemu ich nic nepouziva. Ak ich niekto potrebuje, pretoze ma starsiu binarnu aplikaciu, ktora ich vyzaduje, tak prosim, su na CD a daju sa nainstalovat.
Dalsia vec je prislusny jazyk, ktory sa pouziva. Aby kompiler mohol vediet, ako volat funkcie z externych kniznic, pouzivaju sa volacie konvencie. Pre C je to jednoduche, tam staci vediet nazov funkcie a jej adresu (vo Windows je to zlozitejsie, tam treba vediet este ci je __stdcall, __cdecl, __fastcall apod). Pre C++ je to uz zlozitejsie, napr. kvoli overloadingu funkcii a operatorov (je mozne mat viacero funkcii, ktore maju rovnaky nazov, ale napr. iny pocet argumentov). Preto sa pouziva tzv. 'name mangling', ked sa do nazvu funkcie v C style (s ktorym pocitaju linkery aj formaty spustitelnych suborov) zakoduju typ navratovej hodnoty, typy argumentov, trieda do ktorej patri metoda, apod. Kazdy kompiler to robi svojim sposobom a je to _by design_. (Nie Linuxovej komunity, ale komisie C++).
Rozdiel linuxu voci Windows je v tom, ze sucastou Windows nie su .dll, ktore by exportovali C++ triedy, ale sucastou Linuxu su kniznice, ktore tak robia (napr. cele KDE). Ak vyvojar vo Windows pouziva C++ kniznicu, tak je zvycajne staticka, alebo, co je zriedkavejsie, tak ju umiestni do adresara aplikacie a pouziva ju len tato aplikacia.
Vyssie spomenuty problem s Javou a Mozillou je presne pripad nekompatibility C++ exportov. GCC pri prechode z verzie 2 na verziu 3 pouzili navrh Intelu na C++ ABI, aby sa mohli mixovat C++ kniznice vytvorene rozlicnymi kompilermi. Takze dnes uz je mozne mixovat Intel C++ a GCC3, ale za cenu toho, ze binarne subory skompilovane GCC2 maju smolu.
Riesenie: pokial niekto potrebuje starsie verzie kniznic skompilovane so starsim ABI, tak nech ich pouziva. Linuxu ako systemu je to uplne fuk. Alebo moze poziadat dodavatela, nech mu doda staticky skompilovany binarny subor.
V tvojom clanku zaznela staznost, ze nebudes moct pouzivat binarne programy dajme tomu pre RH9 na svojom RH7 (to uz prechadzame od backward compatiblity k forward compatiblity). To preto, ze sa pouzivaju tie vyssie spomenute nove funkcie. Samozrejme, mozes si skompilovat dany program pre svoj starsi system, ale bude bez tych novsich funkcii. Rozdiel je v pritomnosti tychto funkcii (napr. podpora krb5 alebo LDAP), nie v binarnej kompatibilite. Druha moznost, okrem kompilacie, je nainstalovat novsie verzie prislusnych kniznic. Bohuzial, graf zavislosti dokaze ist pekne hlboko...
Nemysli si ani nachvilu, ze Windows je bez podobnych problemov. Napr. pluginy pre 3dsmax musia byt skompilovane s MSVC6, koniec diskusie (ked chces vediet presne dovody, pozri si podporu Discreet. Je to presne to, co sa vytyka Linuxu. 3dsmax je v C++ a pluginy su vo forme dll).
Rovnako problemy binarnej kompatibiliy (v Linuxe aj inde) sa daju mimimalizovat, ked autori binarnych buildov vedia, co robia. Nemysli si, ze tych, co tvoria binarne balicky, sa netyka problem medzi monitorom a klavesnicou. Castokrat vytvoria binarny subor, ktory ma kazdu blbost nalinkovanu dynamicky, namiesto toho, aby vytvorili vyvazeny mix statickej a dynamickej kompilacie. Dynamicky linkovat dlhodobo stabilne kniznice (glibc, X11, Gnome) ktore su sucastou viacerych releasov distribucii, staticky volatilne kniznice.
Mnoho aplikacii nema problem. Napr. Netscape v3 a v4 boli distribuovane iba ako binarky a funguju dodnes. Mozilla mala problem len prechodom GCC2 na GCC3. Binarne buildy z mozilla.org nikdy nemali problem medzi distribuciami. Binarne buildy OO.o tiez nemaju ziadny problem. Epic vydal Unreal Tournament 2003 (instalacia je na 3. CD) a zda sa, ze binarna kompatibilita im tiez nerobila problemy. Binarna kompatibilita userlandu je problemom len pre toho, kto chce, aby to bol problem a tyka sa rovnako vsetkych systemov.
Teraz k jadru:
Nekompatibilitu maju na svedomi meniace sa struktury, ktore sa pouzivaju ako parametre funkcii pouzivanych modulmi. Nie je za tym ziadna politika, ale cisto inzinierske dovody. Linus chce mat otvorenu moznost dalsieho vyvoja a nechce, aby mu vrieskalo miliony pouzivatelov, ked zmena, ktoru prave urobil, znefunkcnila ich binarne ovladace.
Vsetko ma svoj rub aj lice. Zla stranka tohto pristupu je, ze binarny dowload zo stranok vyrobcu tak skoro nebude a preto to niektorym pouzivatelom stazi zivot. Dobra stranka tohto pristupu je, ze binarny download zo stranok vyrobcu tak skoro nebude a preto niektori vyrobcovia zverejnia zdrojove kody ovladacov a zaclenia ich do jadra. Pre tych, ktori nekupuju hardware impulzivne, tvori zoznam ovladacov jadra vyborny shopping list a mozu sa spolahnut, ze ich hardware tak skoro nebude iba tazitko v zasuvke (vid napr. hw, ktory bol podporovany len vo win98, ale uz nie vo win2k).