Interopérabilité 32 bits et 64 bits

Les applications de technologie d’assistance doivent communiquer au-delà des limites des processus pour obtenir des informations d’interface utilisateur auprès des serveurs Microsoft Active Accessibility et des fournisseurs microsoft UI Automation. Cette rubrique décrit les problèmes de communication interprocessus main que vous devez garder à l’esprit lors du développement d’applications d’accessibilité Windows.

Lorsque les applications utilisent l’API Windows Automation, les composants Microsoft Active Accessibility et UI Automation runtime gèrent automatiquement tous les problèmes et complexités impliqués dans l’exécution des communications interprocessus (IPC), y compris les problèmes d’interopérabilité impliqués quand un processus est 32 bits et que l’autre est 64 bits. Microsoft reconnaît qu’il peut arriver qu’une application de technologie d’assistance ait besoin d’utiliser une certaine forme d’IPC au lieu de l’API Windows Automation pour communiquer avec un serveur Microsoft Active Accessibility ou un fournisseur UI Automation. À ces occasions, Microsoft vous recommande d’utiliser des messages DCOM ou Windows (ceux dont les valeurs sont inférieures à celles de WM_USER) pour communiquer avec d’autres processus. À l’instar de l’API Windows Automation, les messages DCOM et Windows gèrent automatiquement tous les problèmes IPC pour vous, y compris l’interopérabilité 32 bits à 64 bits.

Lorsque l’API Windows Automation, DCOM et les messages Windows ne sont pas une option, gardez à l’esprit les problèmes suivants lors de l’implémentation de la méthode IPC choisie :

• Mémoire partagée : lorsque vous utilisez la mémoire partagée, n’oubliez pas qu’une structure dans un processus 32 bits peut avoir une taille et une disposition différentes de la même structure dans un processus 64 bits. Cela est particulièrement vrai pour les structures qui contiennent des pointeurs ou des handles.
• Troncation de pointeur : bien qu’une application 32 bits puisse utiliser le type de données LONGLONG pour stocker une valeur 64 bits, il existe des cas où aucun élément API Windows n’existe pour permettre à l’application 32 bits de recevoir une valeur 64 bits d’un processus 64 bits ou d’envoyer une valeur 64 bits à un processus 64 bits. Par exemple, les fonctions GetWindowLongPtr et SendMessage tronquent toutes les valeurs de pointeur, laissant à l’application 32 bits une valeur inutile.
• Handles : étant donné que les handles kernel32 et user32 ne sont significatifs que 32 bits dans les processus 32 bits et 64 bits, ils peuvent être transférés entre les processus sans problème. Toutefois, certains éléments que Windows définit en tant que handles sont simplement des pointeurs encapsulés (par exemple, HTREEITEM). Ces « handles » sont tronqués s’ils sont passés d’un processus 64 bits à un processus 32 bits.
• WinEvent Fonctions de raccordement : pour inscrire une fonction de hook en contexte auprès d’un processus serveur 32 bits, la fonction de hook doit résider dans une DLL 32 bits. De même, pour inscrire une fonction de hook en contexte avec un processus serveur 64 bits, la fonction hook doit résider dans une DLL 64 bits. Si une application de technologie d’assistance tente d’inscrire une fonction de hook en contexte auprès d’un serveur dont la profondeur de bits est différente, les événements sont toujours remis à la fonction de raccordement, mais ils sont remis hors contexte. Pour plus d’informations, consultez WinEvents et In-Context and Out-of-Context Hook Functions.

Pour plus d’informations sur l’interopérabilité 32 bits et 64 bits, consultez Interopérabilité des processus.

Rubriques connexes

Vue d’ensemble de l’API Windows Automation