Oder du hast es nicht verstanden.
Es gibt nicht "das" 64 Bit und somit ist ein automatisches Konvertieren garnicht möglich, weil woher soll der Konverter wissen, was "du" willst.
Dass es automatisch von 16 zu 32 zu 64 Bit geht, erreicht man dadurch, dass der Entwickler die "richtigen" Typen verwendet.
Soll etwas auch unter 64 Bit 32 Bei groß
bleiben dann z.B. LongInt
und soll etwas unter 64 Bit mit
wachsen, dann z.B. NativeInt oder LPAREM/WPARAM/LRESULT bei SendMessage use.
An vielen Stellen gibt es Prüfungen, z.B. beim Cast, wo der Compiler dann knallt oder warnt, aber natürlich kann das nicht alle Sonderfälle abfangen, vor allem nicht da, wo es nichts zum Prüfen/Vergleichen gibt.
Was man aber machen kann, den Typen verwenden, welcher nach aktuellem Stand das macht, was man will (jetzt und hofentlich in Zukunft),
und falls man jetzt noch keine Ahnung hat, was in paar Jahren passiert, aber jetzt schon weiß, was man jetzt&später will, dann kann man Prüfungen einbauen.
z.B. war mal Integer der wachsende/compilerabhängige Typ ... schon damals von 16 zu 32 Bit.
Konnte damals aber keiner Ahnen, dass jemand (CPU-Hersteller, andere Compiler-Entwickler und Co.) auf die saudämliche Idee kommt den Typen einzufrieren und stattdessen einen neuen Typen zu erfinden.
Das selbe Problem gab es damals 2009 beim String.
Hätten ALLE dort AnsiChar/AnsiString benutzt, wo es es weiterhin
ANSI bleiben muß,
und dort Char/String, wo es jetzt
Unicode sein darf, dann ......