Vorsichtsmaßnahmen für In-Context Hookfunktion
Aus Leistungsgründen registrieren Cliententwickler Kontexthookfunktionen. Da diese Hookfunktionen jedoch dem Adressraum des Servers zugeordnet sind, müssen Client- und Serverentwickler Vorsichtsmaßnahmen ergreifen, um sicherzustellen, dass die Ereignisverarbeitung reibungslos verläuft.
Vorsichtsmaßnahmen für Cliententwickler
Cliententwickler sollten sich der folgenden Probleme bewusst sein:
- Hookfunktionen im Kontext sollten nicht viel Prozessorzeit verwenden, da die Hookfunktion zurückgeben muss, bevor die Serveranwendung fortgesetzt wird.
- Nachdem ein Ereignis ausgelöst wurde, ist es möglich, dass das einem Ereignis zugeordnete Fenster zum Zeitpunkt des Aufrufs der Hookfunktion nicht mehr vorhanden ist. Clients müssen überprüfen, ob das einem Ereignis zugeordnete Fenster noch vorhanden ist, bevor sie eine andere Aktion im Zusammenhang mit dem Ereignis ergreifen. Um sicherzustellen, dass ein Fenster noch 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 (mit DEF-Dateien und Importen) muss sich die zusätzliche DLL entweder im Windows Verzeichnis oder in einem der Systemverzeichnisse befinden, z. B. Windows \ System, Windows \ System32 oder Windows \ SysWOW64. Bei expliziter Verknüpfung (mit LoadLibrary)muss der vollständige Pfad zu dem Verzeichnis, in dem sich die zusätzliche DLL befindet, im Aufruf von LoadLibrary angegeben werden.
- Hookfunktionen im Kontext 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 beachten, dass Clientanwendungen möglicherweise Kontexthookfunktionen registrieren. Wenn ein Server NotifyWinEventaufruft, muss er darauf vorbereitet sein, WM _ GETOBJECT und andere IAccessible-Methoden zu verarbeiten.
Ungültige Schnittstellenzeiger
Wenn ein Client AccessibleObjectFromEvent innerhalb einer Kontexthookfunktion aufruft, zeigt der IAccessible-Schnittstellenzeiger, der zurückgegeben wird, direkt auf Code im Adressraum des Servers. Wenn der Client eine Schnittstelleneigenschaft mit diesem Zeiger aufruft, ist die Component Object Model -Bibliothek (COM) nicht mit dem Marshalling (Packen und Senden von Schnittstellenparametern über Prozessgrenzen) oder dem 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 General Protection-Fehler 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 beispielsweise ein Client eine IAccessible-Eigenschaft aufruft, um Informationen zu einem Objekt abzurufen, überprüft der Proxy, ob das barrierefreie Objekt noch verfügbar ist, und leitet in diesem Fall die Anforderung des Clients an das barrierefreie Objekt weiter. Wenn das barrierefreie Objekt zerstört wird, gibt der Proxy einen Fehler an den Client zurück.