Delphi XE2 64 bits

Développement des applications multiplates-formes 64 bits pour Windows

Delphi supporte le développement des applications Windows 64 bits sur un système de développement Win32 natif ou sur un système de développement Win64. C++Builder supporte les applications Win32 et Mac OS X, mais pas les applications Win64.

VCL-FMX-RTL supportent le développement des applications Windows 64 bits

Ces trois bibliothèques supportent Win32 et Win64 :

• La bibliothèque FMX (FireMonkey) supporte toutes les plates-formes cible supportées.
• La VCL et la RTL ont été modifiées pour fonctionner avec les applications 64 bits de la même façon qu'elles fonctionnent avec les applications 32 bits. Ainsi, si vous utilisez seulement la VCL et la RTL, vous pouvez utiliser le même code source pour les plates-formes Win64 et Win32.

Si vous utilisez des composants visuels, vous devrez compiler deux applications distinctes et configurer chaque application avec une plate-forme cible différente — une pour Win32 et une autre pour Win64. Vous obtiendrez alors un .EXE pour Win32 et un autre .EXE pour Win64, avec chaque .EXE configuré avec la plate-forme cible appropriée dans le Gestionnaire de projets. Les composants, packages et bibliothèques que vous devez utiliser lors de la conception doivent exister en versions Win32, ainsi qu'en versions 64 bits.

Configuration d'une application multiplate-forme 64 bits dans l'EDI

Pour cibler la plate-forme 64 bits, vous devez ajouter la plate-forme Windows 64 bits au noeud Plates-formes cible du Gestionnaire de projets, puis activer (double-cliquer sur) la plate-forme Windows 64 bits :

Si vous utilisez un système cible Win64 distant pour l'exécution, le débogage et le déploiement de votre application 64 bits (et si votre système de développement est Win32), vous devez créer un profil distant dans l'EDI et l'assigner à votre plate-forme cible.

Si vous utilisez un système de développement Win64, l'utilisation d'un profil distant est facultative et n'est pas requise.

Les applications Windows 64 bits utilisent l'API Windows familier

Si vous avez travaillé avec l'API Windows pour le développement d'applications 32 bits, vous devez être familier avec la plupart des fonctionnalités de l'API Windows qui sont disponibles pour votre développement d'applications 64 bits.

L'exécution, le débogage et le déploiement nécessitent Win64

Le développement d'applications Win64 dans RAD Studio est par définition un développement multiplate-forme, car l'EDI est une application Win32. Ainsi, quand vous exécutez une application ayant la plate-forme cible Windows 64 bits, vous déployez l'application essentiellement sur la plate-forme Win64. Par conséquent, à l'exécution, votre système de développement doit être Windows 64 bits ou être connecté à un système Win64.

Il existe deux scénarios pour l'exécution, le débogage et le déploiement d'une application Windows 64 bits, selon que votre PC de développement s'exécute sous un système d'exploitation 64 bits ou 32 bits.

Utilisation d'un système de développement 64 bits

Si votre PC de développement est une machine 64 bits s'exécutant sous Windows 64 bits, vous pouvez exécuter, déboguer et déployer sur votre PC de développement, exactement comme vous débogueriez une application Windows 32 bits, sans utiliser Platform Assistant et un profil distant. Cependant, l'utilisation de Platform Assistant et d'un profil distant est facultative pour les systèmes de développement Win64, et vous permet d'utiliser le Gestionnaire de déploiement pour déployer votre application.

Utilisation d'un système de développement 32 bits

Afin d'exécuter, de déboguer ou de déployer une application Windows 64 bits en utilisant l'EDI sur un système de développement Win32, vous devez :

• Installer et exécuter Platform Assistant sur le système cible 64 bits.
• Créer un profil distant sur le système de développement Win32 qui décrit le système cible 64 bits.
• Assurer une connexion dynamique à la plate-forme cible Windows 64 bits. Utilisez Tester la connexion sur la page Outils > Options > Profils distants.

Vous pouvez établir la connexion à un PC 64 bits en utilisant un réseau local Ethernet standard ou une Connexion Bureau à distance.

Remarque : Si le pare-feu Windows est activé sur la cible Win64, vous pouvez recevoir un message du pare-feu Windows quand paserver se connecte pour la première fois à la cible Win64. Cliquez sur Autoriser l'accès (et laissez "Réseaux privés" sélectionné sous "Autoriser paserver.exe à communiquer sur ces réseaux").

Débogage d'une application 64 bits

En général, le débogage d'une application Windows 64 bits dans RAD Studio est très similaire au débogage d'une application Windows 32 bits. Il y a quelques différences. Vous verrez ces différences dans certaines des fenêtres CPU, telles que Vue FPU.

Si vous utilisez un système de développement 32 bits, RAD Studio doit déployer une application 64 bits afin de la déboguer. C'est-à-dire que vous devez assurer une connexion dynamique à un système 64 bits à l'exécution. Si vous utilisez un système de développement 64 bits, vous pouvez exécuter et déboguer sur votre système de développement, et vous n'avez pas besoin d'établir la connexion à un système cible distinct.

