Mimic a shell environment (or terminal env) for a 3rd party program

[JoTo]

Hi DCs,

need your help with a problem i can't solve myself.

I need to "remote control" a 3rd party application from my wxWidgets app. The 3rd party app is a console app, while my wxApp is a windows GUI one.

I wrote a class to start a process and capture stdin, stdout and stderr, so i can receive output from the other app and write (input) to it. My class worked fine with many other 3rd party apps.

With that app it works too, but this app seems using output buffering. So when i wait for the welcome message of the other app, i don't receive it. But i need to send some commands to it after the welcome message showed up.

When i just wait a period of time and then send some input while holding fingers crossed (hoping that the other app is already ready to receive), then suddenly i receive a whole bunch of information from the other app. So capturing works fine, but i need more "realtime" control.

So that is not a good solution too.

If i start that app in a normal dos-shell environment, the welcome message is output immediately (what i want to happen when started from within my app as well).

Seems that app recognize if it is started in terminal mode or with captured streams.

I have no access to the sourcecode of the 3rd party app. So i'm not able to inject some "flush" commands in the code.

Anyone has an idea how i can mimic an "interactive terminal mode" to this other app? Or someone knows a wrapper app where i can throw in my commandline and that will mimic it the right way and pass-through the in/output to and from my app to the other app?

Any hint very appreciated. Thank you in advance very much!

Greetings
JoTo

[Ath]

Doesn't it have a command-line parameter to force direct update? Might be it's 'poking' directly into graphical memory, and the output is delayed/buffered by windows before being channeled back to your app. Maybe an update-rate can be set/increased somewhere? (Just some blind hints, sorry)

[JoTo]

Hi Ath,

thanks for your suggestion. But sadly there is no commandline options for that app.

It uses a kind of menu structure. Meaning you start it without any commandline options, then a text menu is displayed where you can select with numbers what do you want to do.

That is why i need to communicate with that process. I have to wait till the menu is there and then send the number i want to make the other app do what i want.

And if its like you suggest, that windows is the "bad guy" who buffers, i have no idea how to change that behaviour as well. Any hint here what i can check to be sure, who's the one i need to kick in *ss? And how i can do this?

Happy new year
JoTo

[f0dder]

What is the 3rd-party program? Is it something that's publicly available so we could take a look at it?

How are you setting up the stdin/out redirecting, and how are you doing your reads/writes?

Probably won't matter, though, since the problem is 99% likely to be the child app checking whether the file handle is FILE_TYPE_CHAR or not - and using buffering if it isn't. Console handles are FILE_TYPE_CHAR, while pipe handles are FILE_TYPE_PIPE... this is standard libc behavior when setting up the FILE* stdin/stdout handles.

If the stuff can't be fixed otherwise, it might be possible to do a bit of detours/easyhook magic

[JoTo]

Hi fodder,

thank you also for your reply.

1. Sorry the 3rd party app is a kind of "driver" for an x-ray generator. So i think its not publicity available for all. I am able to send you that program if you offer to look at it. But i first have to talk to my teammate that have that problem actually if this makes sense in any way, as i'm not sure if the 3rd party app is working without a connected x-ray generator anyway.

2. The capturing is done with the wxWidgets framerwork and the execute function of the wxProcess class. I have not yet feeled the need to dig under the hood, as i have no idea anyway what to look for.

3. Aha, the information about libc behaviour and the different stream types is new to me. I'll forward that information to my teammate and see if we can "turn the knob" a bit here.

Thank you and happy new year
JoTo