Choosing an IPC mechanism
-
I have a console application with no MFC support (I cannot add MFC support due to several reasons). This console executes another process and the new process does a very lengthy operation (I cannot use a thread within the console to do the lengthy operation, as is performed by a third party library that the app links to, which cannot work in console mode). The console app must be notified of the progress of this lengthy operation periodically. Now, when I thought of how to notify the console, I cannot do a
PostMessage(there's no window handle), I cannot do aPostThreadMessage(the primary thread does not have a message queue). Therefore, I am considering the following options: 1. Use a named pipe. The console creates the pipe and usesCreateProcessto spawn the other executable, passing the pipe handle while spawning it. The executable write into the pipe and the console reads. 2. Use Overlapped IO 3. Any other suggestions (No, code injection orCreateRemoteThreadis not an option that I will consider). I have the source code of both the applications, but I don't want to do a lot of changes in the console app (thousands of lines, OLD stuff, no docs). However, I'm open to be convinced to do that as well. Thank you!It is a crappy thing, but it's life -^ Carlo Pallini
-
I have a console application with no MFC support (I cannot add MFC support due to several reasons). This console executes another process and the new process does a very lengthy operation (I cannot use a thread within the console to do the lengthy operation, as is performed by a third party library that the app links to, which cannot work in console mode). The console app must be notified of the progress of this lengthy operation periodically. Now, when I thought of how to notify the console, I cannot do a
PostMessage(there's no window handle), I cannot do aPostThreadMessage(the primary thread does not have a message queue). Therefore, I am considering the following options: 1. Use a named pipe. The console creates the pipe and usesCreateProcessto spawn the other executable, passing the pipe handle while spawning it. The executable write into the pipe and the console reads. 2. Use Overlapped IO 3. Any other suggestions (No, code injection orCreateRemoteThreadis not an option that I will consider). I have the source code of both the applications, but I don't want to do a lot of changes in the console app (thousands of lines, OLD stuff, no docs). However, I'm open to be convinced to do that as well. Thank you!It is a crappy thing, but it's life -^ Carlo Pallini
Socket communication may become good option for you
Parag Patel Sr. Software Eng, Varaha Systems
-
Socket communication may become good option for you
Parag Patel Sr. Software Eng, Varaha Systems
It looked like a bad option for me, because I will then need to link to the winsock libraries, will have the overhead of sockets, and will need to ensure that the machine will have a loopback adapter. On the contrary, a locally named pipe will execute in kernel mode, the OS has built-in support for it (no additional libraries). So, I had excluded sockets. :) Thank you!
It is a crappy thing, but it's life -^ Carlo Pallini
-
I have a console application with no MFC support (I cannot add MFC support due to several reasons). This console executes another process and the new process does a very lengthy operation (I cannot use a thread within the console to do the lengthy operation, as is performed by a third party library that the app links to, which cannot work in console mode). The console app must be notified of the progress of this lengthy operation periodically. Now, when I thought of how to notify the console, I cannot do a
PostMessage(there's no window handle), I cannot do aPostThreadMessage(the primary thread does not have a message queue). Therefore, I am considering the following options: 1. Use a named pipe. The console creates the pipe and usesCreateProcessto spawn the other executable, passing the pipe handle while spawning it. The executable write into the pipe and the console reads. 2. Use Overlapped IO 3. Any other suggestions (No, code injection orCreateRemoteThreadis not an option that I will consider). I have the source code of both the applications, but I don't want to do a lot of changes in the console app (thousands of lines, OLD stuff, no docs). However, I'm open to be convinced to do that as well. Thank you!It is a crappy thing, but it's life -^ Carlo Pallini
-
Thanks Stuart, that looks interesting. Now, I'll choose one between Named Pipes and mailslots. :)
It is a crappy thing, but it's life -^ Carlo Pallini
-
I have a console application with no MFC support (I cannot add MFC support due to several reasons). This console executes another process and the new process does a very lengthy operation (I cannot use a thread within the console to do the lengthy operation, as is performed by a third party library that the app links to, which cannot work in console mode). The console app must be notified of the progress of this lengthy operation periodically. Now, when I thought of how to notify the console, I cannot do a
PostMessage(there's no window handle), I cannot do aPostThreadMessage(the primary thread does not have a message queue). Therefore, I am considering the following options: 1. Use a named pipe. The console creates the pipe and usesCreateProcessto spawn the other executable, passing the pipe handle while spawning it. The executable write into the pipe and the console reads. 2. Use Overlapped IO 3. Any other suggestions (No, code injection orCreateRemoteThreadis not an option that I will consider). I have the source code of both the applications, but I don't want to do a lot of changes in the console app (thousands of lines, OLD stuff, no docs). However, I'm open to be convinced to do that as well. Thank you!It is a crappy thing, but it's life -^ Carlo Pallini
Rajesh R Subramanian wrote:
The console app must be notified of the progress of this lengthy operation periodically.
Mailslots, sockets and named pipes.... all for a simple integer percentage value? SendMessage returns a value in its LRESULT which can be used in the console application to retrieve small values such as percentage complete. Something like this:
#include "stdafx.h" #include <stdio.h> #include <string.h> #include <conio.h> #include <windows.h> #include <Psapi.h> #pragma comment(lib, "psapi") #define WM_PERCENTAGE WM_USER + 1033 BOOL CALLBACK GetPercentageProc(HWND hWnd, LPARAM lParam) { int nLen = GetWindowTextLength(hWnd); TCHAR szTitle[MAX_PATH]; GetWindowText(hWnd, szTitle, MAX_PATH); if(_tcsstr(szTitle,_T("YourApplicationTitle"))) { DWORD dwPID; TCHAR szModule[MAX_PATH]; HMODULE hModule; DWORD dwNeeded; GetWindowThreadProcessId(hWnd,&dwPID); HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,FALSE,dwPID); if(EnumProcessModules(hProcess,&hModule,sizeof(hModule),&dwNeeded)) { GetModuleFileNameEx(hProcess,hModule,szModule,sizeof(szModule)); } else { GetProcessImageFileName(hProcess,szModule,sizeof(szModule)); } TCHAR * p = _tcsrchr(szModule,_T('\\')); if(0 == _tcscmp(++p,_T("YourExecutable.exe"))) { LRESULT dwPercent = SendMessage(hWnd,WM_PERCENTAGE,0,0); DWORD dwP = dwPercent; //Do whatever with your percentage value here. } } return TRUE; } int main() { EnumWindows(GetPercentageProc, NULL); _getch(); return 0; }
Note that its recommended to use RegisterWindowMessage [^] for IPC although I did not use it in my example. Best Wishes, -David Delaune -
Rajesh R Subramanian wrote:
The console app must be notified of the progress of this lengthy operation periodically.
Mailslots, sockets and named pipes.... all for a simple integer percentage value? SendMessage returns a value in its LRESULT which can be used in the console application to retrieve small values such as percentage complete. Something like this:
#include "stdafx.h" #include <stdio.h> #include <string.h> #include <conio.h> #include <windows.h> #include <Psapi.h> #pragma comment(lib, "psapi") #define WM_PERCENTAGE WM_USER + 1033 BOOL CALLBACK GetPercentageProc(HWND hWnd, LPARAM lParam) { int nLen = GetWindowTextLength(hWnd); TCHAR szTitle[MAX_PATH]; GetWindowText(hWnd, szTitle, MAX_PATH); if(_tcsstr(szTitle,_T("YourApplicationTitle"))) { DWORD dwPID; TCHAR szModule[MAX_PATH]; HMODULE hModule; DWORD dwNeeded; GetWindowThreadProcessId(hWnd,&dwPID); HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,FALSE,dwPID); if(EnumProcessModules(hProcess,&hModule,sizeof(hModule),&dwNeeded)) { GetModuleFileNameEx(hProcess,hModule,szModule,sizeof(szModule)); } else { GetProcessImageFileName(hProcess,szModule,sizeof(szModule)); } TCHAR * p = _tcsrchr(szModule,_T('\\')); if(0 == _tcscmp(++p,_T("YourExecutable.exe"))) { LRESULT dwPercent = SendMessage(hWnd,WM_PERCENTAGE,0,0); DWORD dwP = dwPercent; //Do whatever with your percentage value here. } } return TRUE; } int main() { EnumWindows(GetPercentageProc, NULL); _getch(); return 0; }
Note that its recommended to use RegisterWindowMessage [^] for IPC although I did not use it in my example. Best Wishes, -David DelauneHi David, Isn't SendMessage going to be blocking? I was looking for something that would be asynchronous. (OK, I can use a thread, but I am just asking). I'll try this as well. Thank you for your suggestions.
It is a crappy thing, but it's life -^ Carlo Pallini