   How to run an application in c++
  I would like to know if there is a Windows  c++ API function which allows the running of a program by another ?cheers !!   
  I'm confused about what you mean.  If you just want to run a program then you need to compile it, which makes an .exe which you can run.   ;  Nice to see some more people from Oxford on the forums.Suggestions:1. Use system() in stdlib.h which will execute a program and wait until it finishes.2. If you also want to capture the output, consider popen() if your C library supports it.3. Use an operating system-specific method such as:win32 - CreateProcessUnix - fork(), exec() functions etc, vfork() perhaps instead of fork()These methods are more advanced and will require the use of more OS-specific functions to check that the process has started, finished or is still running and/or get its exit code.These methods will (typically) return immediately before the child process has even got going properly - the child process will then execute independently of its parent.Mark;  You can run programs by usingsystem("programname");This will run it as if you did so from the command line (so the program must be located in your PATH). This is not really safe though, because anyone can put a program in the same directory with the same name, and your program will run that instead.   ;  thanks everybody. i think i'm going to use system("programname");   ;  Keep in mind that system() will block; that is, your spawning program will sit there unable to do anything until the program it spawned has completed. This may not be the desired behavior, but that is a firm limitation of system().   ;Quote:Original post by OluseyiKeep in mind that system() will block; that is, your spawning program will sit there unable to do anything until the program it spawned has completed. This may not be the desired behavior, but that is a firm limitation of system().you're right, that's a pretty bad behaviour...   ;  Here's the truth: C and C++ are very, very platform agnostic languages. They have no notion of graphics, no notion of consoles (they only know of standard input, output and error - which may not pipe to consoles at all), no sophisticated notions of files (their file handling is so primitive that to copy a file you need to open a new filestream and duplicate its read buffer!), have no notion of threads or applications... natively.To do any of these things with C or C++, you rely on system-specific APIs such as POSIX, Xlib, Win32, or abstraction libraries such as Gtk, wx, etc. Basically, don't bother with system(); it's a waste of your time, and its downsides outweigh any advantage it might seem to offer:It's a blocking call, so your program is frozen while the spawned program executes.It is dependent on system path, so if a program of a different intent with the same name occurs earlier on the path than the one you inteded, well, whoops!Since it's blocking anyway, this is sort of moot, but you don't get any form of inter-process communication with the spawned program.It executes by starting a command shell instance under Windows! Yuck!It's a popular suggestion because it's easy, it doesn't require a system-specific API, and it lets people feel like they've done something complex - except that the minute you actually try to do something complex or useful with it, you run smack into all its limitations.If you're targeting Windows, please use CreateProcess.   ;Quote:Original post by OluseyiHere's the truth: C and C++ are very, very platform agnostic languages. They have no notion of graphics, no notion of consoles (they only know of standard input, output and error - which may not pipe to consoles at all), no sophisticated notions of files (their file handling is so primitive that to copy a file you need to open a new filestream and duplicate its read buffer!), have no notion of threads or applications... natively.To do any of these things with C or C++, you rely on system-specific APIs such as POSIX, Xlib, Win32, or abstraction libraries such as Gtk, wx, etc. Basically, don't bother with system(); it's a waste of your time, and its downsides outweigh any advantage it might seem to offer:It's a blocking call, so your program is frozen while the spawned program executes.It is dependent on system path, so if a program of a different intent with the same name occurs earlier on the path than the one you inteded, well, whoops!Since it's blocking anyway, this is sort of moot, but you don't get any form of inter-process communication with the spawned program.It executes by starting a command shell instance under Windows! Yuck!It's a popular suggestion because it's easy, it doesn't require a system-specific API, and it lets people feel like they've done something complex - except that the minute you actually try to do something complex or useful with it, you run smack into all its limitations.If you're targeting Windows, please use CreateProcess.thanks for the explanations   ;  i've got a problem with the last parametter of the function i don't get how to set it CreateProcess.BOOL CreateProcess(   LPCWSTR pszImageName,   LPCWSTR pszCmdLine,   LPSECURITY_ATTRIBUTES psaProcess,   LPSECURITY_ATTRIBUTES psaThread,   BOOL fInheritHandles,   DWORD fdwCreate,   LPVOID pvEnvironment,   LPWSTR pszCurDir,   LPSTARTUPINFOW psiStartInfo,   LPPROCESS_INFORMATION pProcInfo); 