On Mon, Jan 21, 2013 at 9:29 AM, Diederick C. Niehorster <dcnieho@gmail.com> wrote:

If you google the term, you get this:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686329(v=vs.85).as...

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.