I have two process. Ferst process create console window, second process shuld print some simbols in ferst process console.
If i use WinApi, I have AttachConsole(DWORD dwProcessId) function, is it possible to do something similar using boost?
The interprocess and process libraries have functions for attaching to processes, but I don’t understand how to use one console for two processes.
Something similar maybe can do with boost::asio,but i think this is not what i need
Related
I am creating process using create process does anyone knows how to use create function if process is already running not create or externally having any other way to detect process is running.
On Windows, you use the Process Status API (PSAPI) to search through all the processes running on the system. The degree of access you have to this resource will depend on the privileges that the program is running under.
See the MSDN article
Specifically, you would invoke the EnumProcesses function to get a full list of the running processes IDs, then, using those IDs use other functions in the API to get information about them. For example, to get a processes name, and have it's ID already, you could call GetProcessImageFileName.
Beware that these functions have ASCII and Wide-character versions.
All I need is just to write a simple MFC Windows application using MSMPI, but I don't want to launch multiple processes as my GUI application may need some user interaction before the multi-threading part. For instance, I'd like to create 2 threads after click a 'Run' button.
I have tried to run my program using the command line: mpiexec.exe -n 2 myprogram.exe but this will create two processes and I will see two application windows.
I have also tried the MPI cluster debugging option in Visual Studio 2010 but it creates two processes as well.
This seems to be a very basic question but I find it difficult to find an answer in Google.
Edit
To eliminate the confusion here, I have to clarify a few things:
I have a very complicated and large codebase that already uses MS-MPI to achieve parallelism and I have to build a MFC GUI on top of it. For this reason, I cannot use any other parallelism mechanism such as std::thread because that will mean I have to rewrite a lot of things which is not affordable.
From my understanding, to launch a MPI program, I have to run the external program called mpiexec.exe in Windows. I haven't figured out if it is possible to launch the program by its own and still achieve MPI features. I'm quite new to MPI. I'm not so sure if it is possible to achieve what I'm asking for. If it is not, I would be very appreciated if anyone can let me know why and possible workaround.
Simply put, I want to create a MFC GUI wrapper for a MPI enabled software and this has to be a multithreading program instead of multiple instances (processes) of this GUI wrapped program (e.g. running this program by mpiexec -n 2 xxx.exe will just create 2 instances of the same program)
I'm guessing you're creating some kind of graphical front-end for some MPI software you have. As far as I can see you have two options.
Option 1
Create a separate Win32 application (without MPI) that is your GUI, let this application run "mpiexec" or equivalent with the correct parameters to start the application when the user requests to.
Option 2
You need to make sure you only launch the GUI on one MPI instance. You do this by looking up the ID of the current program from MPI during startup and if it is 0, start the GUI.
Something like this:
int main(int argc, char** argv){
int myid;
...
MPI_Init(&argc, &argv);
...
MPI_Comm_rank(MPI_COMM_WORLD,&myid);
if(myid == 0){
launchGui();
}else{
waitForAndProcessMessages();
}
...
MPI_Finalize();
return 0;
}
Obviously you still need to fill in all the bits an pieces to make MPI function as you normally would but in this example the first launched instance will become the GUI and not do any processing. Any instance that later joins the HPC will wait for messages and process them until they terminate.
I'd like to create 2 threads after click a 'Run' button"
Since, you have VS 2010, I am not sure of std::thread compatibility. You could use MFC's threading API as follows -
CWinThread* myThread = AfxBeginThread(myThreadFunc, &threadInfoStruct);
You can use PostThreadMessage API to relay information between various MFC threads, i.e. from GUI to Business logic, and thus into MPI threads and back.
Of course, if your compiler supports std::thread, that is the way to go.
Related to std::thread, often the most correct way to implement what you want is to use std::async. Read up about thread based programming vs task based programming in Effective Modern C++.
I want to create 5 child process in Windows using C++. But I am confused that CreateProcess asks for lpApplicationName and not like fork in which I can figure out whether I am child or parent. how to do this in Windows
Unfortunately the CreateProcess function can only be used to load a program and start a new process for that program.
You can however use CreateProcess to simulate the fork functionality, by asking it to load the program you are already running, and then ask it to jump to the correct position. This is what is (or was, at least) done by Cygwin, as referenced by this old answer.
It is usually preferable in Windows to use threading rather than multiple processes, because processes are much heavier objects in Windows than in UNIX.
However, you can do what you're asking by passing the name and path of your application to CreateProcess (using GetModuleFileName if you don't already know it) and including a command-line argument to tell your application that it is being launched as a child process.
Keep in mind that the child processes will be started from scratch, they will not have a copy of the parent's memory as they would if you were using fork.
I've searched the web, and various forums, but I can't find one thing, how to continually monitor open programs and then close another program (not the one being monitored) if something happens to the program being monitored.
For example, say that there is an already open Notepad window, and then the user or some other program opens a Windows Explorer window. I want to know how to close the Notepad window without interacting with the Windows Explorer window (other than realizing that it is indeed open), as well as closing the Notepad window if the user closes the Windows Explorer window.
Thanks in advance! :D
On windows, you can use PSAPI (The Process Status API) to know when processes are started and terminate. The EnumProcesses function can give you this information.
A more reliable method to determine that a process terminated (since process ids can be reused) is to wait on its process handle (you will need the SYNCHRONIZE access right) which you can obtain using OpenProcess and the process' id obtained from EnumProcesses.
To terminate a process, there is always TerminateProcess. To call TerminateProcess, you will need a handle to the process with the PROCESS_TERMINATE access right. All of this assumes that you have the privileges needed to perform these actions on the process to be terminated.
One thing to be aware of is that processes and programs - or at least what the user regards as a program - are not necessarily the same thing.
If you use the PSAPI to get a list of all the processes running, you'll see a lot of background process that don't correspond to open windows at all. There's also cases where a single process can have multiple top-level windows open. So while you have simple cases like notepad where once notepad.exe process corresponds to one Notepad window, you also have cases like:
Word, where one word process handles all the word documents currently open (one process, many windows)
Explorer, where a single exploere.exe process handles all the open explorer windows, and also things like control panel windows and the task bar.
Chrome (and other browsers), where each tab gets its own process (many processes, one window!)
Using TerminateProcess is perhaps not the best way to close an app: it's not directly equivalent to clicking the close button. It forcibly terminates the entire process there and then, without giving it any chance to clean up. If you do this on Word, when it restarts, it will go into 'recovery mode', and act as though it hadn't shut down cleanly the last time. It's best left as a last resort if a process has stopped responding. Also, if you TerminateProcess on a process like Word or Explorer, you'll end up closing all windows owned by that process, not just one specific one.
Given all of this, if you want to essentially write some sort of program manager, you might be better off taking a window-centric approach rather than a process centric one. Instead of monitoring running processes, monitor top-level application windows.
There are several ways to listen for changes to windows; SetWinEventHook with EVENT_CREATE/DESTROY is one way to listen for HWNDs being created or destroyed (you'll need to do filtering here, since it will tell you about all HWNDs - and more! - but you only care about top-level ones, and only app ones at that). SetWindowsHookEx may have other options that could work here (WH_CBT). You can also use EnumWindows to list the windows currently present (again, you'll need to filter out owned dialogs and tooltips, currently invisible HWNDs, etc).
Given a HWND, you can get process information if needed by using GetWindowThreadProcessId.
To close a window, sending WM_SYSCOMMAND/SC_CLOSE is the best thing to try first: this is closer to clicking the close button, and it gives the app a chance to clean up. Note that some apps will display a "are you sure you wish to close?" dialog if you haven't saved recently - again, it's consistent with clicking the close button with the mouse.
The most well-known way of doing this on Windows is to use the Process Status API. You can use this API to enumerate processes However, this API is annoying in that it doesn't guarantee you get the full list or processes.
A better way to enumerate processes is using the Tool Help Library, which includes a way to take a complete snapshot of all processes in the system at any given time.
You need the Microsoft PSAPI (Processes API), for example to see the open processes you can use the openProcess function.
Is there a way (in C++ & windows XP) to detect if one process spawns any other processes?
for example,
write.exe in system32 spawns wordpad.exe then disappears, is there a function that tells me if the process is about to do this?
for those interested i solved the problem using this section of msdn:
http://msdn.microsoft.com/en-us/library/aa390425(v=VS.85).aspx
Nothing in the Win32 API for this. However, it is supported through WMI with the Win32_ProcessStartTrace query. You'll find some C# code that demonstrates the query in my answer in this thread. Writing WMI code in C++ is fairly painful, you'll find a link to boilerplate code you have to write in the MSDN Library article.
Do beware that this isn't particularly fast. It isn't clear to me how much help the WMI provider gets from the kernel to generate the notification but given the speed it quacks like polling. In other words, the process is likely to be well on its way by the time you get the notification. This is otherwise par for the course on a multitasking operating system.
You can enumerate over the process tree, which identifies running processes and their parents. This is the inverse of what you want (you want to identify child processes, not parent processes). But of course by keeping track of parent process IDs while enumerating, you can identify which sub-processes a given process has spawned.
To do this, call CreateToolhelp32Snapshot and then use Process32First and Process32Next to enumerate the processes. The enumeration will fill in a PROCESSENTRY32 struct that contains a th32ParentProcessID member.
This is a polling method; there may be another way of actually hooking the CreateProcess function, but I don’t have any information about that.
I think you would need to make a global hook DLL that attaches itself to every running process. DLL then finds a place where a function call to CreateProcess is mapped to actual CreateProcess from kernel32, and change a table entry to redirect the call to it's own code to "detect" the call to CreateProcess. All this assuming that some user firewall will not prevent your global hook from executing.