32-Bit- und 64-Bit-Interoperabilität
Hilfstechnologieanwendungen müssen über Prozessgrenzen hinweg kommunizieren, um Benutzeroberflächeninformationen von Microsoft Active Accessibility-Servern und Microsoft Benutzeroberflächenautomatisierung-Anbietern abzurufen. In diesem Thema werden die Standard Kommunikationsprobleme beschrieben, die Sie beim Entwickeln von Windows-Barrierefreiheitsanwendungen berücksichtigen müssen.
Wenn Anwendungen die Windows-Automatisierungs-API verwenden, behandeln die Komponenten microsoft Active Accessibility und Benutzeroberflächenautomatisierung Laufzeit automatisch alle Probleme und Komplexitäten, die beim Ausführen der interprozessübergreifenden Kommunikation (IPC) auftreten, einschließlich der Interoperabilitätsprobleme, die auftreten, wenn ein Prozess 32 Bit und der andere 64 Bit 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 Benutzeroberflächenautomatisierung Anbieter zu kommunizieren. In diesen Fällen empfiehlt Microsoft die Verwendung von DCOM- oder Windows-Nachrichten (solche mit werten geringeren Werten als WM_USER), um mit anderen Prozessen zu kommunizieren. Wie die Windows-Automatisierungs-API behandeln DCOM- und Windows-Nachrichten automatisch alle IPC-Probleme für Sie, einschließlich der 32-Bit- bis 64-Bit-Interoperabilität.
Wenn die Windows-Automatisierungs-API, DCOM und Windows-Meldungen keine Option sind, sollten Sie beim Implementieren der ausgewä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 hat als dieselbe 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 LONGLONG-Datentyp verwenden kann, um einen 64-Bit-Wert zu speichern, 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. Beispielsweise kürzen die Funktionen GetWindowLongPtr und SendMessage alle Zeigerwerte ab, sodass die 32-Bit-Anwendung einen nutzlosen Wert erhält.
- Handles: Da kernel32- und user32-Handles in 32-Bit- und 64-Bit-Prozessen nur 32-Bit-Vorgänge von Bedeutung sind, können sie problemlos zwischen Prozessen übertragen werden. Einige Elemente, die Windows als Handles definiert, sind jedoch 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 Hookfunktionen: Um eine kontextbezogene Hookfunktion bei einem 32-Bit-Serverprozess zu registrieren, muss sich die Hookfunktion in einer 32-Bit-DLL befinden. Analog dazu muss sich die Hookfunktion in einer 64-Bit-DLL befinden, um eine kontextbezogene Hookfunktion bei einem 64-Bit-Serverprozess zu registrieren. Wenn eine Hilfstechnologieanwendung versucht, eine kontextbezogene Hookfunktion bei einem Server zu registrieren, der eine andere Bittiefe aufweist, werden weiterhin Ereignisse an die Hookfunktion übermittelt, aber sie werden außerhalb des Kontexts übermittelt. Weitere Informationen finden Sie unter WinEvents und In-Context- und Out-of-Context-Hookfunktionen.
Weitere Informationen zur 32-Bit- und 64-Bit-Interoperabilität finden Sie unter Prozessinteroperabilität.
Zugehörige Themen