As mentioned in one of the replies above, if the C program does not flush its stdout, its output will be buffered until the pipe connection has accumulated (I think) 8 KB or so of data (or else has finished its work), before the downstream process will get to see any data.

(When output goes directly to the terminal window, stdout does not get buffered -- the buffering applies when the output is going to a pipe or file. You could test this out by running your C program at the command line like this:

  ./myC.exe 10 10 1 abc > test.out
[download]

Then use another window to watch the size of the "test.out" file. If the C code is not flushing stdout at each printf statement, the file won't grow until the program has written 8K of data, or until it finishes, whichever comes first.)

And apart from the output buffering in the C program, if the strings being printed to stdout do not end in a line-feed, the perl script might still not print anything until it detects and EOF on the pipe. The default input record separator in perl is "\n" (with windows CRLF handled as needed in the default windows/perl setup) -- (update:) perl will keep reading into $_ on the first iteration of  while (<>) until it gets a line-feed or EOF.

When people do those kinds of progress-report string outputs, they often terminate each print with "\r", so that each iteration overwrites the previous string. If your C program is doing that, have your perl script use "\r" as the input record separator (the perl-internal global variable "$/") -- update: in other words, do this:  $/ = "\r";

And sometimes, the C code has been written so that the status output has no termination at all -- each iteration simply appends onto one line. If your C program is set up that way and you want to keep that "feature", you'll want to modify the C code to at least use some distinctive character (or string) at the end of each report iteration, so the perl script can use that character (or string) as the input record separator.