Why do some cmd launched processes block/buffer output when the output is redirected?

Question

Why do some processes started at the command line on my Windows machine block/buffer their entire output if it is redirected and others not?

Example: tracert does not block/buffer output as it is written. If one executes:

tracert ponyoverflow.com > output.txt

...the output.txt file grows over time. This is completely how I would expect things to behave.

But, I'm trying to work with a potential vendor's software product (iSpring SDK, if you must know) and it seems to buffer the complete output until the process has finished. What I find confusing is that when this software is run at the command line the output comes piecemeal, line-by-line, as expected.

Why is there a difference in behavior between calling it with and without output redirection?

Follow up miscellaneous questions:

• Is this common and/or standard in the world of Windows command line programming?
• Is there anything I can do to grab the
• How do I communicate exactly, in Windows programmer parlance, to iSpring folks how I think their software should behave at the command line?

I'm not sure how important it is, but all this experimentation of mine is happening on a 64-bit Windows 7 Home Premium machine.

Answer 1

(The folks at iSpring were much quicker responding to me requests than I could have dreamed. Spot on. Here is their answer to 'why' below.)

Standard output in C++ is buffered by default. The buffer size is about 4KB. The buffer is flushed when the application finishes. Data written to stdout are not buffered when standard output is connected with a console.