Additions III.

[klemens-morgenstern]

Alright, third round. I hope I got all problems

I also put the process_info stuff into the process.hpp

Also, two questions concerning ShowWindow.hpp

• Is the handling of HWND correct in ShowWindow?
• The MSDN describes ShowWindow with int as parameter - is this alright?

Concerning the travis.yml: I'll remove that as soon as you accept this or any subsequent PR; I'd just like to keep it in for the test. If you happen to choose to pull the travis-PR it doesn't matter, since the files are equal.

Travis:

[klemens-morgenstern]

@Lastique Would it fit into the style of the library, to make an alias for the STARTUPINFO_ type. I would make it the following way (though it's C++11):

template<typename CharType> struct startup_info_t;
template<> struct basic_startup_info_t<CHAR_>    { typedef STARTUPINFOA_  type; };
template<> struct basic_startup_info_t<WCHAR_> { typedef STARTUPINFOW_ type; };

template<typename CharType>
using basic_startup_info = typename basic_startup_info_t<CharType>::type;

typedef basic_startup_info<CHAR_>    startup_info;
typedef basic_startup_info<WCHAR_> wstartup_info;

That way it would look like the std-library, i.e. std::string and std::wstring.

[Lastique]

I don't think it would be a good idea. One of the goals of Boost.WinAPI is to be a lightweight and safe replacement for windows.h and not much more than that. Besides, I'm not sure if such type aliasing would be useful. Most Boost libraries will just use one structure (the wide character one is the most logical choice), I don't see a use case where one would want to select the type and related functions like that.

[klemens-morgenstern]

Ok, it might be needed in boost-process, though that's clear atm. I will then choose the class inside this module, not winapi.

[Lastique]

Committed a modified version to develop.

[klemens-morgenstern]

Thank you!