studio - Cómo prepararse para 64 bits al migrar a Delphi 2010 y Unicode

precio delphi

Question

Como no se espera compatibilidad de 64 bits en la próxima versión, ya no es una opción esperar la posibilidad de migrar nuestra base de código existente a unicode y 64 bits de una vez. Sin embargo, sería bueno si ya pudiéramos preparar nuestro código para 64 bits al hacer nuestra traducción de Unicode. Esto minimizará el impacto en el caso de que finalmente aparezca en la versión 2020. ¿Alguna sugerencia de cómo abordar esto sin introducir demasiado desorden si no llega hasta 2020?

Answer 1

En primer lugar, observe los lugares donde interactúa con librerías y api-llamadas que no son delphi, pueden diferir. En Win32, las bibliotecas con la llamada a llamadas stdcall se llaman como _SomeFunction @ 4 (@ 4 que indica el tamaño de los parámetros, etc.). En Win64, solo hay una convención de llamadas, y las funciones en un dll ya no están decoradas. Si importa funciones desde archivos dll, puede necesitar ajustarlas.

Tenga en cuenta que, en un exe de 64 bits, no puede cargar un dll de 32 bits, por lo que, si depende de archivos dll de terceros, también debe buscar una versión de esos archivos de 64 bits.

Además, observe los enteros, si depende de su valor máximo, por ejemplo, cuando los deja desbordar y espera el momento en que ocurre, causará problemas si se cambia el tamaño de un entero.

Además, cuando se trabaja con transmisiones y desea serializar datos diferentes, con incluye un número entero, causará problemas, ya que el tamaño del entero cambió y la transmisión no estará sincronizada.

Por lo tanto, en los lugares donde depende del tamaño de un entero o un puntero, tendrá que hacer ajustes. Al serializar los datos sush, debe tener en cuenta también este problema de tamaño, ya que podría causar incompatibilidades de datos entre versiones de 32 y 64 bits.

Además, el compilador FreePascal con el IDE de Lazarus ya admite 64 bits. Este compilador Object Pascal alternativo no es 100% compatible con el dialecto Borland / Codegear / Embarcadero de Pascal, por lo que recompilar con 64 bits podría no ser tan simple, pero podría ayudar a señalar problemas con 64 bits.

Answer 2

La conversión a 64 bits no debería ser muy dolorosa. Comience con ser intencional sobre el tamaño de un entero donde sea importante. No use "entero" en su lugar use Int32 para enteros del tamaño de 32 bits, e Int64 para enteros del tamaño de 64 bits. En la última conversión de bit, la definición de Integer pasó de Int16 a Int32, por lo que puedes jugar con seguridad al especificar la profundidad exacta de bits.

Si tiene un ensamblado en línea, cree un equivalente pascal y cree algunas pruebas de unidad para asegurarse de que funcionen de la misma manera. Realice algunas pruebas de tiempo de ambos y vea si el ensamblaje aún funciona lo suficientemente rápido para mantenerse. Si lo hace, querrá hacer cambios en ambos a medida que los necesite.

Answer 3

Use NativeInt para enteros que pueden contener punteros fundidos.

Answer 4

Hay otra pregunta similar , pero repetiré mi respuesta aquí también para asegurarme de que tanta gente vea esta información:

Primero, un descargo de responsabilidad: aunque trabajo para Embarcadero. No puedo hablar por mi empleador. Lo que voy a escribir se basa en mi propia opinión sobre cómo debería funcionar un hipotético Delphi de 64 bits, pero pueden existir o no opiniones contrapuestas y otras incompatibilidades y eventos previstos o imprevistos que causan decisiones de diseño alternativas.

Eso dijo:

• Hay dos tipos enteros, NativeInt y NativeUInt, cuyo tamaño flotará entre 32 bits y 64 bits según la plataforma. Han estado presentes durante bastantes lanzamientos. Ningún otro tipo entero cambiará de tamaño dependiendo de la bitidez del objetivo.

• Asegúrese de que cualquier lugar que dependa de convertir un valor de puntero a un número entero o viceversa está usando NativeInt o NativeUInt para el tipo de entero. TComponent.Tag debe ser NativeInt en versiones posteriores de Delphi.

• Sugeriría que no use NativeInt o NativeUInt para valores que no sean punteros . Trate de mantener su código semánticamente igual entre 32 bits y 64 bits. Si necesita 32 bits de rango, use Integer; si necesita 64 bits, use Int64. De esta forma, su código debería correr igual en ambas bitnesses. Solo si está transfiriendo desde y hacia un valor de puntero de algún tipo, como una referencia o un THandle, debe usar NativeInt.

• Las cosas parecidas a punteros deberían seguir reglas similares a los punteros: referencias de objeto (obviamente), pero también cosas como HWND, THandle, etc.

• No confíe en los detalles internos de cadenas y matrices dinámicas, como sus datos de encabezado.

• Nuestra política general sobre los cambios de API para 64 bits debería ser mantener la misma API entre 32 bits y 64 bits siempre que sea posible, incluso si eso significa que la API de 64 bits no aprovecha necesariamente la máquina. Por ejemplo, TList probablemente solo maneje elementos MaxInt div SizeOf (Pointer), para mantener Count, indexes, etc. como Integer. Debido a que el tipo Integer no flotará (es decir, cambiará el tamaño dependiendo del bitness), no queremos tener efectos dominantes en el código del cliente: cualquier índice que dispare en redondo a través de una variable de tipo entero o for-loop index, estar truncado y potencialmente causar errores sutiles.

• Cuando las API se extiendan para 64 bits, lo más probable es que se realicen con una función / método / propiedad adicional para acceder a los datos adicionales, y esta API también se admitirá en 32 bits. Por ejemplo, la rutina estándar Length () probablemente devolverá valores de tipo Integer para argumentos de tipo string o dynamic array; si uno quiere tratar arreglos dinámicos muy grandes, también puede haber una rutina LongLength (), cuya implementación en 32 bits es lo mismo que Length (). Length () arrojaría una excepción en 64 bits si se aplica a una matriz dinámica con más de 232 elementos.

• En relación con esto, probablemente habrá una mejor verificación de errores para las operaciones de estrechamiento en el lenguaje, especialmente el estrechamiento de los valores de 64 bits a las ubicaciones de 32 bits. Esto afectaría a la facilidad de uso de asignar el valor de retorno de Longitud a ubicaciones de tipo Entero si Longitud (), devuelto Int64. Por otro lado, específicamente para las funciones mágicas del compilador como Length (), puede haber alguna ventaja de la magia tomada, por ejemplo, cambiar el tipo de devolución en función del contexto. Pero la ventaja no se puede tomar de manera similar en las API que no son mágicas.

• Las matrices dinámicas probablemente admitirán la indexación de 64 bits. Tenga en cuenta que las matrices de Java están limitadas a la indexación de 32 bits, incluso en plataformas de 64 bits.

• Las cadenas probablemente estarán limitadas a la indexación de 32 bits. Nos cuesta mucho encontrar razones realistas para personas que desean cadenas de 4GB + que realmente sean cadenas, y no solo bloques de datos administrados, para los cuales las matrices dinámicas también pueden servir.

• Tal vez un ensamblador incorporado, pero con restricciones, como no poder mezclar libremente con el código Delphi; también hay reglas sobre excepciones y diseño de marco de pila que deben seguirse en x64.