In-Context Hakenfunktionsvorkehrungen

Aus Leistungsgründen registrieren Cliententwickler Kontextbezogene Hookfunktionen. Da diese Hookfunktionen jedoch dem Adressraum des Servers zugeordnet sind, müssen Client- und Serverentwickler Vorkehrungen treffen, um sicherzustellen, dass die Ereignisverarbeitung reibungslos verläuft.

Vorsichtsmaßnahmen für Cliententwickler

Cliententwickler sollten sich der folgenden Probleme bewusst sein:

• Kontextbezogene Hookfunktionen sollten nicht viel Prozessorzeit in Anspruch nehmen, da die Hookfunktion zurückgegeben werden muss, bevor die Serveranwendung fortgesetzt wird.
• Nachdem ein Ereignis ausgelöst wurde, ist es möglich, dass das einem Ereignis zugeordnete Fenster nicht mehr vorhanden ist, wenn die Hookfunktion aufgerufen wird. Clients müssen überprüfen, ob das einem Ereignis zugeordnete Fenster noch vorhanden ist, bevor sie eine andere Aktion im Zusammenhang mit dem Ereignis ausführen. Um sicherzustellen, dass ein Fenster weiterhin vorhanden ist, verwenden Clients die Microsoft Win32 IsWindow-Funktion .
• Wenn die DLL, in der die Hookfunktion definiert ist, mit einer anderen DLL verknüpft ist, müssen Cliententwickler sicherstellen, dass das System die andere DLL lädt. Bei impliziter Verknüpfung (mithilfe von DEF-Dateien und Importen) muss sich die zusätzliche DLL entweder im Windows-Verzeichnis oder in einem der Systemverzeichnisse wie Windows\System, Windows\System32 oder Windows\SysWOW64 befinden. Bei expliziter Verknüpfung (mithilfe von LoadLibrary) muss der vollständige Pfad zum Verzeichnis, in dem sich die zusätzliche DLL befindet, im Aufruf von LoadLibrary angegeben werden.
• Kontextbezogene Hookfunktionen können einen Stapelüberlauf verursachen, wenn die DLL, die die Hookfunktion enthält, in eine 16-Bit-Anwendung geladen wird. Dieses Problem tritt auf, weil 16-Bit-Anwendungen eine feste Stapelgröße verwenden, die nicht groß genug ist, um die Kette von Systemfunktionsaufrufen aufzunehmen, die zu einem Aufruf der Hookfunktion führen.

Vorsichtsmaßnahmen für Serverentwickler

Serverentwickler müssen sich bewusst sein, dass Clientanwendungen möglicherweise Kontextbezogene Hookfunktionen registrieren. Wenn ein Server NotifyWinEvent aufruft, muss er darauf vorbereitet sein, WM_GETOBJECT und andere IAccessible-Methoden zu verarbeiten.

Ungültige Schnittstellenzeiger

Wenn ein Client AccessibleObjectFromEvent innerhalb einer Kontext-Hookfunktion aufruft, verweist der zurückgegebene IAccessible-Schnittstellenzeiger direkt auf Code im Adressraum des Servers. Wenn der Client mithilfe dieses Zeigers eine Schnittstelleneigenschaft aufruft, ist die COM-Bibliothek (Component Object Model) nicht mit dem Marshalling (Packen und Senden von Schnittstellenparametern über Prozessgrenzen hinweg) oder der Entmarshaling (Entpacken von Parametern, die über Prozessgrenzen hinweg gesendet wurden) beteiligt und erkennt nicht, ob ein Objekt zerstört wird.

Wenn der Client eine Schnittstelleneigenschaft für ein objekt aufruft, das zerstört wird, verursacht der ungültige Schnittstellenzeiger einen Allgemeinen Schutzfehler im Adressraum des Servers, es sei denn, der Server erkennt diese Situation.

Zum Schutz vor ungültigen Schnittstellenzeigern erstellen Server Proxyobjekte , die barrierefreie Objekte umschließen und die Lebensdauer barrierefreier Objekte überwachen. Wenn instance ein Client eine IAccessible-Eigenschaft aufruft, um Informationen zu einem Objekt abzurufen, überprüft der Proxy, ob das zugängliche Objekt noch verfügbar ist, und leitet die Clientanforderung an das barrierefreie Objekt weiter. Wenn das barrierefreie Objekt zerstört wird, gibt der Proxy einen Fehler an den Client zurück.