Interopérabilité 32 bits et 64 bits
Les applications technologiques d’assistance doivent communiquer entre les limites de processus pour obtenir des informations sur l’interface utilisateur auprès des serveurs Microsoft Active Accessibility et des fournisseurs Microsoft UI Automation. Cette rubrique décrit les principaux problèmes de communication interprocesseurs 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 d’exécution Microsoft Active Accessibility et UI Automation gèrent automatiquement tous les problèmes et complexités impliqués dans l’exécution de communications interprocesseurs (IPC), y compris les problèmes d’interopérabilité impliqués lorsqu’un processus est de 32 bits et que l’autre est de 64 bits. Microsoft reconnaît qu’il existe des occasions lorsqu’une application technologique d’assistance peut avoir besoin d’utiliser une forme d’IPC au lieu de l’API Windows Automation pour communiquer avec un serveur d’accessibilité Microsoft Active ou un fournisseur UI Automation. À ces occasions, Microsoft vous recommande d’utiliser des messages DCOM ou Windows (dont les valeurs sont inférieures à celles de WM_USER) pour communiquer avec d’autres processus. Comme l’API Windows Automation, les messages DCOM et Windows gèrent automatiquement tous les problèmes IPC pour vous, notamment 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 votre méthode IPC choisie :
- Mémoire partagée : lorsque vous utilisez la mémoire partagée, sachez 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 du pointeur : bien qu’une application 32 bits puisse utiliser le type de données LONGLONG pour stocker une valeur 64 bits, il existe des instances où aucun élément d’API Windows n’existe qui permettrait à l’application 32 bits de recevoir une valeur 64 bits à partir 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 avec 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 comme des 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.
- Fonctions de hook WinEvent : pour inscrire une fonction de hook in-context avec un processus de serveur 32 bits, la fonction de hook doit résider dans une DLL 32 bits. De même, pour inscrire une fonction de hook in-context avec un processus de serveur 64 bits, la fonction de hook doit résider dans une DLL 64 bits. Si une application de technologie d’assistance tente d’inscrire une fonction de hook in-context auprès d’un serveur qui a une profondeur de bits différente, les événements sont toujours remis à la fonction de hook, mais ils sont remis hors contexte. Pour plus d’informations, consultez WinEvents et In-Context et fonctions de raccordement hors contexte.
Pour plus d’informations sur l’interopérabilité 32 bits et 64 bits, consultez l’interopérabilité des processus.
Rubriques connexes