32-Bit- und 64-Bit-Interoperabilität

Hilfstechnologieanwendungen müssen über Prozessgrenzen hinweg kommunizieren, um UI-Informationen von Microsoft Active Accessibility-Servern und Microsoft-Benutzeroberflächenautomatisierungs-Anbietern abzurufen. In diesem Thema werden die wichtigsten Kommunikationsprobleme beschrieben, die Sie beim Entwickeln von Windows-Barrierefreiheitsanwendungen berücksichtigen müssen.

Wenn Anwendungen die Windows-Automatisierungs-API verwenden, behandeln die Laufzeitkomponenten der Microsoft Active Accessibility and UI Automation automatisch alle Probleme und Komplexitäten, die bei der Durchführung der Interprocess-Kommunikation (INTERprocess Communications, IPC) beteiligt sind, einschließlich der Interoperabilitätsprobleme, die bei einem Prozess mit 32-Bits verbunden sind und die andere 64-Bit-Version ist. Microsoft erkennt, dass es Situationen gibt, in denen eine Hilfstechnologieanwendung möglicherweise eine Form von IPC anstelle der Windows-Automatisierungs-API verwenden muss, um mit einem Microsoft Active Accessibility-Server oder einem Benutzeroberflächenautomatisierungs-Anbieter zu kommunizieren. In diesen Fällen empfiehlt Microsoft, DCOM- oder Windows-Nachrichten (werte kleiner als die von WM_USER) für die Kommunikation mit anderen Prozessen zu verwenden. Wie die Windows-Automatisierungs-API behandeln DCOM- und Windows-Nachrichten automatisch alle IPC-Probleme für Sie, einschließlich der 32-Bit-zu-64-Bit-Interoperabilität.

Wenn die Windows-Automatisierungs-API, DCOM und Windows-Nachrichten keine Option sind, sollten Sie bei der Implementierung Ihrer gewählten IPC-Methode die folgenden Probleme berücksichtigen:

• Gemeinsam genutzter Arbeitsspeicher – Beachten Sie, dass eine Struktur in einem 32-Bit-Prozess möglicherweise eine andere Größe und ein anderes Layout aufweist als die gleiche Struktur in einem 64-Bit-Prozess. Dies gilt insbesondere für Strukturen, die Zeiger oder Handles enthalten.
• Zeigerabkürzung – Obwohl eine 32-Bit-Anwendung den datentyp LONGLONG zum Speichern eines 64-Bit-Werts verwenden kann, gibt es Instanzen, in denen kein Windows-API-Element vorhanden ist, das es der 32-Bit-Anwendung ermöglichen würde, einen 64-Bit-Wert aus einem 64-Bit-Prozess zu empfangen oder einen 64-Bit-Wert an einen 64-Bit-Prozess zu senden. Die "GetWindowLongPtr" und "SendMessage"- Funktionen werden beispielsweise alle Zeigerwerte abgeschnitten, sodass die 32-Bit-Anwendung einen nutzlosen Wert aufweist.
• Handles: Da Kernel32- und User32-Handles in 32-Bit- und 64-Bit-Prozessen nur 32-Bit-Daten signifikant sind, können sie ohne Probleme zwischen Prozessen übertragen werden. Einige Elemente, die Windows als Handles definiert, sind jedoch wirklich nur umschlossene Zeiger (z. B. HTREEITEM-). Diese "Handles" werden abgeschnitten, wenn sie von einem 64-Bit-Prozess an einen 32-Bit-Prozess übergeben werden.
• WinEvent- Hook-Funktionen – Um eine Kontext-Hook-Funktion mit einem 32-Bit-Serverprozess zu registrieren, muss sich die Hook-Funktion in einer 32-Bit-DLL befinden. Ebenso muss sich die Hook-Funktion in einer 64-Bit-DLL befinden, um eine Kontext-Hook-Funktion bei einem 64-Bit-Serverprozess zu registrieren. Wenn eine Hilfstechnologieanwendung versucht, eine Kontext-Hook-Funktion mit einem Server zu registrieren, der eine andere Bittiefe aufweist, werden Ereignisse weiterhin an die Hook-Funktion übermittelt, aber sie werden außerhalb des Kontexts übermittelt. Weitere Informationen finden Sie unter WinEvents und In-Context und Out-of-Context Hook Functions.

Weitere Informationen zur 32-Bit- und 64-Bit-Interoperabilität finden Sie unter Prozessinteroperabilität.

Verwandte Themen

Übersicht über die Windows-Automatisierungs-API