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

Subject: [boost] [winrt support] Adding support for Windows 8 store/phone to Boost libraries
From: stgates (stgates_at_[hidden])
Date: 2014-04-25 13:02:09

Hi,

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). 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. 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. 

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? I see the documentation for
working with the git submodules
(https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq). Right now
the changes for each library are in a forked repository on a new branch
called ‘winrt’ from the ‘develop’ branch. For example the changes we've made
for the chrono library can be located here:
https://github.com/MSOpenTech/chrono/tree/winrt.

Is the best way to proceed, or should I to just initiate a pull request to
the develop branch on each of the individual libraries?

Thanks,
Steve

Boost Build

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.

To handle running tests against WinRT in an automated fashion that
integrates well into the Boost workflow of running tests as part of the
build, if windows-api is set to store, the test and all its binary
dependencies need to have the APPCONTAINER requirement stripped. This then
allows execution outside of the sandboxed Windows store environment. To do
this all dependent dlls are copied into the tests executable’s folder, if
using <link>shared. This is necessary to avoid modifying the APPCONTAINER
flag on the actual product binaries. Just let me know if this needs more
explanation, I’ll be glad to go into more detail if necessary. With this
change the tests for Windows store run just like the existing Windows tests.
I also added a new feature to control whether or not test binaries are
actually executed, disable-test-execution. This is used to avoid running the
ARM tests when building since Visual Studio 2012 doesn’t install on ARM
devices. All these changes are in testing.msvc.

Chrono

The GetProcessTimes and GetThreadTimes functions doesn’t exist for WinRT and
there are no replacements so the thread_clock and process user, system, and
cpu clock features are disabled. Only process_real_cpu_clock is supported.

Thread

For the thread library most of the changes are around the fact that there is
no way to directly create a thread in WinRT. To work around this I
implemented the boost::thread class itself on top of std::thread. This
actually leads to pretty clean code, much cleaner than directly targeting
the WRL thread pool like in the C runtime. Other changes include moving from
TLS to FLS and basic banned API replacements like WaitForSingleObjectEx for
WaitForSingleObject. In general where it makes sense updates were made to
utilize new APIs on platforms when available.

Test

For the Boost test library I added a new macro for turning on/off debugging
support (BOOST_TEST_HAS_DEBUG_SUPPORT). WinRT doesn’t support creating
processes so attaching a debugger to execution like this is disabled. There
also are no APIs for accessing registry keys, so this feature has been
disabled as well.

--
View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-8-store-phone-to-Boost-libraries-tp4661713.html
Sent from the Boost - Dev mailing list archive at Nabble.com.