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

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 -bit de una vez. Sin embargo, sería bueno si ya pudiéramos preparar nuestro código para 64 bits al hacer nuestra traducción unicode. Esto minimizará el impacto en el caso de que finalmente aparezca en la versión 2020. ¿Alguna sugerencia sobre cómo abordar esto sin introducir demasiado desorden si no llega hasta 2020?

Answer 1

En primer lugar, fíjate en los lugares donde interactúas con bibliotecas que no son delphi y llamadas a la API, que 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 archivo ejecutable 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 trabaje con transmisiones, y quiera serializar datos diferentes, con incluye un número entero, causará problemas, ya que el tamaño del número entero cambió y la transmisión no estará sincronizada.

Por lo tanto, en los lugares donde dependa del tamaño de un entero o 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 de forma segura 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 another similar question, pero voy a repetir mi respuesta aquí también, para asegurarse de que mucha gente ve esta información:

En primer lugar, una advertencia: aunque trabajo de Embarcadero. No puedo hablar por mi empleador. Lo que voy a escribir se basa en mi propia opinión de 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.

que decía:

• Hay dos tipos de enteros, NativeInt y NativeUInt, cuyo tamaño se de inmersión entre 32 bits y 64 bits dependiendo de la plataforma. Han estado en durante algunos lanzamientos. Ningún otro tipo entero cambiará el tamaño dependiendo de la bitidez del objetivo.

• asegurarse de que cualquier lugar que se basa en emitir un valor de puntero a un número entero o viceversa está utilizando NativeInt o NativeUInt para el número entero tipo. TComponent.Tag debe ser NativeInt en versiones posteriores de Delphi.

• Sugeriría 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.

• cosas Pointer-como debe atenerse a unas normas similares a los punteros: objeto referencias (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 de cambios en la API de 64 bits debe ser mantener la misma API entre 32 bits y de 64 bits siempre que sea posible, incluso si esto significa que la API de 64 bits no necesariamente toma ventaja de la máquina. Para el ejemplo , TList probablemente solo maneje elementos MaxInt div SizeOf (Pointer) , para mantener Count, indexes, etc. como Integer. Debido a que el tipo entero no flotará (es decir, cambiará el tamaño dependiendo del bitness), no deseamos tener efectos dominantes en el código del cliente: cualquier índice que alteró a través de una variable de tipo entero o for-loop index, se truncaría y podría causar errores sutiles.

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

• relación a esto, es probable que haya mejorado comprobación de errores para operaciones de estrechamiento en la lengua, especialmente la reducción de 64 bits valora ubicaciones a 32 bits. Esto afectaría la usabilidad de asignar el valor de retorno de Longitud a las ubicaciones de tipo Entero si Length(), devolviera Int64.Por otro lado, específicamente para compilar-magic funciones como Length(), puede haber alguna ventaja de la magia tomada, a, p. Ej. cambiar el tipo de devolución en función del contexto. Pero la ventaja no puede ser tomada de manera similar en API no mágicas.

• Las matrices dinámicas probablemente admitirán la indexación de 64 bits. Tenga en cuenta que las matrices 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. Tenemos un tiempo difícil que viene con razones realistas para las personas que desean 4GB + cadenas que realmente son cadenas, y no solo bloques de datos administrados, para los cuales las matrices dinámicas pueden funcionar igual de bien.

• Quizás 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.