Thanks for all your responses. It's much appreciated.
As to the non-windows apps I'm talking about, and trying to capture
its' data, I'm refering to those apps that were actually created with
C++ but with command-line in mind.
I'm still not going to give up hope. As far as google, I've ben there
and done it, and am STILL LOL doing it. I also found a link, at
the exchange LINK you provided. I didn't quite understand the concept
that was given. I too, abandoned that one. However, I'm still looking.
Keep up with the suggestions though.
: : @ Perran,
: : :: There might be a better way, but I wonder if you could pull it out of textmode video buffer?
: : Good one Perran !
: : I've ben thinking about this for months, but didn't act upon it
: : cause I had a bunch of other things going on and still do. But...
: : I remember my good old DOS days, $b800 rings a bell ??????
: Sorry to burst the bubble, but it's not that simple
: Your GUI program with the TMemo (or whatever) is going to need to create a named pipe, and then using CreateProcess() execute the DOS (or Win32 console) program redirecting its output (stdout) to the pipe. That way the text being written to stdout by the program will not go to the screen like normal, and instead will go to the pipe that your GUI program can read from.
: I experimented with this about a year ago, but after learning of certain limitations I gave up and deleted my code, so I dont have any samples to give to you. But I learned how to do it through searching on Google, and through Experts Exchange (www.experts-exchange.com) so you might want to try that.
: Incidentally, the limitation I found was that any program written in Pascal using the CRT unit cannot have it's output captured. Since the programs I wanted to capture the output of all fell into this category, that's why I abandoned my efforts.