Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Aplikacje technologii pomocniczych muszą komunikować się przez granice procesów, aby uzyskać informacje o interfejsie użytkownika od serwerów microsoft Active Accessibility i dostawców automatyzacji interfejsu użytkownika firmy Microsoft. W tym temacie opisano główne problemy z komunikacją międzyprocesowymi, które należy wziąć pod uwagę podczas tworzenia aplikacji ułatwień dostępu systemu Windows.
Gdy aplikacje korzystają z interfejsu API automatyzacji systemu Windows, składniki czasu wykonywania usługi Microsoft Active Accessibility i UI Automation automatycznie obsługują wszystkie problemy i złożoność związane z wykonywaniem komunikacji międzyprocesowej (IPC), w tym problemy ze współdziałaniem, gdy jeden proces jest 32-bitowy, a drugi to 64-bitowe. Firma Microsoft rozpoznaje, że czasami aplikacja technologii pomocniczej może wymagać użycia jakiejś formy IPC zamiast interfejsu API automatyzacji systemu Windows do komunikowania się z serwerem microsoft Active Accessibility lub dostawcą automatyzacji interfejsu użytkownika. W tych przypadkach firma Microsoft zaleca używanie komunikatów DCOM lub Windows (tych z wartościami mniejszymi niż WM_USER) w celu komunikowania się z innymi procesami. Podobnie jak interfejs API automatyzacji systemu Windows, komunikaty DCOM i Windows automatycznie obsługują wszystkie problemy z IPC, w tym współdziałanie 32-bitowe do 64-bitowego.
Jeśli komunikaty interfejsu API automatyzacji systemu Windows, modelu DCOM i systemu Windows nie są dostępne, podczas implementowania wybranej metody IPC należy pamiętać o następujących problemach:
- Pamięć współdzielona — w przypadku korzystania z pamięci udostępnionej należy pamiętać, że struktura w procesie 32-bitowym może mieć inny rozmiar i układ niż ta sama struktura w procesie 64-bitowym. Dotyczy to szczególnie struktur zawierających wskaźniki lub uchwyty.
- Obcięcie wskaźnika — mimo że aplikacja 32-bitowa może używać typu danych LONGLONG do przechowywania wartości 64-bitowej, istnieją wystąpienia, w których nie istnieje żaden element interfejsu API systemu Windows, który umożliwi aplikacji 32-bitowej odbieranie 64-bitowej wartości z procesu 64-bitowego lub wysyłania wartości 64-bitowej do procesu 64-bitowego. Na przykład funkcje GetWindowLongPtr i SendMessage obcinają wszystkie wartości wskaźnika, pozostawiając aplikację 32-bitową z bezużyteczną wartością.
- Dojścia — ponieważ uchwyty jądra32 i user32 mają znaczenie tylko 32-bitowe zarówno w procesach 32-bitowych, jak i 64-bitowych, można je przenosić między procesami bez problemu. Jednak niektóre elementy, które system Windows definiuje jako uchwyty, są naprawdę po prostu opakowane wskaźniki (na przykład HTREEITEM). Te "uchwyty" zostaną obcięte, jeśli zostaną przekazane z procesu 64-bitowego do procesu 32-bitowego.
- funkcji WinEvent Hook — aby zarejestrować funkcję haka w kontekście z procesem serwera 32-bitowego, funkcja haka musi znajdować się w 32-bitowej bibliotece DLL. Podobnie, aby zarejestrować funkcję haka w kontekście z 64-bitowym procesem serwera, funkcja haka musi znajdować się w 64-bitowej bibliotece DLL. Jeśli aplikacja technologii pomocniczej próbuje zarejestrować funkcję w kontekście zaczepienia z serwerem, który ma inną głębokość bitową, zdarzenia będą nadal dostarczane do funkcji haka, ale zostaną one dostarczone poza kontekstem. Aby uzyskać więcej informacji, zobacz Funkcje WinEvents i In-Context i Out-of-Context Hook Functions.
Aby uzyskać więcej informacji na temat współdziałania 32-bitowego i 64-bitowego, zobacz Process Interoperability.
Tematy pokrewne
-
omówienie interfejsu API usługi Windows Automation — omówienie