2

In Windows, you can create a child process with redirected I/O using anonymous pipes, as described here: Creating a Child Process with Redirected Input and Output MSDN

But, when Stdout is redirected to a non-interactive device like a pipe, it's automatically set to buffered mode. This creates a devastatingly tangled I/O situation. That is, I don't get Stdout's data, until it's manually flushed, or the program terminates. I think, the only elegant solution to this problem is to disable standard I/O buffering at the creation of the child process.[CreateProcess()]

The question is how can I do it? Any example with codes will be very appreciated. (Note: I've searched the Internet, but I can't even get close to the solution.) Thanks!

EDIT: The actual question is, in win32 API how can I disable standard I/O buffering of a child process before creating it using CreateProcess() ?

EDIT-2: I guess I found a pretty hack for this problem. Stdout only full-buffers when file descriptor is not a 'TTY'(Terminal/Console device), if I can somehow make my Pipe a Pseudo-TTY then the problem would be fixed. So, the question is How can I make/set a pipe as a pseudo-TTY in windows? I cannot find any solution in the Internet.

Freyr99
  • 53
  • 5
  • buffered I/O is not "devastatingly tangled", and you can get stdout data without waiting for a "manual" flush or program termination. As soon as the producer fills the buffer, reads in the reader will complete. – William Pursell Oct 19 '17 at 19:20
  • 2
    it depends on how the particular program is written. and this can not be controlled. but i at all never view any standard windows console app (like cmd) which have such problem – RbMm Oct 19 '17 at 19:28
  • 1
    @RbMm, it's a problem with long-running processes that write output intermittently if they use the default full buffering (4 KiB) when writing to a non-character device such as a pipe. In Linux there are workarounds such as using `LD_PRELOAD` via `stdbuf` or a pty via `unbuffer`. In Windows you can use the console to try to emulate a pty, but polling the screen buffer isn't reliable like reading from a pipe. I also saw a suggestion to hook `GetFileType` in the child. – Eryk Sun Oct 19 '17 at 19:56
  • 1
    @eryksun - this, how i say, depend from child implementation - which functions is used for write to stdout – RbMm Oct 19 '17 at 20:04
  • @RbMm, a considerate application should have a command-line option to control the buffering of its output, but in the real world most programs that use C stdio don't even think about this. We're stuck with hacky workarounds such as `stdbuf` or `unbuffer`. – Eryk Sun Oct 19 '17 at 20:16
  • 1
    C/C++ libraries typically buffer STDOUT data in memory before flushing it to the actual console, so there is nothing the launching process can do to change that behavior. – Remy Lebeau Oct 19 '17 at 22:47
  • *in win32 API how can I disable standard I/O buffering* - you can not do this. I/O buffering mean that application write data to memory buffer instead write to file (pipe). so this is absolute unrelated to win api at all. you can not control this behaviour – RbMm Oct 20 '17 at 07:32
  • To address the problem practically (we can't rebuild all applications that just use the CRT defaults) and reliably, Windows needs a built-in pty system -- for which the ConDrv device driver could probably be extended. For now you could try a hacky solution with [winpty](https://github.com/rprichard/winpty), which I've seen mentioned a few times recently, e.g. see the suggestion in [this answer](https://stackoverflow.com/a/46443665/205580). – Eryk Sun Oct 20 '17 at 17:22

0 Answers0