Partager via

In-Context Précautions de la fonction Hook

  • Article

Pour des raisons de performances, les développeurs clients inscrivent des fonctions de hook en contexte. Toutefois, étant donné que ces fonctions de hook sont mappées dans l’espace d’adressage du serveur, les développeurs client et serveur doivent prendre des précautions pour garantir le bon déroulement du traitement des événements.

Précautions pour les développeurs clients

Les développeurs clients doivent être conscients des problèmes suivants :

  • Les fonctions de hook en contexte ne doivent pas utiliser beaucoup de temps de processeur, car la fonction de hook doit retourner avant que l’application serveur continue.
  • Une fois qu’un événement est déclenché, il est possible que la fenêtre associée à un événement n’existe plus au moment où la fonction de hook est appelée. Les clients doivent vérifier que la fenêtre associée à un événement existe toujours avant d’effectuer toute autre action liée à l’événement. Pour s’assurer qu’une fenêtre existe toujours, les clients utilisent la fonction Microsoft Win32 IsWindow .
  • Si la DLL dans laquelle la fonction de hook est définie est liée à une autre DLL, les développeurs clients doivent s’assurer que le système charge l’autre DLL. En cas de liaison implicite (à l’aide de fichiers .def et d’importations), la DLL supplémentaire doit se trouver dans le répertoire Windows ou dans l’un des répertoires système tels que Windows\System, Windows\System32 ou Windows\SysWOW64. En cas de liaison explicite (à l’aide de LoadLibrary), le chemin d’accès complet au répertoire dans lequel réside la DLL supplémentaire doit être spécifié dans l’appel à LoadLibrary.
  • Les fonctions de hook en contexte peuvent provoquer un dépassement de capacité de pile lorsque la DLL qui contient la fonction de hook est chargée dans une application 16 bits. Ce problème se produit parce que les applications 16 bits utilisent une taille de pile fixe qui n’est pas assez grande pour prendre en charge la chaîne d’appels de fonction système qui entraînent un appel à la fonction hook.

Précautions pour les développeurs de serveurs

Les développeurs de serveurs doivent savoir que les applications clientes peuvent inscrire des fonctions de hook en contexte. Lorsqu’un serveur appelle NotifyWinEvent, il doit être prêt à gérer WM_GETOBJECT et d’autres méthodes IAccessible .

Pointeurs d’interface non valides

Lorsqu’un client appelle AccessibleObjectFromEvent dans une fonction de hook en contexte, le pointeur d’interface IAccessible retourné pointe directement vers le code dans l’espace d’adressage du serveur. Si le client appelle une propriété d’interface à l’aide de ce pointeur, la bibliothèque COM (Component Object Model) n’est pas impliquée dans le marshaling (empaquetage et envoi de paramètres d’interface au-delà des limites du processus) ou le démarshalage (décompression des paramètres qui ont été envoyés au-delà des limites du processus) et ne détecte pas si un objet est détruit.

Si le client appelle une propriété d’interface à un objet qui est détruit, le pointeur d’interface non valide provoque une erreur De protection générale dans l’espace d’adressage du serveur, sauf si le serveur détecte cette situation.

Pour vous protéger contre les pointeurs d’interface non valides, les serveurs créent des objets proxy qui encapsulent des objets accessibles et surveillent la durée de vie des objets accessibles. Par instance, lorsqu’un client appelle une propriété IAccessible pour obtenir des informations sur un objet, le proxy vérifie si l’objet accessible est toujours disponible et, le cas échéant, transfère la demande du client à l’objet accessible. Si l’objet accessible est détruit, le proxy retourne une erreur au client.