>> Child processes that use such C run-time functions as printf() and
>> fprintf() can behave poorly when redirected. The C run-time functions
>> maintain separate IO buffers. When redirected, these buffers might not
>> be flushed immediately after each IO call. As a result, the output to
>> the redirection pipe of a printf() call or the input from a getch()
>> call is not flushed immediately and delays, sometimes-infinite delays
>> occur. This problem is avoided if the child process flushes the IO
>> buffers after each call to a C run-time IO function. Only the child
>> process can flush its C run-time IO buffers. A process can flush its C
>> run-time IO buffers by calling the fflush() function.
>>
>> I face this problem if I use GBAK to perform a lengthy backup and
>> restore operation via this approach. The GUI application always stop
>> half way in unforeseen point although it will finish the operation at
>> last. There isn't any response from the ReadFile when it hang some
>> where. I suspect it was due the GBAK utility written didn't perform
>> flush as described.

> What is your question? :-)

Did you ever try to capture the output of GBAK and display it in your
GUI application? There is a delay: everytime ReadFile returns with
data, not all of the output of GBAK is there. Only when the whole
process is done, there is all the output. In rare cases, the whole
thing seems to stop or hang.

The question seems to be: do others also have this problem? Is there
anything one can do to overcome it? Is there anything that can be done
in the GBAK (GFIX/GSEC/etc) code to cure it? (Like flushing the
output).

> Can't you use a threaded approach to avoid the GUI application
> to appear hanging?

There's no need: from my application's perspective, GBAK is not only
another thread, but an entirely different process, that runs in
parallel to my application.

Best Regards

Stefan Heymann

--
Stefan Heymann, Tübingen, Germany