Nem nyert hangszórót! Ebből is látszik, hogy fogalmad sincs, hogy miről beszélsz! Vagy legalábbis rosszul tudod.
A 2.10.1-et leszedtem, ezután fordítottam a 2.11.4-et. És most épp a firefox-ban írogatom ezt az üzenetet (ja, a firefox is gtk2-t használ). És nem, nem fordítottam újra (legalábbis gtk frissítés előtt volt egy 2.0-ról 2.0.0.3-ra egy firefox-frissítésem is). Ugyanúgy megy most a liferea (szintén gtk-s), gtubeclock, gkrellm, stb.
És most nem a legutolsó verziószám változott, hanem a második, ami azért „nagyobb” változás.

Nem tudom, nem vagyok a gépedben, de tény hogy én anno régebbi gtk2.x-ekkel, de más libekkel is elég sokat szívtam hasonló gondok miatt. Ami nem jelentette azt hogy minden egyes alkalommal megszívtam, volt hogy néha nem változtak a régebbi dolgok csak bővültek a funkciók, de sokszor volt hogy csak a legutolsó szám változása is okozott olyan hibát hogy megváltozott egy függvény paraméterezése és ez egy-két progiban (amik meghívták az adott függvényt) hibát okozott.

Nem, én nem azért mondtam. A legfőbb oka az volt, hogy a win3.1megérkezése a sok-sok memóriakezelési gondot kiváltotta. Hát, éppenhogy nem. A régi dos-os játéknak akkor is ems meg xms kellett, és eztwin3.1 alól nem tudtam futtatni. És igen, volt vagy 3-4 menüm aconfig.sys-ben, hogy mikor mit kell betölteni az adottprogihoz/játékhoz. Tehát nem volt az olyan nagy megváltás. Nekemlegalábbis nem 😉

Addig amíg a DOS mellett futtattad persze sok minden nem változott. De a windowsos programoknak már nem volt ilyen gondjuk, és ahogy szépen a win leváltotta a DOS-t, megszűntek a memóriagondok. Persze végleg még a 9x idejében sem, de az azért már eléggé megtizedelte a DOS-os programokat, különösen az extra memóriaigényű fajtákat.

most hiába linkelnék be „retro” webáruházak cuccait, úgyis azt mondanád, hogy nem hiteles…

Dehogy mondanám. Retró webáruházat általában perlben írtak, az pedig lévén interpreter nemigen függ a többi libtől, sőt ugyanúgy elmegy akár windowson is ha összelövöd alatta az apacsot és a perlt. Valamivel kevésbé retrót írhattak javában vagy PHP-ben is, ezekre nagyjából ugyanez igaz. De ezek nem natív kódok – ha felteszek egy ZX-81 emulátort akkor a 80-as években írt „emberevő” című első programom is szépen fut linuxon…

Éppen ezt mondtam, hogy erre nem voltak képesek… csak egy win95 telepítőre…

Nem nyert. A telepítő is echte win 3.1-es. Ami miatt be tud telepíteni az az hogy a win 3.1-es progi az XP-re az az hogy már a win3.1-en is volt rendszerhívás a programcsoportok és azon belül a programok telepítésére, és ez a rendszrehívás XP-n is működik. Őszintén szólva sajnos nem emlékszem pontosan mit kellett csinálni, de úgy a 90-es évek elején én magam is csináltam win16-os setup programot és ott valami winapi hívogatással lehetett ezt megtenni de hogy pontosan hogy azt már nem tudom.

„(szemben Pl. a legtöbb Borlandos cuccal amik általában előre generálták a kódot, Pl. a Borland C++ 2.0 még DOS-os progi volt, de már tudott windowsos progit generálni, a Borland C++ 4.0 még 16 bites volt, de már tudott 32 bites kódot generálni ha jól emlékszem).”
Már jósok is voltak? :)))

Nem. De a win32 nem a win95-tel kezdődött hanem az NT-vel. A Borland C++ 4.0 a következő platformokat támogatta: windows 3.x is a 16 bit windows application, win32 is a 32 bit  windows NT application, DOS Standard is a 16 bit DOS application, DOS Overlay is a 16 bit dos application that uses overlay. Ez mind a BC++ 4 user’s guide-ból van Copyright 1987, 1993 Borland International…
Mi minden régiség lapul itt a könyvespolcaimon  

Tévecc!
Volt 16 bites dos-os editor, volt 16 bites windows editor… képes volt 16 bites dos és windows programokat létrehozni és volt dosos, win3.1 és win95/98 telepítő hozzá… ezt is tudom, mert volt nekem. Mintha már a 4.5-ös képes lett volna előállítani 32 bites kódot előállítani, de sz 5.x már biztosan… Tudom, mert ekkortájt még programoztam borland c-ben… Most már csak egy object windows nevezetű könyv, meg 1-2 floppy (ha még működik) őrzi az emlékét…

