Új hozzászólás Aktív témák

• #41276 urandom0 senior tag hcl #41274

  Új Válasz 2023-02-24 11:16:59 #41276

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  urandom0

  senior tag

  válasz hcl #41274 üzenetére

  Viszont ha http-n megnézed a repószervert, ott van az összes régi verzió.

  Persze, az archive-ban benne van, csak hát azzal mire megyünk.

  Magam részéről még mindig OS szinten néztem; másrészt amennyire tudom, a C egyszerűbb dolog; tehát nem a headerben mondod meg, hogy mi lesz a függőség, hanem attól függ, milyen kódot írsz. Nem csinál meg helyetted semmit.

  CMake-kel biztos megoldható lenne, hogy tetszőleges verziójú GTK headerket húzzon be. De mit kezdesz mondjuk Ubuntu 22.04-en egy 16.04-re fordított GTK programmal? Nézegetheted a terminálban a hibaüzenetet, hogy "cannot find shared library...".

  Visszafele kompatibilitást én mindig úgy tudtam, hogy a régebbi dolgok mennek az újabb OS, HW, stb. verzióval is.

  Igen, ez így van.

  BTW szerintem Androidon sem a SDK régebbi verzióját használja, egyszerűen csak régebbi verzióhoz fordítja, ha azt mondod, hogy az az app menjen 7.x-en.
  Ahogy @lionhearted mondja.

  Hogy most konkrétan Androidnál hogy van megoldva, azt nem tudom. De pl. a WinAPI-nál úgy néz ki, hogy volt pl. a MapVirtualKey függvény, amikor a Windows csak ANSI karakterkészletet tudott kezelni. Aztán bejött az Unicode, és csináltak egy MapVirtualKeyA függvényt az ANSI karakterekhez, és egy MapVirtualKeyW függvényt az Unicode karakterekhez, a MapVirtualKey pedig csak egy makró lett, ami a kettő közül hívta meg valamelyik függvényt, attól függően, hogy definiáltad-e a program elején a #define UNICODE (https://learn.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api). És ez egy teljesen jó megoldás, mert így ha új programot írsz amihez Unicode támogatás kell, azzal is működik, illetve ha új rendszeren fordítod a régi programot, az is működik.

  Ott kezdődik, hogy ilyen szinten nem kéne össze-vissza változnia mindennek.

  De változik, és ez szerintem valahol érthető is. Tegyük fel, valaki 1996-ban kitalálta, hogy legyen egy GtkKiskutya függvény, ami egy kiskutyát rajzol a képernyőre. Te, mint GTK fejlesztő, akarod ezt a függvényt maintainelni 2023-ban? Nyilván nem, mert ha minden őskori szir-szart maintainelni akarunk, akkor a világ összes erőforrása is kevés lenne hozzá. Márpedig maintainelni, javítgatni időnként kell, mert közben volt három architektúraváltás, a régi Gnome1 már sehol sincs, stb.

  Az biztos, hogy valaki szívni fog, a kérdés csak az, hogy ki

• #41275 lionhearted őstag hcl #41274

  Új Válasz 2023-02-24 11:00:52 #41275

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lionhearted

  őstag

  válasz hcl #41274 üzenetére

  Mert más a forráskód kompatibilitás és más a bytekód. JDK-nak meg lehet adni, hogy egy akármilyen verziós (nyilván nem újabbat, mint saját maga) forráskódot fordítson akármelyik általa ismert JVM-re. Ilyen módon a JDK (Java mint nyelv) előre kompatibilis. A JVM pedig visszafelé.

Új hozzászólás Aktív témák