2

2 つのアプリケーション間に自動化シナリオ (主に MSUIA) があります。ターゲットは 32 ビットで、私のアプリ (自動化するもの) は 64 ビットで、64 ビットの win7 上にあります。共有する必要がある情報の一部には、直接 Win SDK 呼び出し (SendMessage、GetFocus など) を介してアクセスする必要があります。

私の理解では、Win64 と 32 サブシステムは完全に分離されているため、そのような種類の対話はすぐに失敗するはずです (たとえば、64 ビット アプリを介して 32 ビット アプリの一部にアクセスしようとするなど)。奇妙なことに、ほとんどのものは正常に動作するようです。そのため、何らかのマーシャリングが内部的に行われているようです。

ただし、p/invoke 関数を定義する方法に問題があるように見えるいくつかのシナリオに遭遇しました。私は、何かがサイズを変更する可能性があるときはいつでも IntPtr を使用して (また、素晴らしいhttp://www.pinvoke.net/default.aspx/サイトを使用して)、それらを「公式の MS の方法」と宣言しました。 64 ビット (コンパイル スイッチを使用) の場合、DLL の 64 ビット バージョンを使用して 64 ビット用にコンパイルする必要があります。

奇妙なことに、これらの呼び出しを使用して 32 ビット アプリにアクセスすると (たとえば、他のプロセスのメモリから実際に読み取る GetWindowText など)、これらの呼び出しは正常に機能しているように見えます。しかし。後続の MSUIA 呼び出しはランダムに失敗するようです。

64 ビットにコンパイルしているにもかかわらず、p/invoke 呼び出しに対して (誤って) 32 ビット署名を宣言すると、すべて正常に動作します。

私には、これは意味がありません。

最もクリーンな解決策は、おそらくアプリを 32 ビット (またはターゲット アプリと同じ) にコンパイルすることですが、それでも..これについての洞察に感謝します。

4

1 に答える 1

2

64ビットプロセスは64ビットコードのみを実行できます。32ビットプロセスは32ビットコードしか実行できません。これで、オペレーティングシステムカーネルは、32ビットプロセスの場合、カーネルレベルのシステムコールに対して64ビットモードに切り替わります。しかし、それは実際にはオペレーティングシステムのビジネスです。

64ビットプロセスからを呼び出すGetWindowTextと、64ビットを呼び出しますuser32.dll。32ビットプロセスから呼び出す場合は、32ビットを呼び出していますuser32.dll。ターゲットウィンドウが32ビットプロセスであるか64ビットプロセスであるかは関係ありません。重要なのは、実行中のコードのビット数です。

p/invoke署名の32ビットバージョンについて説明している質問のセクションは私にはあまり意味がありません。コードを見ずにこれ以上言うことはできません。

アプリを32ビット用にコンパイルする必要があるかどうか疑問に思います。疑わしい。別のプロセスの自動化を行っています。32ビットプロセスが64ビットプロセスを自動化することは完全に正常であり、その逆も同様です。

混合できないのは、同じプロセス内の異なるビットネスモジュールです。64ビットの実行可能ファイルから32ビットのDLLをロードすることはできません。およびその逆。しかし、あなたはそれをしていません。つまり、32ビットまたは64ビットのいずれかでアプリをコンパイルできます。

さて、32ビットまたは64ビットのプロセスを使用できると言ったので、32ビットをターゲットにすることをお勧めします。その理由は、アプリのバージョンが1つしかないため、デプロイが簡単になるためです。はい、AnyCPUを使用できますが、なぜ面倒なのですか。64ビットプロセスが必要ない場合は、最小公分母に固執する方が簡単です。

于 2012-04-26T20:50:42.367 に答える