Calling external program

Aug 30, 2009 at 9:35pm
I've been looking through sites trying to find a way to call an external program from within a program. Maybe I don't even know what to search for? i.e. A program that gets user inputs and determines which program is appropriate, then calls that program and passes the arguments to it.
Aug 30, 2009 at 9:45pm
I'm not sure about this but I think you can use system("Cmd code to open a program here");
It's just a suggestion so don't smile yet.
Aug 30, 2009 at 10:01pm
That will work. I could build a string then use system(string.c_string) to call the program, but that would be windows specific. It seems like there should be something more powerful than that?
Aug 30, 2009 at 10:28pm
There might be somethin in the Windows API, the only way i know is system("C:/.../Notepad.exe")
Aug 30, 2009 at 11:21pm
Spawning a new process is a platform specific operation.

On a Windows platform, look at CreateProcess(...)

http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx

I'm not familiar with the Linux equivalent. I think it's fork(...) - maybe someone can clarify
Last edited on Aug 30, 2009 at 11:22pm
Aug 30, 2009 at 11:34pm
well aside from what Lodger just said, you can use system, which is quite easy. The command to use would look something like this : system("./fileb.exe");
Using system to launch a file has both advantages and disadvantages though.
System will automatically wait for fileb to return before it continues filea. This is both good and bad for uses under certain circumstances. The most important disadvantage of system though, is that you cannot by default exchange variables between them. However, as an easy work around for this, you can do the following :
1) Decide where you want these temporary variables to be placed.
- For example, on unix : /tmp is a great place as it clears on reboot, and it exists on all unix computers
- If you need cross-platform support, make a folder within your project named tmp or temp or whatever else you want
2) Use ifstream from fstream to get the saved variable from a file, text files are easiest to work with
3) Work with it, I recommend placing it into a variable and then leaving it.
4) Use ofstream from fstream to save the variable into a file, text files are nice
5) Enjoy! :)


EDIT : Sorry if ./ doesn't work on Windows, im a linux user.
Last edited on Aug 30, 2009 at 11:36pm
Aug 31, 2009 at 2:41am
Actually, the most important disadvantage of system() is that it introduces security vulnerabilities. Using a system-dependent method (that skips the shell) is always safer.

In Windows, it is CreateProcess(), which is really straight-forward to use.
http://www.google.com/search?btnI=1&q=msdn+CreateProcess

In POSIX (Linux, etc) it is a combination of fork() and one of the exec() functions.
http://linux.die.net/man/2/fork
http://linux.die.net/man/2/execve
http://linux.die.net/man/3/execv
These are also easy to use, but there are some caveats. Follow the example codes.

In all cases, IPC is another concern. You can always pass command-line arguments to a new process. You can also redirect the input/output of the child processes. There are also memory-mapped files. And message passing. Sockets. Etc.

Good luck!
Sep 1, 2009 at 6:57pm
hmm, i still don't see these security issues everyone talks about. How exactly is it a security issue? system() executes a shell command, it's as safe as a batch file or shell file. Unless it's opening some giant hole in your firewall and calling every virus distributer in the world to forward their viruses to you, i don't see what the big deal is. I mean : sure, it's not the greatest method to get everything done and i certainly agree with not using pause with it, but it's a lot easier than using fork or createprocess and you get the hang of it instantly. Although, if what you're making is for some corporation or you're getting paid for it or whatever, i certainly wouldn't do it, but im assuming most of the stuff people ask for help on is a hobby program.
Sep 1, 2009 at 8:49pm
Sure are an arrogant little snot, aren't you?

The system shell is the security hole.

It is a pretty cavalier way to spend your employer's time and money to use the "easy" way and make the software less safe, less robust, and less managable.


[edit]
@elvenspike
Sorry I was rude.
Last edited on Sep 1, 2009 at 8:50pm
Sep 2, 2009 at 2:51am
Well like i said : It's not the greatest method to get things done and I wouldn't use it if I'm getting paid, and wouldn't recommend it to anyone in that situation. But for a school project or a hobby thing, it gets the job done. Anyway, I wouldn't call it a security hole, more like... an untrusted command. If you know EXACTLY what it's doing, like if you made it yourself, is it really unsafe? Again, I'm assuming these are hobbyist programs, considering if you're coding for a corporation or are getting paid for it, you should probably know how to do something like this anyway. Besides that, it's cool, I AM arrogant, although I don't see the arrogance in that post. I simply asked what the security issue was, then included some sarcasm.
Sep 2, 2009 at 3:11am

If you know EXACTLY what it's doing, like if you made it yourself, is it really unsafe?


That's the point. You think you know what it is doing, but in reality you don't.

One of the easiest exploits is when UNIX programmers use exec() and allow the shell
to search the user's PATH for the named executable. Suddenly your exec() of "ls /"
executes something other than /bin/ls (because a hacker put an "ls" executable in a directory
in the PATH before /bin and now "ls /" turns into "rm -rf /".

Same sort of principle with system().
Sep 2, 2009 at 3:26am
Again, I'm talking : If I make this program, I know perfectly well what it's doing, unless I got the specific line elsewhere and I don't know what it does. Not to say that everything you get elsewhere is made by a hacker, but system() in itself isn't a security hole. What can be done with it is unsecure, but if you make it yourself it's fine, again, unless it's a line or whole code gathered from somewhere else. Obviously what you're saying is a huge deal, but that's a matter of trusted programs. Unless what you were saying there is that using exec() could potentially feed information to a virus or something of that sort, even if you coded the program and it's perfectly harmless.
Sep 2, 2009 at 3:35am
http://en.wikipedia.org/wiki/Security_hole

In computer security, the term vulnerability is a weakness which allows an attacker to reduce a system's Information Assurance. Vulnerability is the intersection of three elements: a system susceptibility or flaw, attacker access to the flaw, and attacker capability to exploit the flaw. [1] To be vulnerable, an attacker must have at least one applicable tool or technique that can connect to a system weakness. In this frame, vulnerability is also known as the attack surface.
Sep 2, 2009 at 3:40am
Hmm, I stand corrected but I, personally, wouldn't refer to it as a security hole but that's just me. When I think of security hole, I think of a person with every port open and forwarded to them and posts on facebook/myspace/digg/whatever/whatever/whatever that tell everyone they know and more that all of their ports are open and provide their external IP. That's not the only thing that qualifies, but that's a fair example of something major stupidity causing system vulnerability. Otherwise, a glitch in a browser that allows a website to slip a keylogger onto your harddrive or something of that sort.
Sep 2, 2009 at 6:38am
i think you could make some kind of DLL and then call it from the first program...
and within that DLL must be the code that is gonna open new program
Sep 2, 2009 at 7:00am
Why so compicated? just use system, or to satisfy everyone : simply fork() a child. That's all. just fork that child real good. :)
Topic archived. No new replies allowed.