Hi, I want to discuss here of how transparent would be the user code to be able to use non portable extension with the current interface. The way extensions are provided means that a user needs to use the BOOST_POSIX_API, BOOST_WINDOWS_API in his own code when he uses an extension. Could the documentation include some explicitly examples. The interface of the setup callback is different so the user will need to define two possible setup functions. #if defined(BOOST_POSIX_API) void setup() { ... } #elif defined(BOOST_WINDOWS_API) void setup(STARTUPINFOA &sainfo) { ... } #endif Note that these setup functions are called on a different context either on the child either on the parent process, but both will be assigned to the same context field. Any setting of the ctx.streams with fd >2 should be protected ctx.streams[3] = ... While the preceding code doesn't have any sens under WINDOWS, the library don't provide an interface that forbids it, but the current implementation just ignore it. I'm not sure if this is good in this case as the application could not work in the same way in POSIX or WINDOWS systems. If the class stream_id I proposed in this thread is used as domain of the map, the code will not compile as a stream_id cannot be constructed from fd>2 on WINDOWS. The opposite applies to behaviors whose constructor have stream_type parameter. These constructors are available only for POSIX, but I don't think adding them will change the perception of the user has of his application. Couldn't the behaviors provide a uniform interface for these constructors? BTW all the constructor taking a stream_type as parameter are not documented. Instead of just defining them for POSIX #if defined(BOOST_POSIX_API) pipe() : stype_(unknown_stream) { } pipe(stream_type stype) : stype_(stype) { } #endif You can add the respective constructors for WINDOWS, even if the parameter is completely ignored. #if defined(BOOST_WINDOWS_API) pipe() { } pipe(stream_type /*stype*/) { } #endif The same applies to all the behaviors using stream_type. Could a table of extension be included on the documentation? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Subject-Formal-Review-of-Proposed-Boost-P... Sent from the Boost - Dev mailing list archive at Nabble.com.