On 25 Apr 2014 at 10:02, stgates wrote:
I work for Microsoft and we´ve been taking a look at making a some of the libraries in Boost work in the Windows 8 store and phone 8 runtime environment (WinRT).
Having recently been dismissed from a similar multinational where publicly contributing to open source except through your wife's name is career damaging/destroying, I firstly want to thank you personally for taking the time, effort and risk in the above.
The main issue is use of Win32 desktop APIs that are banned in WinRT. The fixes generally involve updating to a newer non-banned version, like CreateEvent to CreateEventEx, or replace areas that call banned APIs using ifdef macro techniques.
As a general rule, open source maintainers really hate #ifdef far more than they are hated in big corporations. A patch containing any #ifdef's not absolutely and uncategorically necessary would be rightly rejected. By unnecessary, I mean, for example, if you added a separate CreateEventEx implementation just for WinRT when clearly the Win32 implementation could be modified to work on both Win32 and WinRT.
Similar to what already exists in some places of Boost when targeting different platforms or operating system versions. Files which do not use any banned APIs are largely unaffected. So far we´ve made the thread, chrono, system, and date_time libraries work in WinRT. To facilitate building and testing, changes are also required to the build and test libraries. Listed at the end of this message is a summary of the major changes made.
You are not filling me with optimism unfortunately (though I haven't examined your source code, so I could be wrong). WinRT is essentially a reduced subset of Win32, just as WinCE was. It is not a separate target and should not be treated as one. Rather, it's a target dialect, much as FreeBSD and Linux are dialects of Unix.
I´m unfamiliar with the process for contributing back to Boost and would like to know what is the best way to work, to contributing back these changes to each of the individual libraries?
It's maintainer led, so basically one person controls each library delegating to others where appropriate, and it's up to their personal whims. Be aware some maintainers will refuse to compile code on Windows as it "isn't POSIX", so be prepared to do much extra donkey work for Windows for some libraries. Some maintainers take three to six months to get round to replying to you, so also be aware of that. You'll get far further and quicker if you can demonstrate that your changes cause no regressions and add very little new complexity, and it helps to include soak tests. Also, you'll need to write a ton of documentation for anything added. See below for an idea to generate some goodwill.
To support deciding which Windows API to target I added a new feature <windows-api> with values desktop, store, and phone. When utilizing the Visual Studio 2012 on Windows 8 or later the store and phone options are available, otherwise desktop is the default. Most of the changes in msvc.jam are to deal with selecting the correct vcvars setup script since with phone it is in a different location. I also added ARM support to the msvc toolset. For libraries which support the new Windows Runtime they now produce both the desktop and store binaries by default. This is done by calling the supported-windows-api rule I added in toolset.msvc which is called in the default-build section of each library´s Jamfile to indicate if targeting WinRT is supported. When building for the Windows 8 store or phone a new macro is now defined BOOST_WINAPI_FAMILY, set with the same value as WINAPI_FAMILY. This is then used in the individual Boost libraries to detect if targeting the new Windows Runtime and avoid certain banned APIs.
Sounds excellent. Boost might approach Android-level functionality on WinRT soon if you keep at it like this. FYI, Boost only has a partially functioning port on Android, basically the bits people needed. In particular, Boost isn't regularly regression tested on Android, so stuff does break more frequently than is helpful. If you can supply a feed of regular Boost regression testing for WinRT (especially if on ARM as well), I think you'd get lots of very positive goodwill in return here. This basically involves setting up a local machine testing per commit which sends the XML with the results to one of Boost's servers. If this is an option, do say so and I'm sure the relevant people will chime in. Regarding the considerable work beyond mere coding required to get a platform support patchset into Boost, a lot of it is work which won't have an approved business case in a company like Microsoft i.e. you aren't supposed to work on it during office hours. Also, if it was anything like my former employer, the business processes aren't well adapted to work items stretching over six months where the work is done in unpredictable bursts (i.e. when everyone involved has a shared window of free time) which will throw you off your "proper" work. After my recent multinational corporate adventure I have since returned to employment in open source, and while nothing like as well paid as working for the majors, I have to admit the money differential isn't currently bothering me in the slightest because everyone I work with "gets it". They also read their email incidentally, something I've found is too uncommon in corporations where if it ain't in the top two lines and has the right subject, forget about it. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/