有没有一种明确的方式在Windows中沟通两个程序?

时间:2016-03-15 03:22:21

标签: windows io pipe ipc

我的目标如下:

将JSON字符串化(从我的程序)发送到另一个程序(外部程序)并等待字符串响应,也是字符串化的JSON。这不管JSON编程。我使用的代码(两个程序都是c ++程序)是:

void initializePipeCommunication(){

//HANDLE que representa la salida estandar de este programa (DLL). Se conectara con la entrada estandar del otro programa
HANDLE this_write;

//HANDLE que representa la entrada estandar de este programa (DLL).
HANDLE this_read;

//informacion del proceso asociado al programa externo, es necesaria esta variable para cerrar la comunicacion
PROCESS_INFORMATION externalProcessInformation;

//HANDLE que representa la entrada estandar del otro programa.
HANDLE child_input_read;

//HANDLE que representa la salida estandar del otro programa.
HANDLE child_output_write;

STARTUPINFO startup_info;
SECURITY_ATTRIBUTES security_attributes;

// Set the security attributes for the pipe handles created
security_attributes.nLength = sizeof(SECURITY_ATTRIBUTES);
security_attributes.bInheritHandle = TRUE;
security_attributes.lpSecurityDescriptor = NULL;

CreatePipe(&this_read, &child_output_write, &security_attributes, 0);
CreatePipe(&child_input_read, &this_write, &security_attributes, 0);

ZeroMemory(&externalProcessInformation, sizeof(PROCESS_INFORMATION));
ZeroMemory(&startup_info, sizeof(STARTUPINFO));

startup_info.cb = sizeof(STARTUPINFO);
startup_info.hStdInput = child_input_read;
startup_info.hStdOutput = child_output_write;
//startup_info.hStdError = child_output_write;
startup_info.dwFlags |= STARTF_USESTDHANDLES;
startup_info.dwFlags |= STARTF_USESHOWWINDOW;


TCHAR* szCommandLine = loadExecutablePathFromRegistryWide();
lstrcatW(szCommandLine, L" UsePipeMode");

//Creando el programa externo
if (!CreateProcess(NULL, szCommandLine, NULL, NULL,
    TRUE, 0/*CREATE_NEW_CONSOLE*/, NULL, NULL, &startup_info, &externalProcessInformation)){
    DWORD dwStatus = GetLastError();

    if (dwStatus == ERROR_CANCELLED || dwStatus == ERROR_ELEVATION_REQUIRED) {          
        Errors::report(Errors::BAD_EXTERNAL_PROGRAM_PRIVILEGES);
    }
    else if (dwStatus == ERROR_FILE_NOT_FOUND) {
        // The file defined by lpFile was not found and an error message popped up. 
        Errors::report(Errors::BAD_EXTERNAL_PROGRAM_PATH);
    }
    PluginHelper::log("error # ");
    PluginHelper::logn(std::to_string(dwStatus).c_str());
}}

void write(std::string msg){
    unsigned long dwWritten, toWrite = msg.length();
    WriteFile(this_write, msg.c_str(), toWrite, &dwWritten, NULL);
}



std::string read(){
    unsigned long dwRead, dwWritten;
    static char* chBuf = (char*)malloc(266240);
    ReadFile(this_read, chBuf, 266240, &dwRead, NULL);
    chBuf[dwRead] = 0;
    std::string g(chBuf);           
    return (g.substr(0, g.length()));
}

这是使用管道,事实上,双方都是匿名管道。我不关心异步通信。

问题是我发送的字符串大约是266KB,有时来自外部程序的响应带有错误的JSON格式,同样,在外部程序中,字符串化的JSON构造得很好并发送到我的程序(日志确认那)。总而言之,两边的匿名管道是相同的,在外部程序中,发送到我的程序的字符串很好,除此之外,在我的程序中,响应是我期望的另一个(加上不一致的错误,如异常文本连接到没有意义的JSON。)

有人问:

•上述代码是否良好或至少是错误证明?

•是否有输入/输出方式,即cin / cout通信方式,无需硬欺骗? (就像Google Chrome Native Messaging Interface一样)

1 个答案:

答案 0 :(得分:2)

我已经做了20多年的Win32编码并编写了服务器,应用程序,你可以命名。我认为我使用管道的唯一原因是为了方便(但有限的实用程序)端点的ACL,或能够impersonate the client。否则,它只是专有的,并不是非常高效。

至于您报告的损坏,我的猜测是它的截断,因为您假设所有数据都是一次性读取的,这既不是操作系统保证的,也不是可能给定的大小你的数据。我建议修改你的协议,以便始终首先发送一个DWORD dwBytesSent,读取它,然后循环直到你从管道中读取了很多字节。

如果我是你,因为这个数据听起来很大,我可能只是把它写到文件中。您可以使用GetTempFileName()找出写入位置。您可以使用一个简单的前缀来清理孤立文件,例如清理孤立文件。超过一天。然后只是简单(通常至少同样快)的API来读/写数据。

如果您想要更高的性能(和复杂性),可以使用共享内存或套接字。套接字很适合移植,但有一些额外的开销(环回适配器不是超快),你想要关闭Nagling:setsockopt(TCP_NODELAY)。共享内存并不比您用于管道的API更难,但性能更高,但您需要在其中发明协议(例如,第一个DWORD是状态,第二个DWORD是长度,其余是数据)。微软有一个很好的tutorial article