Failures on msvc-8.0, msvc-10.0

[pdimov]

In the course of looking at something else, I saw that building Boost.System fails on msvc-8.0 and msvc-10.0 with:

compile-c-c++ ..\bin.v2\libs\system\build\msvc-10.0\debug\asynch-exceptions-on\threading-multi\error_code.obj
error_code.cpp
C:\Projects\boost-git\boost\boost/system/detail/local_free_on_destruction.hpp(29) : error C2039: 'LocalFree' : is not a member of 'boost::detail::winapi'
C:\Projects\boost-git\boost\boost/system/detail/local_free_on_destruction.hpp(29) : error C3861: 'LocalFree': identifier not found
C:\Projects\boost-git\boost\boost/system/detail/error_code.ipp(426) : error C2039: 'FORMAT_MESSAGE_ALLOCATE_BUFFER_' : is not a member of 'boost::detail::winapi
'
C:\Projects\boost-git\boost\boost/system/detail/error_code.ipp(426) : error C2065: 'FORMAT_MESSAGE_ALLOCATE_BUFFER_' : undeclared identifier

msvc-11.0 and later work.

[Lastique]

I believe, this is caused by boostorg/predef#57. I'm working on an update for Boost.WinAPI to accommodate that change, but due to the problem with Boost.Thread (boostorg/thread#160) testing might be difficult.

[pdimov]

The Thread problem should be fixed now.

[jeking3]

@pdimov you can work around it temporarily, locally, with the changes from #59, if you want to make local progress.

[Lastique]

@jeking3 No, that fix is incomplete.

[pdimov]

Makes no sense to me; when BOOST_PLAT_WINDOWS_UWP is 0 all BOOST_WINAPI_PARTITION are made 1? How is this correct?

[Lastique]

The idea is that on older Windows SDKs that have no support for API families WinAPI is supposed to provide all APIs, sans the ones not available in the target Windows version. This is when BOOST_PLAT_WINDOWS_UWP is 0.

The problem is that Boost.WinAPI only halfway ported to the partition macros and in some places directly tests Boost.Predef macros, which are all 0 after boostorg/predef#57. The right thing to do is to port all of Boost.WinAPI to the partition macros, which should account for the older SDKs. This is what I've done locally and testing now.

[pdimov]

But changing BOOST_PLAT_WINDOWS_RUNTIME from 1 to 0 on older SDKs is wrong. This change should be reverted as it has repercussions all over.

[Lastique]

BOOST_PLAT_WINDOWS_RUNTIME should be 0 on older SDKs. The breaking change is that BOOST_PLAT_WINDOWS_DESKTOP was previously 1 by default on older SDKs and now is 0. The rationale is that Boost.Predef reflects the fact that the SDK does not support API families. See boostorg/predef#54.

[pdimov]

Right, BOOST_PLAT_WINDOWS_DESKTOP. :-)

[jeking3]

@Lastique cool it'll be good to see the fixes here; I thought modifying config.hpp like I did in #59 was all that was needed.

[pdimov]

BOOST_PLAT_WINDOWS_DESKTOP needs to stay 1 on older SDKs if you ask me. #if BOOST_PLAT_WINDOWS_DESKTOP means "Desktop APIs are available" and they are.

[Lastique]

Both ways have its merits. I can agree with changing it back to 1 by default, although what is considered a "desktop API" is a little fuzzy since BOOST_PLAT_WINDOWS_APP and BOOST_PLAT_WINDOWS_SYSTEM families also exist on the desktop and not only there. This family stuff is a lot of mess, IMHO.

[Lastique]

Should be fixed in 8091170.

[pdimov]

The problem is that the old PLAT macros were mutually exclusive and indicated platforms, not API families. Changing them to mean (overlapping) API families is a breaking change, as code relies on their being mutually exclusive.

A much more prudent approach would have been to not touch these and introduce separate FAMILY macros which new code can test.