What are the main differences between the two? I'm willing to run only another EXE from my (C++) application. Are there any differences when inheriting environments, security features etc?
The main difference between CreateProcess and ShellExecute is the following: CreateProcess is more oriented on low level and ShellExec on the high user lever which see the user in explorer.
For example using of CreateProcess one can use command line which length is more as MAX_PATH. It has 32,768 characters restriction. You can also use CreateProcess to start program (if you have enough permissions) on another windows desktop like on the Logon Screen.
Another example. You can use ShellExecute to start Control Panel or open any program which existed on the computer for editing of JPG filed for example. So you works with ShellExecute close to the corresponding actions in the Windows Explorer.
The main difference is in flexibility. ShellExecute is easier to use, but doesn't have a lot of flexibility. CreateProcess is a pain to use, but lets you do anything.
Just for example, with CreateProcess, you can specify handles (pipes or files) to use for the standard input/output/error streams in the child. ShellExecute doesn't give you want way to do that.
It's probably also worth noting that although ShellExecute can be used to start an executable directly, its primary intent is to "execute" document files -- for example, tell it to "execute" a "whatever.html", and it starts up your default web browser and loads the specified HTML file into it. You can do that using CreateProcess as well, but to do it, you (normally) start by calling FindExecutable to find the program associated with the data file in question, then execute that passing your data file as a parameter.
CreateProcess returns the handle and id for the started process and it's main thread in the PROCESS_INFORMATION structure
Related
I've researched it all over StackOverflow and Google but only get results about C# and irrelevant topics, so now I have to ask. I want after 20 seconds of the application being open to close itself and open another application that is in the same folder. After I have debugged, I copy the application to the folder on my Desktop that I will eventually ZIP up. But I want the app to open another application in the folder. Say for instance ApplicationA.exe Opens and after 20 seconds it closes and ApplicationB.exe opens.
You can use the CreateProcess() winapi function which acts like fork()+exec() and then exit() the ApplicationA. Also you can use Sleep(miliseconds) for the delay.
Here is the information about CreateProcess():
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
You can open it with system("ApplicationB.exe"); and then exit. This will start ApplicationB.exe and exit ApplicationA.exe.
Check out: http://www.dreamincode.net/forums/topic/18057-run-external-executable/
I believe C++ is not really the best way to go for system calls like the ones you need to do here. Maybe shell scripting would be a better option.
Anyway, the easiest way is probably writing a third program that opens ApplicationA.exe, closes it and starts ApplicaionB.exe.
I believe in C++ you'd have to use system, which you find in <cstdlib>. Yes, it is a C feature, not a C++ one, and its use is not encouraged, to put it mildly.
I would recommend using the ShellExecute function. http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx
Is it possible to embed system command line right inside your application window?
I want to be able to have the command line take some space on the bottom of my C++ application, and my application to take the above space. Ideally it should work on Mac, Linux and Windows, but for starters Windows is the primary goal as I am developing on it.
Speaking for Windows, the Windows console window is "special" in that it gets special treatment, different than any other window on the system. You will not succeed in manipulating it for your own use. For a good example, try using Spy++ on a console window.
Note that the window created with AllocConsole is not a command-line interpreter, it's just a console window.
You should implement your own console window, and as far as interpreting the commands I can think of a few options to explore depending on what you expect, behavior-wise and complexity-wise:
Delegate commands to a hidden cmd.exe
Interpret commands yourself
There are probably open-source solutions for command line interpreting.
In Windows, you can do that using some WinAPI functions like ShellExecute and CreateProcess (there are a few others that I don't remember). You get the command string from your GUI, pass it to one of these WinAPI functions, then send the output back to your GUI.
You want to do this on multiple platforms, so I would suggest making a generic module (class or namespace of functions, whatever fits you best) that allows using the OS terminal agnostic of the actual underling OS. Then. when you want to port your app to another OS, you just change the implementation of this module.
Note: Boost has (had?) a library under development that made running shell commands easier, Boost.Process. But it's currently on version 0.4 and hasn't been updated since October 4, 2010 (even though its status is still "on going").
I'm trying to find an easy way to execute a java vm in windows using a C++ wrapper. I can use CreateProcess() to launch java.exe directly with all of my parameters that I need to give it. The problem is this now shows up as two processes in process manager. So, if I kill the parent process, the java.exe instance still sticks around.
The reason I need to do this is that we have a few java programs, all of which will be running concurrently. I want to be able to give them distinguishable names in the process explorer, so that if a user has trouble with one of them, they don't have to guess which java.exe process that corresponds to.
You can replace java.exe with your own executable. This article from the Java Glossary discusses how java.exe works and where to find the source for it. It's possible that you could get by simply by copying and then renaming java.exe
I want to execute a certain batch file and redirect its console output to a text control in visual c++ or redirect the console output at the same time the logs/echo are showing.
Basically, you have to make the run process to write to a pipe, and to read the output of this pipe.
[EDIT] I know how SciTE does that (you can take a look at the source: win32/SciTEWin.cxx, ExecuteOne function), I searched a slightly more generic way, found How to spawn console processes with redirected standard handles from Microsoft itself.
If you seach CreatePipe PeekNamedPipe CreateProcess keyword, for example, you might find other examples.
Another option is to use Boost.Process (Boost.Process is not (yet) an official Boost C++ library. It must be downloaded and installed separately).
The example "Child.4 - Reading from a child using asynchronous I/O" shows how to redirect the output of the child process into a C++ stream (and later access the content).
Example "Child.4 - Reading from a child using asynchronous I/O" show how to use Boost.Process togehter with Boost.Asio to access the childs I/O asynchronous.
The advantages of this method is, that Boost.Process supports the Windows API and POSIX API.
If elegance is not a priority then a really simple solution might be to redirect the output to a file, and then read in the file contents.
Writing a program in c++ and I want to issue a system command from the system() function but I don't want the user to see the command (because the command includes a pwd) in the executable window. I need to copy a file from the user's directory onto the server without allowing user access to the server or displaying the pwd. Figured having a .exe that does this is the easiest way.
Ex:
system("FILETRANSFER_SW.exe -pw helloWORLD11!# C:/temp.txt F:/tempfolder/")
But the executable window is showing this command, hence defeating the purpose of trying to hide the password.
I tried issuing
system("#echo OFF")
at the beginning of the program but that does not suppress the following commands, they still show up in the executable window.
Any suggestions?
Thanks...
The command line of running processes is considered public information in most operating systems.
Therefore it is a very bad idea to pass passwords on the command line.
There are two common workarounds to this problem, both of which require the support of the executable being called:
instead of passing the username/password on the command line, pass the name of a file containing the username/password
re-set the command line of the running process from within the called executable.
The first solution is easy and universally possible, the second one has a race condition and is harder to implement, because there's no cross-platform way to do it (on some OSes, changing argv will help).
I'm assuming from your command line that you're using Windows. If it doesn't need to be portable I would suggest you use the CreateProcess() API instead of calling system().
The CreateProcess() API can take a command-line and you can set up the STARTUP_INFORMATION parameter to hide the new process window (wShowWindow = SW_HIDE).
The command line will be hidden from the casual user, but as others have pointed out, it's not that hard to retrieve. Since you are creating a new process, I would suggest writing the sensitive data to that process' standard input. That way the process can just read it and proceed normally.
Using CreateProcess() API will hide the sensitive data from a user, but a power user can easily get the command line associated with the process using a free utilty, e.g. Process Explorer
Another solution is to send the password between your programs, encrypted with something like 3DES, or AES.
You could use a pipe to comunicate between both programs, and don't use the command line at all.
But any of this schemes is not really secure they can be circumvent rather easily. If you want more security you should use some kind of challenge-response protocol with the server.