Well. I 'm trying to get a program in C++(MS-DOS) to open another .exe file. I thought there might have been a way with the:
to call it, but somehow it does not work and its like it skips it completely.
I'd appreciate any help. Thankyou.
(Sorry about the title, i meant execute an .exe)

your statement should actually work. Perhaps you got the path wrong? You could try something like:

Is it absolutely necessary to open main.exe? I personally don't like the system() command, because if someone would replace the "main.exe" program with a renamed version of "format C: /q" you would be in a hell of a lot of trouble

It works now, thanks.

what do you mean by "format C: /q"?

And what happens if you do?

What he means is that system calls suffer from security issues.


There's nothing to stop a user creating a program called main.cpp which may contain malicious code, then compiling it, and sitting that executable in the same directory as the other executable.

So when his other program calls system("main.exe") it would execute the virus/trojan/whatever.

In regards to what format c: /y does, it should format (wipe) your C:\ drive I believe, although I haven't tested it - obviously.

There is nothing inherently evil about system(), or executing other executables; just be aware that you must be careful how you do it.

So in that scenerao what is the difference between calling system(), CreateProcess() and ShellExecute() -- they all spawn other processes. system() is no more or less a security risk than any of the others.

>So in that scenerao what is the difference between calling system()

There isn't. I never said it was more of a security risk.


I agree with you in the sense that the above quote has a flawed explanation. If you used shellexe createproc (whatever) it would have the same desired affect.

For the OP, the security danger is in executing less-privileged programs with more-privileged programs. That is, a low-level hax0r can write malicious code and get someone with access rights he doesn't have to execute his program. Doing so gives the executed program all the access rights as the calling program, and the maliciousness is unbounded.

Typically, programs will execute others under [edit]three[/edit] scenarios:

1. As a user tool.
   Programs like Explorer or ObjectDock/Launcher/whatever or Irfanview, WinAmp, etc. need to execute other programs in order to satisfy the user's instructions. Explorer runs the program you double-click. Irfanview uses the QuickTime Player to play .mov files. Etc.
2. As part of a known software system.
   For example, your IDE lets you edit programs: it may use OLE to embed an editor. It calls the compiler and linker and even programs like make to execute scripts that compile and link your program. The fancy GUI program you are using may only display the GUI and interact with the user. It could be actually doing stuff by executing other executables that came with the GUI. Often, the GUI itself is an external program. GIMP, for example, uses GTK, which is provided via a nice DLL sitting in your system32 directory. If you like Linux, your fancy calculators all farm out to bc to do the math. Etc.
3. As an extension/add-on/plug-in/interpreter to add functionality to a program.
   For example, Softimage|XSI uses Perl to allow users to write scripts that do things the program doesn't do itself. Blender uses Python in the same way. (Both are 3D modelling and animation systems.) If you are reading this with Firefox right now, you have probably used some plugins to modify it somewhat. I'm using the Blue Ice 2 theme, and the Hide Menubar, Back/Forward Dropdown Remover, and Download Statusbar plugins. (They're great.) All these were written with some combination of scripting powers: XML, Javascript, VBScript, etc.
   Extra care must be taken with this kind of power, because unscrupulous people can easily execute their own evil scripts -- so the interpreter must be executed with less privilege than the calling program.

In [edit]all[/edit] cases, however, there is a degree of security. In the first, the user directly controls which processes he causes to execute. He (should) know what they are and what they do. In the second, the executed process came packaged as part of the executing process. If you trust one to execute, you can trust the other --since they are both from the same source. In the third, attempts to do something that is not permitted is simply not permitted -- the script/plug-in/whatever explicitly cannot do all the things the calling program can.

How's that for information overload?

Whew.