I use GBAK.EXE to perform backup and restore operation of Firebird
database in my GUI application design. The reason I use GBAK instead
of firebird service manager is I can perform remote backup and restore
operation via TCP/IP network without transferring the backup file to
firebird server first.

However, as GBAK is a console utility, It display the output to STDOUT
or STDERR. There is no easy way to capture the output while the
console process is running. We need to invoke windows API to perform
the task. We may use CreatePipe and CreateProcess to redirect the
STDxxx handles and use ReadFile to capture the output in our GUI
application.

There is a drawback using windows native API aproach. As stated in
microsoft knowledge base (http://support.microsoft.com/kb/190351):

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.