Not having dup2 is annoying though. With win32 you cannot make the change automatically propagate to child processes. You need to specify the handles in every CreateProcess call. Sometimes that happens deep inside a library and you can't modify it.
Assuming you know exactly what buffering everything in the process does. But you just mentioned a case of something that "happens deep inside a library".
I absolutely agree that dup2 should be possible; I only mentioned that replacing a "live" file descriptor isn't necessarily simple (unless your program is currently quiesced).
> But you just mentioned a case of something that "happens deep inside a library".
Well, if we're talking C, if you have the same libc as all your libraries [not true on Win32, but true on recent popular Unix-like OSs], you should be able to safely fflush and dup2, then call into any applicable library code ...
But anyway, I think the difficulties with it are much larger in the kernel than in user land.
I could very well imagine a scenario in which supporting dup2(2) required more locking and reference counting of kernel objects. I.e. any kernel thread currently operating against the data structure backing a descriptor must have that operation survive a dup2.
Not having dup2 is annoying though. With win32 you cannot make the change automatically propagate to child processes. You need to specify the handles in every CreateProcess call. Sometimes that happens deep inside a library and you can't modify it.