Create a GUI for a console application !?

I hope I understand your issue.
Suppose the name of your console application is TestConsole.exeand it gives the output "ABCDEFGHIJKLM" on executing via command prompt.
Now You need to execute this TestConsole.exe from an application that has a GUI and get the result in your GUI application. If this is the situation then write belwo code in your GUI app

char   pchBuffer[128];
FILE   *pPipe;
if( (pPipe = _popen( "TestConsole", "rt" )) != NULL)
{
    while(fgets(pchBuffer, 128, pPipe))
    {
        // pchBuffer will have the output of console application
        // so write here the code to display this in your edit control
        // or do whatever you want
    }
}

I think you are looking for this,

C++/VB - MFC: concurrent display of console output on GUI edit box.

Please see it[^] :)

Your parent process could be covered by a GUI application
and its ReadFromPipe(..) function could transfer the child's text into a box.

There is no such thing as "command line application". This is because absolutely any application can get whatever appears in the command line and analyze it. If does not really related to threads or UI.

First of all, in C/C++ applications, you can use entry points with different signatures (for, in fact, please see the link below). Two of them accept command line parameters. When such signatures are used, the runtime system takes the command line argument which OS passes to the application, parse them properly and passes as arguments of the entry point function. Here they are:

int main(int argc, char **argv)
int main(int argc, char *argv[])

You should use this data in your application, according to the application semantics you design.

For more detail, please see:
http://en.wikipedia.org/wiki/Main_function#C_and_C.2B.2B[^].

As to the threads, you should use the regular precautions when passing data between threads. You need to know it anyway; there is nothing specific to passing command line arguments.

[EDIT: an answer after OP clarification of the question]

This is a totally different story. You should not call it "command line application". This is probably a "console application". You can solve this problem.

You can run the console application using System.Diagnostics.Process.Run with redirected streams StandardInput, StandardOutput and, just in case, StandardError. Please see:
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx[^].

You can find code samples with redirection here:
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardinput.aspx[^],
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardoutput.aspx[^].

You don't have to read the output of your console application to the end. You could read it line by line (or some other portion, depending on application) and process it on the fly. This is a blocking call, it will keep a thread in a wait state when data from the console application is not ready. Therefore, you should do it in a separate thread. You also should wait for the process termination (Process.WaitForExit) in a separate thread. It majorly depends on what kind of console application is that. If could be prolonged process, so you will need to feed it data permanently until you decide to terminate it, and process the data coming form this child process on the fly. This would be a kind of simulation of the interactive user by your UI process.

If this is a short-leaving process and if you want to run the whole process repeatedly, this is much simpler scenario. If this thing in really fast, you don't even need to use separate thread (but in general case this is always better). You might not even feed data to it through StandardInput, because in such application it is usually possible to pass all data in the very beginning in a command line; in other words, such process can be used non-interactively.

—SA