在64位和32位(WOW64)应用程序之间使用WOW64安全吗？

Question

有一个很好的所以 Q/A会话讨论了WM_COPYDATA messages 这里的一般用法，并讨论了不同32/64 bitness 这里的应用程序之间是否会起作用。然而，后者似乎集中于可能误用正在传递的“数据指针”。所以，我在这里提出一个新的问题。

我正在努力让两个Windows应用程序相互通信/同步，作为第一轮的方法，我正在使用Windows消息传递来实现这一点。现在看来一切都还好，…但是我使用WM_COPYDATA消息在应用程序之间传递信息。

我的问题：，当这两个应用程序有不同的(32/64)位时，是否保证了的安全性？我使用下面的代码进行了一些测试，在“客户端”和“服务器”之间使用了32对64构建的所有四个可能的组合，所有的测试都按预期工作；但这仅仅是因为我得到了“幸运”的结果(可能是由于未定义的行为)，还是WOW64系统(特别是当服务器为64位，客户端为32)处理所有必要的编组？

如果有人能够确认它的工作，我将非常感谢一个“官方的”链接/参考确认这一点。

共享头文件：

static const WPARAM nmIdFilePath = 0x00001100;

struct nmLockInfoType {
    char filePathID[1024];
    // More elements will be added later!
};
static const nmLockInfoType nmLockInfoDefault = {
    "<<<Uninitialised Image Data Path>>>",
    //...
};
extern nmLockInfoType nmLockInfo; // MUST be provided by each app!
///nmLockInfoType nmLockInfo = nmLockInfoDefault; // Use this code to instatiate it (once, somewhere)!

服务器程序代码(在RegisterWindowMessage(L"HANDSHAKE");消息的处理程序中)：

//...
COPYDATASTRUCT cds;
cds.dwData = nmIdFilePath;           // Pre-defined ID
cds.cbData = sizeof(nmLockInfoType);
cds.lpData = &nmLockInfo;            // Pre-defined structure (see above)
//...
// Send a copy of the "Welcome Pack" data structure to the client app ...
::SendMessage(clientLock, WM_COPYDATA, WPARAM(m_hWnd), LPARAM(&cds)); // "clientLock is the HWND of the client app's MainWnd

客户程序代码：

BOOL MyFrame::OnCopyData(CWnd* pWnd, COPYDATASTRUCT* pCopyDataStruct)
{
    switch (pCopyDataStruct->dwData)
    {
    case nmIdFilePath:
        memcpy(&nmLockInfo, pCopyDataStruct->lpData, pCopyDataStruct->cbData);
        return nmsSucceeded; // This is NON_ZERO so evaluates to TRUE
    // Other cases here ...
    } 
    return CMDIFrameWnd::OnCopyData(pWnd, pCopyDataStruct);
}

当客户端为32位，而服务器为64位时，我特别关注这种情况；在这种情况下，它将向32位应用程序发送64位数据地址(尽管是WOW64应用程序)。内置的“编组”在WOW64情况下处理这个问题吗？

Answer 1

它只有当我们遵循规则，如何使用它是安全的。请参阅以下WM_COPYDATA信息的备注：

要传递的数据，不能包含指针、或、其他引用到接收数据的应用程序无法访问的对象。 在发送此消息时，引用的数据不能是由发送进程的另一个线程更改的。 接收应用程序应考虑数据只读。lParam参数仅在消息处理期间有效。接收应用程序不应该释放lParam引用的内存。如果接收应用程序必须在SendMessage返回后访问数据，则必须将数据复制到本地缓冲区中。

例如，如果我们试图传递数据类型: ULONG_PTR，那么数据副本在从64位应用程序传递到32位应用程序时可能不能很好地工作。因为32位应用程序是32位，64位应用程序是64位.

您可以通过修改下面的代码来测试它：

struct nmLockInfoType {
char filePathID[1024];
ULONG_PTR point64_32;
// More elements will be added later!
};

上面提到的场景应该是安全的，因为您测试的结果是安全的。如果你还在担心的话请告诉我。

此外，下面是一篇关于开发64位应用程序的有用文档，供您参考：

常见的视觉C++ 64位迁移问题