c# - 64 位和 32 位应用程序之间的自动化/WinAPI 调用

Question

我们在 2 个应用程序之间有一个自动化场景(主要是 MSUIA)，目标是 32 位，我的应用程序(自动化应用程序)是 64 位，在 64 位 win7 上。 一些需要共享的信息必须通过 direkt Win SDK 调用(如 SendMessage、GetFocus 等)来访问。

根据我现在的理解，Win64 和 32 子系统是完全独立的，因此任何此类交互都应该立即失败(例如尝试通过 64 位应用程序访问 32 位应用程序的部分内容)。但奇怪的是，大多数东西似乎都能正常工作。所以内部似乎有某种编码/任何东西。

不过，我现在遇到了一些情况，我定义 p/invoke 函数的方式似乎存在问题。我已经将它们声明为“官方 MS 方式”，只要某些内容可能会改变大小(也使用伟大的 http://www.pinvoke.net/default.aspx/ 站点)，就使用 IntPtr，因此，由于我强制我的 .net 应用程序为 64 位(使用编译开关)，因此应该编译它们对于 64 位，使用 64 位版本的 dll。

现在奇怪的是，当使用这些调用访问 32 位应用程序时(例如 GetWindowText 实际上从其他进程的内存中读取)，这些调用似乎工作正常。但。随后的 MSUIA 调用似乎随机失败。

如果我(错误地)为 p/invoke 调用声明了 32 位签名，即使编译为 64 位，一切也运行正常。

对我来说，这毫无意义。

最干净的解决方案可能是将我的应用程序也编译为 32 位(或与目标应用程序相同)，但...如果您对此有任何见解，我将不胜感激。

Answer 1

64位进程只能执行64位代码。 32 位进程只能执行32 位代码。现在，对于 32 位进程，操作系统内核将切换到 64 位模式以进行任何内核级系统调用。但这确实是操作系统的事。

当您从 64 位进程调用 GetWindowText 时，您正在调用 64 位 user32.dll。当您从 32 位进程调用时，您正在调用 32 位 user32.dll。目标窗口是 32 位还是 64 位进程并不重要，重要的是执行代码的位数。

你的问题中讨论 32 位版本的 p/invoke 签名的部分对我来说没有多大意义。如果没有看到任何代码，我真的无法说更多。

您想知道是否需要编译 32 位应用程序。我对此表示怀疑。您正在对不同的流程进行自动化。 32 位进程自动化 64 位进程是完全正常的，反之亦然。

不能在同一进程中混合使用不同位数的模块。您无法从 64 位可执行文件加载 32 位 DLL。反之亦然。但您没有这样做，这意味着您可以编译 32 位或 64 位应用程序。

现在，虽然您可以使用 32 位或 64 位进程，但我建议您以 32 位为目标。原因是它使您的部署更简单，因为您只有一个应用程序版本。是的，您可以使用 AnyCPU，但何苦呢？如果您不需要 64 位进程，那么坚持最低公分母会更简单。