# C++: calling external programs

## Recommended Posts

Can someone tell me which instructions i need to call, for example, iexplore.exe from a C++ program ? Something like the shell function in VB.

##### Share on other sites
The windows dependent way of calling a program is either with the 'system("prog_name")' or ShellExecute function under the Win32 API.

Command Line pass call
 #include stdlib.h... system("program_name");

Shell Execute
The ShellExecute function opens or prints a specified file. The file can be an executable file or a document file. See ShellExecuteEx also. HINSTANCE ShellExecute(    HWND hwnd,	// handle to parent window    LPCTSTR lpOperation,	// pointer to string that specifies operation to perform    LPCTSTR lpFile,	// pointer to filename or folder name string    LPCTSTR lpParameters,	// pointer to string that specifies executable-file parameters     LPCTSTR lpDirectory,	// pointer to string that specifies default directory    INT nShowCmd 	// whether file is shown when opened   );	 ParametershwndSpecifies a parent window. This window receives any message boxes that an application produces. For example, an application may report an error by producing a message box.lpOperationPointer to a null-terminated string that specifies the operation to perform. The following operation strings are valid:String	Meaning"open"	The function opens the file specified by lpFile. The file can be an executable file or a document file. The file can be a folder to open."print"	The function prints the file specified by lpFile. The file should be a document file. If the file is an executable file, the function opens the file, as if "open" had been specified."explore"	The function explores the folder specified by lpFile.  The lpOperation parameter can be NULL. In that case, the function opens the file specified by lpFile. lpFilePointer to a null-terminated string that specifies the file to open or print or the folder to open or explore. The function can open an executable file or a document file. The function can print a document file. lpParametersIf lpFile specifies an executable file, lpParameters is a pointer to a null-terminated string that specifies parameters to be passed to the application.If lpFile specifies a document file, lpParameters should be NULL. lpDirectoryPointer to a null-terminated string that specifies the default directory. nShowCmdIf lpFile specifies an executable file, nShowCmd specifies how the application is to be shown when it is opened.  This parameter can be one of the following values: Value	MeaningSW_HIDE	Hides the window and activates another window.SW_MAXIMIZE	Maximizes the specified window.SW_MINIMIZE	Minimizes the specified window and activates the next top-level window in the Z order.SW_RESTORE	Activates and displays the window. If the window is minimized or maximized, Windows restores it to its original size and position. An application should specify this flag when restoring a minimized window.SW_SHOW	Activates the window and displays it in its current size and position. SW_SHOWDEFAULT	Sets the show state based on the SW_ flag specified in the STARTUPINFO structure passed to the CreateProcess function by the program that started the application. An application should call ShowWindow with this flag to set the initial show state of its main window.SW_SHOWMAXIMIZED	Activates the window and displays it as a maximized window.SW_SHOWMINIMIZED	Activates the window and displays it as a minimized window.SW_SHOWMINNOACTIVE	Displays the window as a minimized window. The active window remains active.SW_SHOWNA	Displays the window in its current state. The active window remains active.SW_SHOWNOACTIVATE	Displays a window in its most recent size and position. The active window remains active.SW_SHOWNORMAL	Activates and displays a window. If the window is minimized or maximized, Windows restores it to its original size and position. An application should specify this flag when displaying the window for the first time. If lpFile specifies a document file, nShowCmd should be zero.  Return ValuesIf the function succeeds, the return value is the instance handle of the application that was run, or the handle of a dynamic data exchange (DDE) server application.If the function fails, the return value is an error value that is less than or equal to 32. The following table lists these error values:Value	Meaning0	The operating system is out of memory or resources.ERROR_FILE_NOT_FOUND	The specified file was not found.ERROR_PATH_NOT_FOUND	The specified path was not found.ERROR_BAD_FORMAT	The .EXE file is invalid (non-Win32 .EXE or error in .EXE image).SE_ERR_ACCESSDENIED	The operating system denied access to the specified file. SE_ERR_ASSOCINCOMPLETE	The filename association is incomplete or invalid.SE_ERR_DDEBUSY	The DDE transaction could not be completed because other DDE transactions were being processed.SE_ERR_DDEFAIL	The DDE transaction failed.SE_ERR_DDETIMEOUT	The DDE transaction could not be completed because the request timed out.SE_ERR_DLLNOTFOUND	The specified dynamic-link library was not found. SE_ERR_FNF	The specified file was not found. SE_ERR_NOASSOC	There is no application associated with the given filename extension.SE_ERR_OOM	There was not enough memory to complete the operation.SE_ERR_PNF	The specified path was not found.SE_ERR_SHARE	A sharing violation occurred. RemarksThe file specified by the lpFile parameter can be a document file or an executable file. If the file is a document file, the ShellExecute function opens or prints it, depending on the value of the lpOperation parameter. If the file is an executable file, the ShellExecute function opens it, even if lpOperation specifies printing. You can use ShellExecute to open or explore a shell folder. To open a folder, use either of the following calls:ShellExecute(handle, NULL, path_to_folder, NULL, NULL, SW_SHOWNORMAL);or  ShellExecute(handle, "open", path_to_folder, NULL, NULL, SW_SHOWNORMAL);  To explore a folder, use the following call:ShellExecute(handle, "explore", path_to_folder, NULL, NULL, SW_SHOWNORMAL);  If lpOperation is NULL, the function opens the file specified by lpFile. If lpOperation is "open" or "explore", the function will force an open window or explorer.See AlsoFindExecutable, ShellExecuteEx [/soure]

##### Share on other sites
Quote:
 Original post by XiachunyiThe windows dependent way of calling a program is either with the 'system("prog_name")'...
system isn't Windows-dependent. It's a Standard C Library function. It's also largely useless.

##### Share on other sites
Quote:
Original post by Oluseyi
Quote:
 Original post by XiachunyiThe windows dependent way of calling a program is either with the 'system("prog_name")'...
system isn't Windows-dependent. It's a Standard C Library function. It's also largely useless.

Oh okay, the reason I said it was system dependent was because didn't linux have another function that you have to call to pass in commands?

##### Share on other sites
Quote:
 Original post by XiachunyiOh okay, the reason I said it was system dependent was because didn't linux have another function that you have to call to pass in commands?
system exists on Linux. You're thinking of fork, which is a POSIX-specific process creation API. It's less robust than CreateProcess, however.

##### Share on other sites
Quote:
Original post by Oluseyi
Quote:
 Original post by XiachunyiOh okay, the reason I said it was system dependent was because didn't linux have another function that you have to call to pass in commands?
system exists on Linux. You're thinking of fork, which is a POSIX-specific process creation API. It's less robust than CreateProcess, however.

fork in conjunction with execv/execve, presumably.

To expand on system—while Oluseyi is of course correct in that it is not a platform specific call, usage of it is frequently denounced as such on these forums for the simple reason that while system is a standard function, pretty much anything you will ever call from it (such as the ubiquitous "PAUSE") are obviously highly platform specific.

Edit: Now I'm curious. I have no experience with Win32 programming—what do you mean when you say that the fork/execv* way is 'less robust'?

[Edited by - Miserable on October 3, 2004 12:09:47 PM]

##### Share on other sites
Quote:
 Original post by MiserableTo expand on system—while Oluseyi is of course correct in that it is not a platform specific call, usage of it is frequently denounced as such on these forums for the simple reason that while system is a standard function, pretty much anything you will ever call from it (such as the ubiquitous "PAUSE") are obviously highly platform specific.
Not only that. It evaluates the command on the basis of the user environment, specifically the PATH, with no controls. If a malicious attacker were able to install an arbitrary binary named pause[.[com|exe|bat]] in the application directory and the current directory is included in the user PATH, that unknown binary would be executed instead of the expected system-supplied pause.

Quote:
 Edit: Now I'm curious. I have no experience with Win32 programming—what do you mean when you say that the fork/execv* way is 'less robust'?
CreateProcess includes security attribute parameters, which can prevent the above situation from occuring. Of course, most programmers simply pass a NULL security attribute to inherit from the calling program, but that's not the API's fault!

##### Share on other sites
Quote:
 Original post by Oluseyi... It evaluates the command on the basis of the user environment, specifically the PATH, with no controls. If a malicious attacker were able to install an arbitrary binary named pause[.[com|exe|bat]] in the application directory and the current directory is included in the user PATH, that unknown binary would be executed instead of the expected system-supplied pause...
WRT your "no controls" statement, it is rare that your .*rc file would define . before anything else in your PATH variable, so it's actually quite unlikely your malicious attacker will get this trojan to work (for what it's worth, . isn't even in my PATH). I should say though, that I've no idea how windoze does this (I use Linux... \o/).

##### Share on other sites
Quote:
Original post by Symphonic
Quote:
 Original post by Oluseyi... It evaluates the command on the basis of the user environment, specifically the PATH, with no controls. If a malicious attacker were able to install an arbitrary binary named pause[.[com|exe|bat]] in the application directory and the current directory is included in the user PATH, that unknown binary would be executed instead of the expected system-supplied pause...
WRT your "no controls" statement, it is rare that your .*rc file would define . before anything else in your PATH variable, so it's actually quite unlikely your malicious attacker will get this trojan to work (for what it's worth, . isn't even in my PATH). I should say though, that I've no idea how windoze does this (I use Linux... \o/).

The way the PATH variables work in Windows, actually it would be quite easy. For instance, %systemroot%\System32 evaluates before %systemroot% , so if a trojan named explorer.exe was placed in C:\Windows\System32 , a program would call it instead of the desired one in C:\Windows. And then of course if the trojan had edited the PATH variable and made a different folder be checked before these...lets just say that things go wrong.

##### Share on other sites
Quote:
Original post by Oluseyi
Quote:
 Edit: Now I'm curious. I have no experience with Win32 programming—what do you mean when you say that the fork/execv* way is 'less robust'?
CreateProcess includes security attribute parameters, which can prevent the above situation from occuring. Of course, most programmers simply pass a NULL security attribute to inherit from the calling program, but that's not the API's fault!

In linux you just either change your working user to drop root privileges or you run the program as an un-privileged user, so it can only hurt things that user can access.

I'll take filesystem level over API level, thank you :P

##### Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by Oluseyi
Quote:
 Edit: Now I'm curious. I have no experience with Win32 programming—what do you mean when you say that the fork/execv* way is 'less robust'?
CreateProcess includes security attribute parameters, which can prevent the above situation from occuring. Of course, most programmers simply pass a NULL security attribute to inherit from the calling program, but that's not the API's fault!

In linux you just either change your working user to drop root privileges or you run the program as an un-privileged user, so it can only hurt things that user can access.

Or maybe even *gasp* drop priviliges programmatically via a system call in the child of the fork - before the execution of the external program.