A solution that will take a decent amount of programming but can be done:
Write a separate program that intercepts the screen output of the program and sends it to your program somehow. Run this program in the hidden window, it turns around and runs the app and sends the output to your program.
At least parts of the interceptor are almost certainly going to have to be in assembly.
Edit: Redirecting stdout won't do it even if the program only writes to it--he wants the output displayed.
There are three things that might need to be intercepted:
Int 21h filesystem writes. These are the things that could be intercepted by redirecting stdout. Beware that some programs may write to a different handle number that actually represents the stdout file--look up the handle that's being written to in the program's handle table and compare it to the stdout entry (IIRC the second entry)--if they match it's actually screen output.
The second level is IIRC int 10h. There are several sub-calls that must be intercepted.
Finally, a program may do direct screen writes. Intercepting these would be a major pain, I wouldn't even consider trying it (you would have to basically rewrite the dos box.) Instead, frequently compare the screen memory with a saved copy looking for changes.
In all three cases at least parts of the routine are going to have to be written in assembly.
I have done the first, played a bit with the second but then I found that I could get by without doing it. I've never attempted the third.