Using the Console Like MSDEV

Environment: VC6 SP4, NT4 SP6, 2000 SP1

Probably everybody who reads this article is familiar with msdev.exe. We know that if we type "msdev /?", we get usage information on the console. However, if we type "msdev", the IDE comes up. This dual behavior is achieved through an additional executable, called In this article you can find a fairly generic solution for adding the same capability to any kind of non-console program.

Click here for larger image

In the demo there are two executables, and tester.exe. By placing them into the same directory and running from the command line, tester.exe will be spawned. Tester.exe is a simple MFC SDI application which has the extra capability of being able to read/write from/to standard output/error/input of by using either cin/cout/cerr or printf/scanf.

To use this functionality in your own non-console application, you have to
- call one function (see below) before making any calls that use the console and
- you will need to rename to "".

Then, when you type NAME_OF_YOUR_EXE, the .com executable will start, create the framework needed to enable its console for the .exe and spawn the process. Here is how it works: first creates the commandline that will be used to spawn the .exe process. It is done by replacing the .com extension with .exe and appending the rest of the command line arguments. Then, using the constructed command line, the new process is spawned in suspended mode. Then we create three named pipes, one for stdin, one for stdout and one for stderr. Three thread functions will serve as handlers on each pipe. The example below shows what the stdout pipe handler does:

OutPipeTh(void* param)
 TCHAR buffer[1024];
 DWORD count = 0;

 ConnectNamedPipe(coutPipe, NULL);

 while(ReadFile(coutPipe, buffer, 1024, &count, NULL))
  buffer[count] = 0;
  cout << buffer << flush;
These three thread functions are spawned in their own thread and then the suspended process is resumed. While the .exe application is running, the communication between the .com and .exe on the .com side is handled by these three threads. When we detect that the .exe application exited, we close the named pipes a return the exit code that we retrived from .exe process.

The .exe program needs to call a function at the beginning of its execution in order to establish connection with the pipes created by the .com application. The function is as follows:

BOOL InitializeDualMode(BOOL initMode)
 TCHAR szOutputPipeName[256];
 TCHAR szInputPipeName[256];
 TCHAR szErrorPipeName[256];

 // construct named pipe names
 _stprintf( szOutputPipeName, 
 GetCurrentProcessId() );

 _stprintf( szInputPipeName, 
 GetCurrentProcessId() );

 _stprintf( szErrorPipeName, 
 GetCurrentProcessId() );

 // attach named pipes to stdin/stdout/stderr
 rc = _tfreopen( szOutputPipeName, "a", stdout ) != NULL &&
 _tfreopen( szInputPipeName, "r", stdin ) != NULL &&
 _tfreopen( szErrorPipeName, "a", stderr ) != NULL;

 // if unsuccessful, i.e. no console was available
 // and initmode specifiec that we need to create one
 // we do so
 if ( !rc && initMode)
  rc = AllocConsole();
  if (rc)
  rc = _tfreopen( _T("CONOUT$"), "a", stdout ) != NULL &&
  _tfreopen( _T("CONIN$"), "r", stdin ) != NULL &&
  _tfreopen( _T("CONERR$"), "a", stderr ) != NULL; 

 // synchronize iostreams with standard io
 if ( rc )

 return rc;
As seen in the function, connecting stdio to pipes is painless. One thing to remember is that the pipes in the .com program have to be created with pipemode set to PIPE_TYPE_BYTE | PIPE_READMODE_BYTE. Trting to use PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE will result in communication failure, because the _tfreopen() will try to connect to the pipes in BYTE mode.


Thanks to Zoltan Csizmadia for the idea!


Download source - 20 Kb
Download executables - 10 Kb


  • Minimeze console

    Posted by Legacy on 09/26/2003 12:00am

    Originally posted by: Marco

    how can i minimize console after "AllocConsole()" command?


  • How can I Display string?

    Posted by Legacy on 09/28/2001 12:00am

    Originally posted by: LinX

    How can I display strings, at the same time, other thread is reading characters from keyboard in windows 2000?

  • I wonder...

    Posted by Legacy on 09/12/2001 12:00am

    Originally posted by: River

    the return value of function named _tfreopen is a pointer to FILE not a bool at MSDN. So I wonder why.

  • Capturing STDOUT

    Posted by Legacy on 04/30/2001 12:00am

    Originally posted by: Tony Tobianski

    I'm actually trying to capture STDOUT from a call to a function I don't want to alter. The function runs an interpreted language command. I'm capturing the commands in a CEditView, by using GetLine(). I then want to send this input to the interpreting function. The output commands of the language were written to write to STDOUT. I'd like to capture the output of any output functions and place then on the following line of the CEditView window, without displaying an additional DOS console. Is this possible?

    Your idea, or insight into communication between console and windows may prove very useful! Unfortunately, there is some network/hardware problem and there's 100% loss when trying to download at this time : (

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • As all sorts of data becomes available for storage, analysis and retrieval - so called 'Big Data' - there are potentially huge benefits, but equally huge challenges...
  • The agile organization needs knowledge to act on, quickly and effectively. Though many organizations are clamouring for "Big Data", not nearly as many know what to do with it...
  • Cloud-based integration solutions can be confusing. Adding to the confusion are the multiple ways IT departments can deliver such integration...

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date