Conversion des applications Delphi 32 bits en Windows 64 bits

De RAD Studio
Aller à : navigation, rechercher

Remonter à Développement d'applications Windows 64 bits


Si vous avez une base de code d'applications Delphi Windows 32 bits à convertir en Windows 64 bits, vous devez

  • Ouvrir votre application 32 bits dans l'EDI, ajouter et activer la plate-forme cible Windows 64 bits, et compiler votre application comme une application Windows 64 bits. (Pour des détails, voir Etapes de la création d'applications multi-périphériques.)
  • Examiner et gérer les problèmes suivants (la plupart de ces problèmes sont associés aux opérations de pointeurs, à la taille de NativeInt et au code assembleur).

Opérations de pointeurs

Vous devez revoir les opérations de pointeurs dans votre base de code.

  • La taille de tous les pointeurs a changé, comme suit :
    • Sur la plate-forme Windows 32 bits, un pointeur prend 4 octets.
    • Sur la plate-forme Windows 64 bits, un pointeur prend 8 octets.
  • Vous ne pouvez pas présumer que :
    SizeOf(Pointer)=SizeOf(Integer/Cardinal/Longint)
  • Si vous incrémentez des pointeurs, n'oubliez pas que le comportement d'un pointeur 64 bits peut être différent de celui d'un pointeur 32 bits. Vous devrez probablement faire des ajustements dans votre code.
    • Correct :
    MyPtr := PByte(P) + 10;
    • Compatibilité descendante :
    MyPtr := PAnsiChar(P) + 10;
    • Incorrect :
    MyPtr := Pointer(Integer(P) + 10);
  • Vous ne pouvez pas présumer que :
    SizeOf(Pointer) == 4
    • Correct :
    Move(FSelection[Index + 1], FSelection[Index], (FSelectionCount - Index - 1) * SizeOf(Pointer));
    • Incorrect :
    Move(FSelection[Index + 1], FSelection[Index], (FSelectionCount - Index - 1) * 4);

Pour de plus amples informations sur l'utilisation de pointeurs dans les applications Windows 64 bits, voir l'article MSDN, Rules for Using Pointers.

Types entiers

  • Sur la plate-forme Windows 64 bits, un entier prend 4 octets.

Modifications de la taille de NativeInt

  • Sur la plate-forme Windows 64 bits, la taille de NativeInt est maintenant de 8 octets.
  • Sur la plate-forme Windows 32 bits, la taille de NativeInt est toujours de 4 octets.


Code assembleur inline

Si votre application contient du code assembleur inline (ASM), vous devez examiner le code ASM et y apporter les modifications suivantes :

  • Le mélange d'instructions assembleur avec du code Pascal n'est pas supporté dans les applications 64 bits. Remplacez les instructions assembleur par du code Pascal ou écrivez les fonctions complètement en assembleur.
  • Le portage du code assembleur de IA-32 à Intel 64 ne peut pas être simplement effectué en copiant le code. Considérez les spécificités des architectures, telles que la taille des pointeurs et l'alignement. Vous pouvez aussi consulter le manuel du processeur à propos des nouvelles instructions. Si vous voulez compiler le même code pour différentes architectures, utilisez des définitions conditionnelles. Voir Utilisation des définitions conditionnelles pour le code multiplate-forme dans "Utilisation du code assembleur inline".

RAD Studio supporte Intel x86 par le biais de SSE4.2 et AMD 3dNow, et pour x64, Intel/AMD par le biais de SSE4.2.

Pour de plus amples informations, voir :

Problèmes Winapi

  • Si vous passez des pointeurs à SendMessage/PostMessage/TControl.Perform, les paramètres wParam et lParam doivent être transtypés en WPARAM/LPARAM et pas en Integer/Longint.
    • Correct :
      SendMessage(hWnd, WM_SETTEXT, 0, LPARAM(@MyCharArray));
    • Incorrect :
      SendMessage(hWnd, WM_SETTEXT, 0, Integer(@MyCharArray));
  • Remplacez SetWindowLong/GetWindowLog par SetWindowLongPtr/GetWindowLongPtr pour GWLP_HINSTANCE, GWLP_ID, GWLP_USERDATA, GWLP_HWNDPARENT et GWLP_WNDPROC car ils renvoient des pointeurs et des handles. Les pointeurs qui sont passés à SetWindowLongPtr doivent être transtypés en LONG_PTR et pas en Integer/Longint.
    • Correct :
      SetWindowLongPtr(hWnd, GWLP_WNDPROC, LONG_PTR(@MyWindowProc));
    • Incorrect :
      SetWindowLong(hWnd, GWL_WNDPROC, Longint(@MyWindowProc));
  • Les pointeurs qui sont assignés au champ TMessage.Result doivent utiliser un transtypage en LRESULT au lieu de Integer/Longint.
    • Correct :
      Message.Result := LRESULT(Self);
    • Incorrect :
      Message.Result := Integer(Self);
  • Tous les enregistrements TWM... pour les gestionnaires de messages Windows doivent utiliser les types Windows corrects pour les champs :
    Msg: UINT; wParam: WPARAM; lParam: LPARAM; Result: LRESULT)

Alignement des champs de données de type enregistrement

Dans les versions antérieures de Delphi, les enregistrements packed étaient utilisés pour garantir l'alignement correct des données lors de l'appel de bibliothèques externes et notamment certaines fonctions externes de l'API Windows qui nécessitent des paramètres record ou struct. Les champs de données inutilisés étaient introduits à des fins de "remplissage" et d'alignement des champs de données nécessaires. L'implémentation du compilateur en cours élimine le besoin d'utiliser les enregistrements packed de cette façon, dans la plupart des cas. La révision de votre code source existant afin d'éliminer les enregistrements packed et le "remplissage" superflus rend le source plus clair et plus facile à maintenir.

Si vous souhaitez que vos fichiers de données existants maintiennent la compatibilité avec les anciennes versions de Delphi, appliquez la directive de compilation {$OLDTYPELAYOUT ON} au code source où l'ancienne organisation des enregistrements est toujours nécessaire.

Autres problèmes mineurs à résoudre

  • La procédure DataEvent de la VCL-RTL est affectée par le changement de taille de NativeInt.
Vous pouvez obtenir une erreur de redéfinition du compilateur sur les méthodes virtuelles (E2170 Impossible de redéfinir une méthode non virtuelle). Dans ce cas, des modifications du code sont nécessaires.
  • Les correctifs de fonctions à l'exécution, comme l'injection d'une instruction de saut inconditionnel pour rediriger une fonction, doivent être réécrits en instructions 64 bits.
  • Fichiers .obj externes 64 bits : si vous prévoyez de lier votre application Windows 64 bits à un fichier .obj externe, n'oubliez pas que vous aurez besoin d'une version 64 bits du fichier .obj pour le lier à une application Windows 64 bits.

Voir aussi

Récupérée de « https://docwiki.embarcadero.com/RADStudio/Sydney/f/index.php?title=Conversion_des_applications_Delphi_32_bits_en_Windows_64_bits&oldid=203743 »