Howdy peeps, this was originally going to be a private email to module author tye

I would've just replied to tell you to post it someplace like here. I hate the relative waste of my time in answering a question in a way that it can only ever benefit a single person. And it is ludicrous to assume that I am the only person on Earth capable and willing to (partially) answer a question about a module that I had a hand in writing. (:

As to your question, your original code reacts like this for me:

flags was=1
HANDLE_FLAG_PROTECT_FROM_CLOSE=2
Trying for flags=3
Can't SetHandleInformation: The parameter is incorrect,
stopped at dontClose.pl line 14.
[download]

With minor changes, I can get it to act like it did for you (no complaint but doesn't change anything) or to act like one would expect.

For me, saying that I want to "change" the HANDLE_FLAG_INHERIT value from 1 to 1 (along with changing _PROTECT_FROM_CLOSE from 0 to 1) for one of the STD* handles or a dup(1) of one of them causes the "The parameter is incorrect" error. (This is what your original code does.) Kind of a silly response, sure. But I'd bet money that this is just an undocumented (as near as I can tell) and "varies between versions" behavior of the underlying Windows SetHandleInformation() call.

If I don't specify that I want to "change" the HANDLE_FLAG_INHERIT value (pass in a second argument of 2, not 3) but still use one of the STD* handles (or a dup), then I get the "no complaint but no change" behavior.

If I add an __END__ line and pass in \*DATA to GetOsFHandle() so that I get back a handle to the Perl script (which is an ordinary file), then the flags get updated as desired.

You'll have to find somebody with more knowledge of obscure particulars of the Windows SetHandleInformation() call if you want more than somewhat wild guesses as to why.

I can certainly see it being unsupported to turn off the INHERIT flag on a STD* handle. It seems reasonable to imagine an unfortunate implementation choice that made it illegal to even just try to "keep it on".

I don't have a good guess as to why one isn't permitted to make a STD* handle immune from being closed nor why that prohibition should be silent. It seems even harder to justify such for a dup(1) of a STD* handle. Perhaps this particular impotence applies to all "console" handles? Not that I can think of any guesses as to why that would be.

But maybe somebody here knows more about Windows or can make better guesses or can find better documentation. Or you might have to shop your question to a different audience.

I'm even curious to know why a flag like _PROTECT_FROM_CLOSE was created in the first place. :)