Interaction with an application running in CMD

Interaction with an application running in CMD

• Afraz

  As evidenced by the variated answers you probably need to be more specific on what you're trying to do.  Are you spawning the executable and wishing to send it keyboard input and get its output   If that is the case, you need to use piping (a convoluted game of musical chairs with stdin and stdout, IMO, but it's the standard approach.)  I'd study the example for _pipe in MSDN to see if this works.

  http://msdn2.microsoft.com/en-us/library/edze9h7e.aspx

   

  
  

• KitGreen

  Kumarvk said:
  

  Actually, I am using Microsoft Visual C++ 2003 edition. I am using ShellExecute() to execute other application which runs in CMD.exe.I will try all the options available. But if you have something specific to tell, please do so.

  AND
  
  Does it include Micorsoft Visual C++ also
  
  
  Looks like you want to call a console application from another one and display or use the output of that application in the calling console. If that is all you want you don’t need any Intercrosses communication stuff. You need intercrosses communication only when two applications are interacting in a more co-coordinated and continuous manner. For now, you can try the following code.
  
  /*Caller.cpp
  * This program calls Called.exe and passes 6 arguments and displays the return value
  */
  #include <iostream>
  
  using namespace std;
  
  int main(int argc, char* argv[])
  {
  int i = system("Called.exe a b c d e f"); // calls the program Called.exe from local folder
  cout<<"Return Value = "<<i;
  return 0;
  }
  
  /************************************************************/
  
  /* Called.cpp
  *This program is called by Caller.exe and returns the number of arguments as return value
  */
  
  #include <iostream>
  
  using namespace std;
  
  int main(int argc, char *argv[])
  {
  for(int i=1; i<argc; i++)
  cout<<argv<<" ";  //outputting the arguments
  cout<<endl;
  return argc; //returns the number of arguments
  }
  
  
  /***************************************************************/
  
  Let me know if this is what you are looking for.

  
  
  

• Victor Hadianto

  You might be confusing things.

  Piping is used when application A (we don't care where the input is coming from, or whether it was run from cmd.exe) runs ("spawns") application B and feeds it input by writing to a file descriptor (one end of the pipe). From application B's perspective, it is getting its input via stdin, as if the user were typing it via the command line. Application B still writes to stdout, and application A can read it from the other end of the pipe, also a file descriptor.

  The example in the link I gave may be a bit misleading because it's using the same piece of code to play the roles of application A and B. Most piping scenarios involve simulating keyboard input for an existing application.

  Brian

  
  

• hwiz

  If you are not programming in any of the .NET languages

  Does it include Micorsoft Visual C++ also

  
  
  

• BlueMikey

  Looks like you want to call a console application from another one and display or use the output of that application in the calling console.

  No that's not my objective. The Called program will run in a different console and it can run for infinite time unless proper command is given to it. This can be achcived either using ShellExecute() or system() methods as mentioned by you.

  Now, my application, which may not be console based application, will communicate with that application in such a way that I can provide input to that application, which may be commands to to the other application, and at the same time I need to capture the output or results from the other application so that I can show them in my application.

  I hope my problem is clear now. I think that somehow i need to use STDIN, STOUT and STDERR for this kind of communication.

  
  
  

• Paritosh Mhaisekar

  You can also use named pipes, shared memory (memory mapped files) or any methode that allows IPC!
  
  

• Scott_P

  From application B's perspective, it is getting its input via stdin, as if the user were typing it via the command line. Application B still writes to stdout, and application A can read it from the other end of the pipe, also a file descriptor.

  I think I got this idea. And the way you have mentioned it, it's exactly the same thing I want to do. I will try this example for my purpose and will let you know.

  Most piping scenarios involve simulating keyboard input for an existing application.

  May you provide me any link for this kind of example

  
  
  

• MariaF

  Hi,

  I ma sorry for late reply. Actually, I am using Microsoft Visual C++ 2003 edition. I am using ShellExecute() to execute other application which runs in CMD.exe.

  I will try all the options available. But if you have something specific to tell, please do so.

  Thanks,

  
  
  

• MariamCR

  The only link i've relied on is the one I've already given. The main difference is that you would spawn another executable, not a copy of itself (the part that makes this a non-typical scenario, because you shouldn't of interprocess communication against binaries whose source code that's under your control!)
  

• Eric Brinkerink

  yes that's what I want to do!! I will give input to my application using the keyboard, and it will actually be executed by another application which is running in CMD.exe in the background. And then I should be able to catch the output from that application in my own application.

  One restriction is that I won't be able to make any change in the applcation running in CMD.exe.

  Will piping be useful for that

  Thanks,

  
  
  

• PeterLlwr

  You can use RPC, named pipes or sockets, to name a few.

  For RPC, see http://windowssdk.msdn.microsoft.com/en-us/library/ms719418.aspx.

  For general information about inter process communication, see http://windowssdk.msdn.microsoft.com/en-us/library/ms690478.aspx.

  
  
  

• Kent Boogaart

  You can use the RedirectStandardOutput and RedirectStandardInput properties to obtain the output of the console program as well as send input. There are several restrictions on redirecting the standard output stream:
  - The app has to use standard "DOS" output, not use the Bios or write directly to the video buffer. If the output is the standard light-gray on black background, you'll stand a chance.
  - The output is buffered when it is redirected. You won't get output from the program until the buffer is filled (2048 characters) or the program exits.
  
  
  
  

• ideal24293

  If you are not programming in any of the .NET languages Microsoft's Component Object Model is a good way for the transferring information between different applications.
  A few good articles are

  http://www.codeproject.com/com/comintro.asp

  http://www.codeproject.com/com/comintro2.asp

  
  But there are various other ways for Inter Process communication in Microsoft Windows. You'll find a good over view and can make an intelligent choice from here:
  
  http://en.wikipedia.org/wiki/Interprocess_communication
  

  Also please  whic compiler(s) you are using for your programs.
  
  
  
  
  
  
• Interaction with an application running in CMD