Is there a way to further remove platform dependence in handling the "exit code"?
You mean the WIFEXITED et al macros? We had a status class in previous Boost.Process versions which encapsulated the exit code. However the design of the class was not really cross-platform as member functions like exited() were clearly added for POSIX systems only and didn't make sense on Windows (exited() for example always returned true). Thus the question is what to make platform-independent if a concept doesn't exist on a platform. :-)
A while ago when I was thinking about this same problem, I considered using Windows' debugging mechanism (process creation flag DEBUG_ONLY_THIS_PROCESS) to obtain this information. I don't know if debugging a process will affect its execution in some way, or whether the performance will be substantially impacted, but it might be interesting to see if this approach would work.
* Templating of the char type to support wchar_t. The "wchar_t version" would use the wide versions of Windows functions: CreateProcessW, etc.
The problem is then what to do on POSIX platforms (as there is no wide version of execve() for example)?
While there is no POSIX equivalent of the wide char functions, I was mainly thinking about using the `TCHAR` macro in cross-platform builds. Windows programmers will probably be programming with TCHAR set to `wchar_t`, so if the process creation library supported templating of the char type, then there wouldn't need to be conversion of wide char strings to narrow char strings. Plus, wouldn't there be a problem trying to execute a module on Windows that has a non-Latin character in it?
* The ability to allocate within another process' address space, as well as read/write from/to another process' memory.
I think you are looking for Boost.Interprocess. :-)
I read that the interprocess allocators of Boost.Interprocess require a pre-existing shared memory segment. I was thinking about cross-platform versions of Windows' VirtualAllocEx function<http://msdn.microsoft.com/en-us/library/aa366890.aspx>which allows blocks of memory to be allocated directly within another process' address space, and ReadProcessMemory<http://msdn.microsoft.com/en-us/library/ms680553.aspx>/ WriteProcessMemory <http://msdn.microsoft.com/en-us/library/ms681674.aspx>for accessing the memory.
* Integration with Boost Filesystem
Where would you like to see support? Passing a path object to create_child() for example?
For some reason it looked strange to me that the find_executable_in_pathfunction returned a string rather than a Boost Filesystem path object. It's not that big of a deal, though, because I could construct a path from a string if I really wanted.