32 ビットと 64 ビットの相互運用性
支援技術アプリケーションは、Microsoft Active Accessibility サーバーと Microsoft UI オートメーション プロバイダーから UI 情報を取得するために、プロセス境界を越えて通信する必要があります。 このトピックでは、Windows アクセシビリティ アプリケーションを開発するときに留意する必要があるプロセス間通信の問題メインについて説明します。
アプリケーションで Windows オートメーション API を使用する場合、Microsoft Active Accessibility および UI オートメーション ランタイム コンポーネントは、プロセス間通信 (IPC) の実行に関連するすべての問題と複雑さを自動的に処理します。これには、1 つのプロセスが 32 ビットで、もう一方が 64 ビットである場合に関係する相互運用性の問題も含まれます。 Microsoft は、支援技術アプリケーションが Microsoft Active Accessibility サーバーまたはUI オートメーション プロバイダーと通信するために、Windows Automation API の代わりに何らかの形式の IPC を使用する必要がある場合があることを認識しています。 このような場合、他のプロセスと通信するには、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 フック関数 — コンテキスト内フック関数を 32 ビット サーバー プロセスに登録するには、フック関数が 32 ビット DLL に存在する必要があります。 同様に、コンテキスト内フック関数を 64 ビット サーバー プロセスに登録するには、フック関数が 64 ビット DLL に存在する必要があります。 支援技術アプリケーションが、ビット深度が異なるサーバーにコンテキスト内フック関数を登録しようとすると、イベントは引き続きフック関数に配信されますが、コンテキスト外に配信されます。 詳細については、「WinEvents」および「 In-Context」および「Out-of-Context Hook Functions」を参照してください。
32 ビットと 64 ビットの相互運用性の詳細については、「 プロセスの相互運用性」を参照してください。
関連トピック