> ze ked ma kompilator kompilovat rovnako pre 32bit i 64bitovy system, tak je nepripustne, aby nim nepreslo dake pretypovanie pointeru
Cože? Rozumíš vůbec tomu co říkáš? Víš o tom, že velikost pointeru (= ukazatel, adresa) je ve 32bit a 64bit režimu jiná? Ve 32bit to je 4B, v 64bit 8B. Proto jim samozřejmě přetypování na nějaký datový typ s menší velikostí (např int i long jsou na windows v 32bit i 64bit režimu 4B) projít nemůže. Adresa by se "ořízla" a pak by program při použití takového ukazatele "chcípnul" na SIGSEGV, protože by chtěl přistoupit do paměti na adresu, která mu nepatří. Pointer lze přetypovat pouze na typ se stejnou (size_t, ptrdiff_t) nebo větší velikostí (takový typ daný standardem není, pouze C99 určuje, že "long long" je nejméně 8B, takže tam by se to vešlo, ale zase to třeba nebude chodit s další generací (128bit)). Samozřejmě je nejlepší pointer vůbec nepřetypovávat. Dělat to je prasárna a ve většině případů zbytečná.
WindowsAPI je jasně dané, je k němu slušná dokumentace a pokud se používá, jak se používat má, tak programátor nemůže nikdy narazit na problém spojený s přechodem z 32bit na 64bit.
64bit aplikace jsou, jen jich není dostatek. A né vynou windows, ale programátorů, kteří, jak si uvedl, si řeknou, že to funguje v jakési 32bit emulaci tak na to s*rem. Ale pak samozřejmě aplikace nemůže využít plného potenciálu platformy - 64bit není jen o více paměti, ale v 64bit režimu máte 2x tolik registrů, víc instrukcí a to může vést (a často i vede) k vyššímu výkonu aplikace.
Na Linuxu x86_64 je třeba long 8B, tak tam nějaké to přetypování ukazatele na long projít může, ale rozhodně to není správně napsaný program, protože standard pouze uvádí sizeof(short) = 8B a proto NELZE spoléhat na to, že se do nějakého "obyč" typu vejde ukazatel.