Nekem a 2.0 volt meg, ennek csak DOS-os telepítője volt, de tudott elvben windowsos programot is készíteni (gyakorlatban nekem akkor nem volt windowsom). Volt a 3.x, ebben volt egy DOS-os és talán egy win16-os progi is (nálam csak kiherélt verzió járt egy rövid ideig, abban nem volt windows).

Minden partnernek átadta a ms az infókat… még a hekkerek is többet tudtak mag, mint a szegény borland aki elől eltitkolták… ezt te sem hiszed el…
A win95-öt sem 1-2 percig fejlesztették… és ilyenkor az a szokás, hogy a kooperativ fejlesztőkkel jóelőre (olyan előre, hogy te kis butus felhasználó még az os ötletét sem hallottad) megosztják az infókat, hogy „addigra” legyen meg az eszköz…

Az MS és a Borland akkor még elég keményen konkurrensek voltak. Akkor még nem az volt a M$ jelszava sem hogy fejlesztők, fejlesztők, mivel a DOS után az emberek örültek a win-nek és a vizuálbéziknek mint a majom a farkának. Csak mostanság jellemző az hogy az egyes platformok versenyeznek a fejlesztőkért a jobbnál jobb ingyenes eszközökkel, ez kétségtelen hogy a linux és windows versenyének pozitív hatása.

„Épp az a probléma hogy a 8.0-ás süsü programok nem települnek a 9.1-es start menükbe.”
Nem, nem ezt mondtam!
A 95-ös borland progi települt a 95-ös windowsra…
Tehát még egyszer 9.1-es süsü program települ-e a 9.1-es süsüre?

Nem csak a 95-ös windowsra települt hanem a 2003-mas XP-re is. Meg a win 3.1-re is. Amúgy annyira ez nem nagy mutatvány, egyszerűen annyit kellett megtenni hogy azt az API hivást ami win 3.1-en a program groupokat csinálta meg kellett csinálni win9x-re illetve XP-re is, innentől kezdve ugyanúgy betelepülnek a progik bele ahogy egyébként a linuxos wine-ba is, ugyanis ő is megcsinálja ugyanezt (más kérdés hogy neki ez annyira nem egyszerű, ugyanis disztribenként eltér hogy a menü elemek hova kerülnek, de volt már olyan disztribem ahol a wine-ba települt progi szépen bekerült a KDE start menüjébe is). A gond ott van, és ez az egyik amit hiányolok hogy linuxnál nincs ilyen disztribek és verziók felett átnyúló API a hasonló feladatok végrehajtására (menüpont/csoport a start menüben (minden ablakkezelőre), démon bejegyzése automatikus indításra.

vagy legalábbis én nem találtam ilyet.” Így pontos!

Miért, te meg tudod mondani hogy a 9x milyen logika alapján teszi bele a start menübe a programokat ? Az persze ok hogy a KDE megfelelő könyvtáraiba bekerülnek a kis .desktop fájlok, a gond ott kezdődik hogy hogy kerülnek oda.

Van a KDE-nek és a GNOME-nak is saját menüje, meg egymástól orrba-szájba tudnak importálni. A kisebb ablakkezelők is tudnak importálni a KDE és a GNOME menüjéből. A démon bejegyzése meg nem a program írójának a feladata, hanem a disztribúció készítőjének. De általában nem valami nehéz dolog, illetve csak lustaság kérdése, hogy valaki nem ír egy wrapper scriptcsoportot rá (hmm… ez nem is olyan rossz ötlet).

A KDE és a Gnome nagyjából ugyanazt a .desktop fájlformátumot használják, a kisebb ablakkezelők viszont gyakorlatilag azt amit akarnak, legtöbbször valamilyen init fájlt. Az más kérdés hogy a debian alapú rendszereken van egy program ami ha szépen megkéred a .desktop fájl alapján megcsinálja a menüt (bár azt nem tudom Pl. egy ICEWM vagy egy BlackBox esetén ez működik-e, én többnyire KDE/Gnome alatt ténykedtem. Ugyanez a progi a Mandrake-ben is tevékenykedik, a többi viszont egyedi megoldásokat csinál. A Fedora a FC3-ig gyakorlatilag semmit, a SuSE 9-nél pedig nem tudtam megállapítani hogy milyen logika alapján pakol dolgokat és hová.

A démon akkor válik érdekes kérdéssé ha az adott cucc nincs a disztribhez meg, ugyanakkor kellene. A démon bejegyzése a legtöbb disztribben nem nagy varázslat, csak elég sűrűn változik hogy mit és hogyan kell csinálni. A legdurvább ebben a műfajban szvsz az UHU 1.0 volt ahol nem a szokásos /etc/rc.d játék volt hanem egy sima textfájl.

És ezekhez tényleg nem kellene túl nagy varázslat, max. egy modjuk installresource nevű script ami benn lenne a /usr/sbin alatt minden disztribben és szépen parancssorosan elvégezné ezeket a műveleteket a paramétereknek megfelelően disztribúció-specifikus módon. A gond az hogy az elmúlt 1x év alatt a linux disztribek ennyi standardizálásban nem tudtak megegyezni…