> This must be done before the program runs

I have no experience with VMS, but I always thought a similar limitation was weird on Windows. On Unix you can replace an active descriptor with dup2(2). On windows, whatever HANDLEs you have at CreateProcess you are stuck with forever. You can replace the CRT's integer descriptor or SetStdHandle, maybe they have freopen these days too, but these are usernode abstractions. Sometimes I would like to swap the kernel structure backing a HANDLE after it's created.

You do have to take care if you're replacing a handle underneath an active program even with dup2, though. The file descriptor replacement is atomic, but higher-level code in the process (such as struct FILE in libc, or similar in other languages) may have buffers that it hasn't finished flushing yet.

True, so you fflush before 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.

> True, so you fflush before dup2.

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.

freopen() has been around and working as intended on Win32 for ages. And this works for all userspace in the same process (i.e. it's not just FILE* that gets redirected, but everything going to stdout regardless of how it gets there). So I'm not sure why the kernel side of it would matter?

dup2() is there as well: https://docs.microsoft.com/en-us/cpp/c-runtime-library/refer...

Unix has had IO redirection longer than VMS.