Re: [Boost-users] Boost.Process and STARTUPINFOEX

Subject: Re: [Boost-users] Boost.Process and STARTUPINFOEX
From: Nat Linden (nat_at_[hidden])
Date: 2013-01-21 12:09:19

On Mon, Jan 21, 2013 at 9:29 AM, Diederick C. Niehorster
<dcnieho_at_[hidden]> wrote:

> If you google the term,
> you get this:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms686329(v=vs.85).aspx
>
> Minimum version - windows vista.
>
> Whether you're out of luck or not I don't know, don't use this lib
> otherwise..

In my opinion, the key issue is about passing file handles to the
child process. If you are content to pass no file handles, then a
plain STARTUPINFO structure should suffice, along with bInheritHandles
= FALSE. Although I still intend to delve more deeply into
Boost.Process, I don't yet know whether you can configure the present
library source to use STARTUPINFO instead of STARTUPINFOEX.

But if you desire to pass *any* file handles to the child process,
e.g. stdin, stdout, stderr (that is, bInheritHandles = TRUE), you're
potentially opening a can of worms. If you must restrict yourself to
the functionality present in Windows XP (STARTUPINFO rather than
STARTUPINFOEX), you end up passing an uncontrolled set of handles to
the child process. You would have to be fully aware of every file
handle opened anywhere in your process -- including every third-party
library. This is only possible for a completely trivial process.

For example, our application innocently opened a file with
std::ofstream. While it was open, a completely different module
launched a child process that persists until the end of the parent
process. Some time later the original code closed the ofstream and
tried to remove it -- but could not because the file handle was held
open by the child process! The child process was completely ignorant
of the open file handle. It did not want it and made no use of it, but
received it anyway.

Only the STARTUPINFOEX facility permits specifically constraining the
set of open file handles passed to a child process. Frankly I'm
distressed that this level of control was only introduced after
Windows XP.

I am in favor of Boost.Process using "correct" (STARTUPINFOEX)
file-handle-passing semantics by default. The documentation may
already mention the need to #define _WIN32_WINNT to 0x0600 or greater;
again I still need to catch up with it.

For those who must still target Windows XP, I would want to be able to
configure Boost.Process to use the earlier, buggy STARTUPINFO
machinery, but I would want the documentation to call out the gotchas.
If you pass NO file handles, it's fine. If you only launch
short-running child processes, it's probably fine. But using only
STARTUPINFO, the library (the OS!) cannot defend you against
undesirable side effects if you pass any file handles to a child
process that runs for nontrivial real time.