Déploiement d'une application 64 bits

Si vous utilisez Platform Assistant et un profil distant, vous pouvez utiliser le Gestionnaire de déploiement pour déployer vos applications 64 bits. Si vous utilisez un système de développement 64 bits et voulez utiliser le Gestionnaire de déploiement, vous devez créer un profil distant qui décrit le système cible pour le déploiement.

Considérations pour les applications 64 bits

Les composants, packages et bibliothèques 64 bits nécessitent les versions de conception 32 bits

Si vous créez des composants, packages ou bibliothèques 64 bits, vous devez avoir leurs versions de conception 32 bits si vous voulez utiliser ces composants, packages et bibliothèques dans l'EDI pendant le développement d'une application. Cette exigence existe car l'EDI est un programme Windows 32 bits.

Par exemple, si vous utilisez l'expert Nouveau composant, vous devez commencer en créant une version 32 bits de votre composant. Vous recompilerez par la suite votre composant, en tant que composant Win64, en définissant la plate-forme cible sur Windows 64 bits (dans le Gestionnaire de projets). RAD Studio enregistre les fichiers de sortie (tels que .bpl et .dcp) dans des répertoires spécifiques à la plate-forme, situés dans le répertoire de sortie de votre projet.

Rendre disponibles vos composants au moment de la conception et de l'exécution

Voici les deux façons dont l'EDI décide si un composant est disponible pour Win32/Win64/OSX32. Ici, "disponible" signifie l'apparition sur la palette, et la vérification par l'EDI. L'EDI n'effectue pas de vérification à la compilation autre que la vérification de l'existence de l'unité du composant. Les deux méthodes décrites ici s'appuient sur les données incorporées dans le package d'exécution Win32 (ou de conception et d'exécution) qui implémente les composants. L'EDI ne peut pas charger les packages Win64 et OSX32 dans l'EDI. Ainsi, l'EDI doit se reporter au package Win32 pour obtenir des informations.

Le système de construction de RAD Studio incorpore automatiquement une ressource RC_DATA dans le binaire du package Win32 nommé PLATFORMTARGETS, qui est un masque de bits des constantes pidXXX dans System.Classes.pas et reflète les plates-formes ciblées du projet de package. L'EDI le lit quand le package est chargé et l'utilise pour décider, par exemple, s'il faut désactiver les composants dans la palette quand une plate-forme non supportée est active.

Le ciblage de plusieurs plates-formes avec un package de composant implique un contrat entre le développeur du composant et l'EDI. L'EDI suppose que, si un projet package de composant cible plusieurs plates-formes et que le développeur distribue le package d'exécution Win32 aux clients (et tous les fichiers compilables et liables associés), le développeur distribuera aussi tous les fichiers compilables et liables nécessaires, et les bits d'exécution, pour les autres plates-formes ciblées.

Des composants individuels peuvent utiliser l'attribut de classe ComponentPlatformsAttribute pour redéfinir les données de PLATFORMTARGETS, en utilisant un masque de bits des mêmes constantes dans Classes. Par exemple :

type  [ComponentPlatformsAttribute(pidWin32 or pidWin64)] // not supported on OSX  TMyComponent = class(TComponent)  private  ... end;

L'emploi de cet attribut implique le même contrat que celui décrit à la première puce ci-dessus.

Programmation Windows

*  Les appels API Windows doivent être des versions 64 bits.

   *  Les blocs try sont supportés dans les programmes 64 bits.

   *  Vous ne pouvez pas mélanger du code 32 bits et du code 64 bits dans le même processus.

*  Les DLLs, composants, bibliothèques et packages nécessitent la compilation ou l'installation de versions 32 bits (à la conception) et 64 bits (à l'exécution) distinctes si vous voulez utiliser le Concepteur de fiches.

*  64 bits est nécessaire pour les extensions du système d'exploitation, les extensions noyau.

*  Comme la taille de LRESULT, WPARAM et LPARAM s'étendra à 64 bits, les transtypages inappropriés devront être vérifiés dans les gestionnaires de messages.

Programmation en assembleur

*  La plupart des registres d'une CPU 64 bits sont deux fois plus grands que ceux d'une CPU 32 bits. Toutefois, la taille du registre d'instruction (IR) est la même pour les processeurs 32 bits et 64 bits.

*  Vous pouvez utiliser un assembleur inline pour le code 64 bits avec quelques limitations :

   *  Pas de mélange de code Pascal et de code assembleur dans un bloc.
       Les fonctions doivent être écrites complètement en assembleur ou en Pascal.

   *  Limitez les modifications directes du pointeur de pile (RSP).

*  Utilisez les nouveaux pseudo-ops :

• .SAVENV
• .PUSHNV
• .PARAMS
• .NOFRAME