C++: calling external programs
Author
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.
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
Shell Execute
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]
Quote:Original post by Xiachunyisystem isn't Windows-dependent. It's a Standard C Library function. It's also largely useless.
The windows dependent way of calling a program is either with the 'system("prog_name")'...
Quote:Original post by OluseyiQuote:Original post by Xiachunyisystem isn't Windows-dependent. It's a Standard C Library function. It's also largely useless.
The windows dependent way of calling a program is either with the 'system("prog_name")'...
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?
Quote:Original post by Xiachunyisystem exists on Linux. You're thinking of fork, which is a POSIX-specific process creation API. It's less robust than CreateProcess, however.
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?
Quote:Original post by OluseyiQuote:Original post by Xiachunyisystem exists on Linux. You're thinking of fork, which is a POSIX-specific process creation API. It's less robust than CreateProcess, however.
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?
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]
Quote:Original post by MiserableNot 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.
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.
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!
Quote:Original post by OluseyiWRT 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/).
... 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:Original post by SymphonicQuote:Original post by OluseyiWRT 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/).
... 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...
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
