在 Windows 中是否有一种明确的方式来通信两个程序？

Question

My goal is just the following:

Send a JSON stringified (from my program) to another program (external program) and wait for a string response, also a JSON stringified. This is no matter of JSON programming. The code (both program really are c++ programs) that I use is:

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()));
}

That is using pipes, in fact, anonymous pipes in both sides. I don´t care about asynchronous communication.

The problem is that the string I send is around 266KB and sometimes the response from the external program came with a bad JSON format, again, in the external program the stringified JSON is well constructed and sent to my program (the logs confirm that). Summarizing, the anonymous pipes in both sides are the same, and in the external program the string emitted to my program is well, besides that, in my program the response is another that I expect (plus inconsistent errors, like exceptions text concatenated to the JSON with no sense).

Some ask:

• Is well or at least error proof the above code?

• Is there an Input/output way, ie cin/cout way of communication without the need of hard tricking? (Like Google Chrome Native Messaging Interface does)

Answer 1

I've been doing Win32 coding for 20+ years and written servers, apps, you name it. I think the only reason I'd use pipes is for easy (but limited utility) ACL'ing of the endpoint, or to be able to impersonate the client . Otherwise, it's just proprietary and not terribly performant.

As for the corruption you report, my guess would be it's truncation because you're assuming that all the data is read at once, which is neither guaranteed by the OS nor even likely given the size of your data. I'd suggest modifying your protocol to always send a DWORD dwBytesSent first, read that, then loop until you've read that many bytes off the pipe.

If I were you, since this data sounds like it gets large, I'd probably just write it to a file. You can use GetTempFileName() to figure out where to write it. You can have a simple prefix unique to your application to cleanup orphan files, eg more than a day old. And then just simple (and generally at least as fast) APIs to read/write data.

IF you want more performance (and complexity) you can do shared memory or sockets. Sockets are nice for portability, but have some extra overhead (loopback adapter isn't super fast) and you'll want to turn off Nagling: setsockopt(TCP_NODELAY) . Shared memory is no harder than the APIs you're using for pipes, but is more performant, but you'll need to invent a protocol within it (eg first DWORD is status, second DWORD is length, rest is data). Microsoft has a nice tutorial article .