32 ビットと 64 ビットの相互運用性
支援技術アプリケーションは、Microsoft Active Accessibility サーバーと Microsoft UI オートメーション プロバイダーから UI 情報を取得するために、プロセス境界を越えて通信する必要があります。 このトピックでは、Windows アクセシビリティ アプリケーションを開発するときに留意する必要があるプロセス間通信の主な問題について説明します。
アプリケーションで Windows Automation API を使用する場合、Microsoft Active Accessibility および UI Automation ランタイム コンポーネントは、プロセス間通信 (IPC) の実行に関連するすべての問題と複雑さを自動的に処理します。これには、1 つのプロセスが 32 ビットで、もう一方が 64 ビットである場合に関係する相互運用性の問題も含まれます。 Microsoft は、支援技術アプリケーションが、Microsoft Active Accessibility サーバーまたは UI オートメーション プロバイダーと通信するために、Windows Automation API の代わりに何らかの形式の IPC を使用する必要がある場合があることを認識しています。 このような場合、Microsoft では、DCOM または Windows メッセージ (WM_USERの値より小さい値を持つメッセージ) を使用して他のプロセスと通信することをお勧めします。 Windows Automation API と同様に、DCOM メッセージと Windows メッセージでは、32 ビットから 64 ビットの相互運用性など、すべての IPC の問題が自動的に処理されます。
Windows Automation API、DCOM、および Windows メッセージがオプションでない場合は、選択した IPC メソッドを実装するときに次の問題に注意してください。
- 共有メモリ - 共有メモリを使用する場合は、32 ビット プロセスの構造体のサイズとレイアウトが 64 ビット プロセスの同じ構造体とは異なる場合があることに注意してください。 これは特に、ポインターまたはハンドルを含む構造体に当てはまります。
- ポインターの切り捨て - 32 ビット アプリケーションでは、LONGLONG データ型を使用して 64 ビット値を格納できますが、32 ビット アプリケーションが 64 ビット プロセスから 64 ビット値を受け取ったり、64 ビット値を 64 ビット プロセスに送信したりする Windows API 要素が存在しない場合があります。 たとえば、GetWindowLongPtr および SendMessage関数は、すべてのポインター値を切り捨て、32 ビット アプリケーションには役に立たない値を残します。
- ハンドル: kernel32 ハンドルと user32 ハンドルは、32 ビット プロセスと 64 ビット プロセスの両方で 32 ビットしか重要ではないので、問題なくプロセス間で転送できます。 ただし、Windows でハンドルとして定義されている項目の中には、実際には単にラップされたポインター (たとえば、HTREEITEM ) があります。 これらの "ハンドル" は、64 ビット プロセスから 32 ビット プロセスに渡されると切り捨てられます。
- WinEvent Hook Functions — コンテキスト内フック関数を 32 ビット サーバー プロセスに登録するには、フック関数が 32 ビット DLL に存在する必要があります。 同様に、コンテキスト内フック関数を 64 ビット サーバー プロセスに登録するには、フック関数が 64 ビット DLL に存在する必要があります。 支援技術アプリケーションが、異なるビット深度を持つサーバーにコンテキスト内フック関数を登録しようとすると、イベントは引き続きフック関数に配信されますが、コンテキスト外に配信されます。 詳細については、「WinEvents および In-Context および Out-of-Context Hook Functions」を参照してください。
32 ビットと 64 ビットの相互運用性の詳細については、「プロセスの相互運用性 を参照してください。
関連トピック