>sok 32 biten ragadt gépen pont ilyen 32 bites gányolt, fixre drótozott megoldás fog gondot okozni
Erre azt mondanám, hogy ez legyen azoknak a problémája akik ilyen alkalmazásokat futtatnak. Szerintem sokkal kisebb munka egy alkalmazásban csak az időkezelést megjavítani, mint mindent 64 bitesíteni. És teljesen ésszerű és életszerű. Ráadásul van egy rakás lib, ami nem is kezel időt, azokat miért kell feltétlenül upgradelni.
Teljesen fals érv az, hogy egy lehetséges hibaforrás miatt töröljünk el egy egész architektúrát, amikor pontosan tudjuk, hogy ementáli sajt az egész mindenség PC-n, tele van hibákkal. Pont az a bajunk, hogy "el lehet rontani" az időkezelést, ha valaki akkora retardált, hogy 32 biten tárolja a másodperceket 2025-ben??? Ha valaki retardált, akkor bármilyen platformon bármilyen hibát tud okozni. Sőt, 64 bites architektúrán is beleteheti az időt egy uint32_t-be. Hiszen aki retardált, akármit megcsinálhat. Nehogy már ez legyen az ok.
>A másik meg az erőforrás-hatékonyság.
Sokszor a 32 bites program sokkal hatékonyabb. Azért mert a struct alignment 32 bites, illetve a pointerek fele akkorák. Így a program RAM használata jelentősen kisebb lehet. És ami még fontosabb, hogy a hot adathalmaz esetleg éppen ezért fér bele a cache-be, amiből 64 biten már kilóg. Ott pedig többszörös sebesség visszaesés lehetséges amikor hirtelen kevés lesz a cache.
Két dolog van amivel messzemenően nem értek egyet:
* A 32 bit erőszakos eltüntetése. Nekem sokkal inkább politikai döntésnek látszik, mint ésszerűnek.
* A gcc fordítóban mások az alapértelmezett int típus méretek 64 biten mint 32 biten. Szerintem ez volt az ősbűn. Ha megtartották volna az eredeti méreteket 64 biten is, akkor erőfeszítés nélkül lehetne portolni a programokat. Ha belegondolunk semmi értelme nem volt a típusokat megváltoztatni. Sőt IMHO a Microsoft nem is változtatta meg a saját fordítóival. Ebben szerintem jobb döntést hoztak.