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.

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.

Frissítetted vagy csak melléraktad az újat ? Középső verziószám változáskor általában ez utóbbi történik, azaz lesz egy libgtk-2.10.so ami a 2.10.1-re mutat, és lesz egy libgtk-2.11.so ami a 2.11.4-re. Azaz a 2.10-hez linkelt programjaid továbbra is a 2.10-et használják és köszönik jól vannak. De próbáld csak a 2.11.4-hez linkelt progit 2.11.1-gyel használni vagy fordítva, esetleg nézd meg hogy mi történik ha eltávolítod a 2.10-et és csinálsz egy 2.10-es linket a 2.11-re…

Win3.1 – amíg csak 1 mega ram volt a régebbi gépemben, akkor még swap-ot se engedet létrehozni. Miután került bele 4, és lett xms is, akkor már lehetett swap-ot is létrehozni.

Én 4MB RAM-mal használtam, igazából már a DOS-os időben ennyi RAM volt a gépemben, és persze xms-sel. Azért mindenesetre nem semmi hogy akkortájt 4MB RAM mi mindenre elég volt. És a win még hagyján, Mac-en 4MB RAM-ja a grafikusoknak és a tördelőknek volt és óriási mennyiségnek számított…

Ez persze így igaz. De általában ez azért van mert még 9x alatt is sok érdekeset megtehettél, DOS alatt pedig pláne. Ott anno a fénykorban olyan extenderek voltak amik ugyanúgy a proci nullás gyűrűjében futkároztak mint az NT kernel, ilyen volt Pl. a Mortal Combat által használt Dos4GW verzió. Ennek aztán még 9x alatt sem nagyon volt esélye az oprendszer felügyelete alatt elindulni. Az meg bevett szokásnak számított Pl. hogy valaki közvetlenül piszkálta a merevlemezt a fájlrendszer és hasonló baromságok megkerülésével . Plusz ott voltak a különféle EMS/XMS/hagyományos/HMA memória játékok, a DOS-os progik nagy része a végén már csak úgy futott hogy külön config.sys menüt kellett csinálni majd minden programnak, attól függően hogy milyen memóriát szeretett. Ez volt az egyik ok hogy a win3.1 elterjedt, igaz hogy memóriakezelés szempontjából az sem volt a tökély, de legalább az EMS/XMS/hagyományos memória konfigurálgatásra nem volt szükség (ettől persze az egyéb DOS-os furkóságok, Pl. a 64 kilobyte-os szegmensméret) még maradtak…

Nem. Ez egy echte 16 bites program, win 3.1-re készült. Még olyan szinten sem támogatja a 32 bitet hogy ilyen kódot tudna generálni (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). De a Delphi 1.0 csak és kimondottan 16 bites volt. Amúgy ezt később a Borlandosok úgy oldották meg hogy a Delphi 2.x, 3.x mellé adták az 1.0-t is hogy lehessen 16 bites kódot is fordítani. De a két vonal elég szigorúan ketté volt vágva.

Tehát a mondatod helyesen így hangzik: milyen qurva nagy király ez a cég, hogy a ms-tal együtt fejleszthati 1 évig a fejlesztő eszközét, amely nem képes támogatni azt. Igaz, hogy „öt” perc alatt belenyomtak egy telepítőt, hogy királyul belemenyjen a startmenübe és pöccre induljon. (Nevetséges.)

Egy fejlesztés nem úgy működik hogy kijön a fejlesztőeszköz és nekiesel a programnak és két nap múlva kihozod a végeredményt. Amikor a D1-et elkezdték csinálni akkor szvsz win95 még a láthatáron sem volt. A Borland-M$ együttműködés pedig elég újkeletű, nagyjából a D8 körülre datálható, addig nem annyira szerették egymást – és a Borland meg is verte a M$-t fejlesztőeszközben. Más kérdés hogy a .NET mellett már kevésbé tudnak labdába rúgni.

Akkor szeretném azt hallani tőled, hogy milyen klasszak pl. a 9.1-es süsü programok, hogy betelepülnek a 9.1 k menübe…

Épp az a probléma hogy a 8.0-ás süsü programok nem települnek a 9.1-es start menükbe. Még nagyobb gond hogy speciel pont a süsü 9.x az ahol nem tudtam megállapítani hogy a programok milyen logika mentén kerülnek bele a start menübe, ugyanis magában az rpm csomagban még csak utalás sincs arra hogy hogy a fenébe kellene bekerülniük, vagy legalábbis én nem találtam ilyet. Általában az szokott lenni hogy beraknak egy .desktop fájlt valamilyen alkönyvtárba, estleg az rpm pre/postinstall csinál valamit, de itt nem találtam ilyesmit…

Mellesleg próbáltál már pl. office2003-at windows98-ra telepíteni? (Mert az sem fog menni…)

Itt az irány a lényeg. Az nem akkora gond hogy win98-ra nem tudsz Pl. .NET3-mat telepíteni. Júzer vegyen jobb gépet, jobb oprendszert. De az nagyon kínos ha a win9x-es programot nem tudod XP-n futtatni. Ez a kompatiblitási irány az ami a lényeg a júzernek, hogy a 10 éve használt könyvelőprogramját ne kelljen azért újra cserélni (vagy akár újrafordítani) csak mert az OS-e felett eljárt az idő. Ezért mennek ma is az IBM nagygépek: visszafelé kompatiblisek a régiekkel, így a régi programok szépen elfutkároznak rajta. És ezért fejlesztenek a bankok javára – úgy gondolják hogy ezek a programok mivel platform és OS függetlenek a jövőben is működni fognak, akár linux akár windows, akár más lesz, és nem kell újraforgatni őket csak azért mert linuxról átköltöztek Solarisra.