Una razón específica por la que esto puede ser difícil es que los tamaños de los punteros serán diferentes. En lugar de un puntero ocupando 32 bits, un puntero ahora ocuparía 64 bits.
eso es un problema si el software en algún lugar calzadores un puntero en un int a través de un reinterpret_cast en C++ (que puede ocurrir en algún código de nivel muy bajo), y pasó a trabajar debido a que el tamaño de un int y un puntero fuera el mismo tamaño. Básicamente, el código asumió un cierto tamaño para un puntero.
Otra forma en que puede tragarse es si el código está llena de números mágicos como 4 en lugar de sizeof(void*), o en lugar de 0xffffffffINT_MAX o algo similar.
Puede que no haya una versión de 64 bits de un software si depende de una biblioteca o una función que no está disponible en 64 bits. No puede tener una aplicación que sea parte 32 bits y 64 bits. Por ejemplo, en Windows, hay una función llamada SetWindowLong que solo acepta 32 bits de datos, por lo que no es muy útil para los programas de 64 bits si es necesario pasar un puntero a la función. Es por eso que hay una función llamada SetWindowLongPtr que puede manejar hasta 64 bits en programas de 64 bits y 32 bits en programas de 32 bits.
Tenga en cuenta que Internet Explorer se ejecuta en 32 bits de manera predeterminada, incluso en ventanas de 64 bits, porque una gran mayoría de los complementos están disponibles solo en 32 bits. Un gran ejemplo de esto es the Adobe Flash Player, que está disponible solo en 32 bits. Entonces, aparentemente, incluso para una gran compañía como Adobe, la migración a 64 bits puede no ser siempre trivial.
Operaciones de cambio de posición pueden verse afectadas. Por ejemplo, el cambio de bit 0x80000 dejado 10 veces en 32 bits le da 0x0, pero el cambio de bit 0x80000 queda 10 veces en 64 bits, lo que le da 0x200000000.
Dicho todo esto, no hay una razón técnica real por la que es demasiado difícil portar una aplicación a 64-bits si el código fue escrito bien. El mejor de los casos es que una reconfiguración simple del proyecto y una reconstrucción completa es todo lo que se necesita.
El lado cínico de mi parte dice que las empresas usan esto como una forma de implementar la obsolescencia planificada: ¡forzar o alentar a las personas a actualizar o comprar los productos más nuevos!
Debe ser más específico si quiere una buena respuesta. Por ejemplo, es insensato hacer versiones de 64 bits de aplicaciones .NET - configurarlo para compilar como Cualquier CPU o x64. Entonces, obviamente, no estás hablando de aplicaciones .NET, pero ¿de qué estás hablando? :) –
Pregunto en general cuál es el motivo técnico que aparentemente imposibilita el uso de la misma base de código exacta para compilar aplicaciones de 32 bits y de 64 bits. Dado que si fuera solo una recompilación, todas las bibliotecas también estarían disponibles como de 64 bits, etc., y todas las aplicaciones podrían volver a compilarse a 64 bits, es decir. No hay problema. – Tuminoid
"Todo el software de 64 bits que falta no puede ser simplemente porque a la gente le gusta el código con números mágicos?" - podría faltar mucho software de 64 bits porque no es necesario. Alguien por favor corrígeme si me equivoco, pero la regla de oro que he escuchado es que, a menos que esté abordando potencialmente más de 4 GB de memoria, debe compilar como 32 bits. –