2

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

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

不过，我现在遇到了一些情况，我定义 p/invoke 函数的方式似乎存在问题。我已经宣布它们是“官方的 MS 方式”，只要有东西可能改变大小（也使用很棒的http://www.pinvoke.net/default.aspx/站点），所以我强制我的 .net 应用程序成为64 位（使用编译开关），它们应该使用 64 位版本的 dll 编译为 64 位。

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

如果我（错误地）为 p/invoke 调用声明了 32 位签名，即使编译为 64 位，一切都运行良好。

对我来说，这没有任何意义。

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

4

1 回答 1

2

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

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

您的问题中关于 32 位版本的 p/invoke 签名的部分对我来说没有多大意义。如果没有看到任何代码，我真的不能说更多。

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

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

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

于 2012-04-26T20:50:42.367 回答