Re: [boost] [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Subject: Re: [boost] [winrt support] Adding support for Windows 8 store/phone to Boost libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-04-26 11:31:23

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/