====== BEGIN OUTPUT ======
libs/winapi: error: file not found; Did not find [project-root]/index.html file. The file is required for all libraries. Redirection to HTML documentation.
libs/winapi: error: directory not found; Missing [project-root]/doc directory. The [project-root]/doc directory is required for all libraries. Sources to build with and built documentation for the library. If the library needs to build documentation from non-HTML files this location must be buildable with Boost Build.
libs/winapi: warning: file not found; Did not find [project-root]/include/boost/[library].h* file. A single header for the library is suggested at [project-root]/include/boost/[library].h* if the library does not have a header directory at [project-root]/include/boost/[library].
libs/winapi: error: directory not found; Missing [project-root]/meta directory. The [project-root]/meta directory is required for all libraries.

EXIT STATUS: 1
====== END OUTPUT ======

For Xbox development, we make use of WINAPI_FAMILY_GAMES which is supported by the Windows 10 SDK (19041) or later.

When you build with WINAPI_FAMILY=WINAPI_FAMILY_GAMES, boost ends up misconfiguring a number of APIs which are supported such as SwitchToThread. Part of the problem is that WINAPI_FAMILY_GAMES by design does NOT include everything in WINAPI_PARTITION_SYSTEM. WINAPI_FAMILY_GAMES contains many more Win32 APIs than UWP, but less than the full DESKTOP partition.

The good news is that most the Win32 APIs used by the winapi headers ARE supported for WINAPI_FAMILY_GAMES.

The only APIs that are NOT in WINAPI_FAMILY_GAMES are:

• The WinCrypt functions in crypt.hpp (bcrypt.hpp is supported instead).
• The dbghelp.hpp functions
• FlushViewOfFile
• CompareObjectHandles
• Jobs APIs in jobs.hpp
• ImpersonateNamedPipeClient. TransactNamedPipe. GetNamedPipeClientComputerNameA, GetNamedPipeClientComputerNameW
• The priority class APIs in priority_class.hpp
• The security object APIs in security.hpp
• Shell APIs in shell.hpp
• ShowWindowAsync

Fixing this is important for making the rest of boost work on the Xbox platform.

Note that for Xbox development, we officially support the MSVC VS 2017 (v141) 15.9 or later toolset as well as clang/LLVM for Windows v11 or later. Due to some link warnings with newer SDKs and Microsoft GDKs, clang/LLVM for Windows v15 or later is recommended. We also recommend VS 2019 (v142) 16.11 or later.

There's no need to access the NDA Microsoft GDK with Xbox Extensions for this work as all the relevant APIs are in the public Windows SDK (19041) or later.

Visual Studio 2019 v16.8 reports the following error on this line if you include <boost/chrono.hpp> in a Win32 project:

boost-1.74\boost\winapi\basic_types.hpp(255,6): error C2467: illegal declaration of anonymous 'struct'

For this .vcxproj, I do have "Disable Language Extensions" set to "Yes (/Za)", which seems to be triggering this issue.
Also: "C++ Language Standard" is set to "Default (ISO C++14 Standard)"
"C Language Standard" is set to "Default (Legacy MSVC)"

I'm using MSVC 14.0 (2015) and building Boost 1.84.0 via cpm (CMake) on Windows 10 Pro:

CPMAddPackage(
  NAME boost
  VERSION 1.84.0
  URL [omitted]/boost-1.84.0.tar.xz
  URL_HASH SHA256=2e64e5d79a738d0fa6fb546c6e5c2bd28f88d268a2a080546f74e5ff98f29d0e
  EXCLUDE_FROM_ALL TRUE
  SYSTEM TRUE
  OPTIONS "BOOST_ENABLE_CMAKE TRUE"
          "BOOST_INCLUDE_LIBRARIES asio\\\;beast\\\;crc\\\;date_time\\\;filesystem\\\;log"
)

I receive the following error:
error C2039: 'CompareObjectHandles': is not a member of 'global namespace''

error C2873: 'CompareObjectHandles': symbol cannot be used in a using-declaration

What is strange is that the function declaration is inside the same if condition and therefore (depending by the result) should automatically be defined or undefined.

Any idea? Thanks 😅🥳🤯

Hi,

I'm getting this error in http://www.boost.org/development/tests/develop/developer/output/teeks99-08a-win2012R2-64on64-boost-bin-v2-libs-thread-test-async__async_executor_p-test-msvc-8-0-dbg-adrs-mdl-64-thrd-mlt.html

    call "c:\users\boost\appdata\local\temp\boost_regression\b2_msvc_8.0_vcvarsall_amd64.cmd" >nul
cl /Zm800 -nologo @"D:\t08\run\results\boost\bin.v2\libs\chrono\build\msvc-8.0\dbg\adrs-mdl-64\thrd-mlt\chrono.obj.rsp" 

chrono.cpp
..\boost/detail/winapi/time.hpp(90) : error C2039: 'GetTickCount64' : is not a member of '`global namespace''
..\boost/detail/winapi/time.hpp(90) : error C2873: 'GetTickCount64' : symbol cannot be used in a using-declaration

What has been changed and how can I fix it?

Interprocess in MSVC 7.1 does not link in debug (intrinsics are not enabled in Debug mode). This happened after support for BOOST_USE_INTRIN_H was added. This patch adds support for Visual 2003 using #pragma intrinsic and also uses intrin.h for Visual 2005 (_MSC_VER == 1400).

Interprocess correctly compiles after this patch is applied:

https://gist.github.com/anonymous/f826fb6e82c2bbcbef62

Build job: https://ci.appveyor.com/project/jeking3/winapi/build/job/s2mbgr4viurq20q9

compile-c-c++ bin.v2\libs\winapi\test\~hdr-use-winh-winapi-stack_backtrace~hpp.test\msvc-14.1\release\threading-multi\~hdr-use-winh-winapi-stack_backtrace~hpp.obj
decl_header.cpp
.\boost/detail/winapi/stack_backtrace.hpp(45): error C2039: 'RtlCaptureStackBackTrace': is not a member of '`global namespace''
.\boost/detail/winapi/stack_backtrace.hpp(45): error C2873: 'RtlCaptureStackBackTrace': symbol cannot be used in a using-declaration

There are reports that <boost/system/error_code.hpp> breaks code using NO_ERROR; the reason is that winapi/error_codes.hpp includes winapi/basic_types.hpp which includes <winerror.h> which defines all error codes as macros, including NO_ERROR.

It's not clear why <winerror.h> is included; winapi/error_codes.hpp defines the error codes as non-macros and does not rely on the macros.

I was recently using the new stacktrace module on Windows and discovered that it (eventually) ends up including windows.h. Unfortunately this header defines min and max macros that conflict with the standard C++ ones.

To work around this I currently have to define NOMINMAX (or undef BOOST_USE_WINDOWS_H) in my code. However, as discussed in a bug report for the ASIO module, this breaks encapsulation (I shouldn't have to care about the internal implementation of the stacktrace module).

This issue was solved for the ASIO module by defining NOMINMAX by default (see here). However, when I suggested a similar fix for the stacktrace module (see boostorg/stacktrace/issues/37), it was suggested that it may be better to fix this issue at "source".

I believe these are caused by Boost.WinAPI

http://www.boost.org/development/tests/develop/output/teeks99-09-f-win2016-64on64-beast-msvc-14-0-warnings.html#accept

... found by running the System tests:

gcc.compile.c++ ..\..\bin.v2\libs\system\test\error_code_user_test_header.test\g
cc-6.4.0\debug\address-model-64\target-os-cygwin\error_code_user_test.o
In file included from /usr/include/w32api/windows.h:70:0,
                 from test\error_code_user_test.cpp:26:
/usr/include/w32api/winbase.h:1085:28: error: conflicting declaration of C funct
ion 'void* LocalAlloc(UINT, SIZE_T)'
   WINBASEAPI HLOCAL WINAPI LocalAlloc (UINT uFlags, SIZE_T uBytes);
                            ^~~~~~~~~~
In file included from ..\../boost/system/detail/local_free_on_destruction.hpp:15
:0,
                 from ..\../boost/system/detail/error_code.ipp:28,
                 from ..\../boost/system/error_code.hpp:766,
                 from test\error_code_user_test.cpp:17:
..\../boost/winapi/local_memory.hpp:27:1: note: previous declaration 'void* Loca
lAlloc(boost::winapi::UINT_, boost::winapi::SIZE_T_)'
 LocalAlloc(
 ^~~~~~~~~~
In file included from /usr/include/w32api/windows.h:70:0,
                 from test\error_code_user_test.cpp:26:
/usr/include/w32api/winbase.h:1086:28: error: conflicting declaration of C funct
ion 'void* LocalReAlloc(HLOCAL, SIZE_T, UINT)'
   WINBASEAPI HLOCAL WINAPI LocalReAlloc (HLOCAL hMem, SIZE_T uBytes, UINT uFlag
s);
                            ^~~~~~~~~~~~
In file included from ..\../boost/system/detail/local_free_on_destruction.hpp:15
:0,
                 from ..\../boost/system/detail/error_code.ipp:28,
                 from ..\../boost/system/error_code.hpp:766,
                 from test\error_code_user_test.cpp:17:
..\../boost/winapi/local_memory.hpp:32:1: note: previous declaration 'void* Loca
lReAlloc(boost::winapi::HLOCAL_, boost::winapi::SIZE_T_, boost::winapi::UINT_)'
 LocalReAlloc(
 ^~~~~~~~~~~~

Clang-cl from master.
Removing :: fixes errors.

[sw.client.manager-0.4.2]/src/sw/manager/settings.cpp
In file included from D:/dev/cppan2/client2/src/sw/manager/settings.cpp:20:
In file included from D:/dev/primitives/src/log/include\primitives/log.h:13:
In file included from D:/dev/swst/pkg/8d/ed/6a12/src/sdir/include\boost/log/trivial.hpp:23:
In file included from D:/dev/swst/pkg/8d/ed/6a12/src/sdir/include\boost/log/sources/severity_logger.hpp:20:
In file included from D:/dev/swst/pkg/8d/ed/6a12/src/sdir/include\boost/log/detail/light_rw_mutex.hpp:39:
D:/dev/swst/pkg/3c/51/ca71/src/sdir/include\boost/winapi/srw_lock.hpp(73,43): error: no type named '_RTL_SRWLOCK' in the global namespace; did you mean simply '_RTL_SRWLOCK'?
    ::InitializeSRWLock(reinterpret_cast< ::_RTL_SRWLOCK* >(SRWLock));
                                          ^~~~~~~~~~~~~~
                                          _RTL_SRWLOCK
D:/dev/swst/pkg/3c/51/ca71/src/sdir/include\boost/winapi/srw_lock.hpp(61,32): note: '_RTL_SRWLOCK' declared here
typedef struct BOOST_MAY_ALIAS _RTL_SRWLOCK {
                               ^
D:/dev/swst/pkg/3c/51/ca71/src/sdir/include\boost/winapi/srw_lock.hpp(73,5): error: no member named 'InitializeSRWLock' in the global namespace; did you mean simply 'InitializeSRWLock'?
    ::InitializeSRWLock(reinterpret_cast< ::_RTL_SRWLOCK* >(SRWLock));
    ^~~~~~~~~~~~~~~~~~~
    InitializeSRWLock
D:/dev/swst/pkg/3c/51/ca71/src/sdir/include\boost/winapi/srw_lock.hpp(71,25): note: 'InitializeSRWLock' declared here
BOOST_FORCEINLINE VOID_ InitializeSRWLock(PSRWLOCK_ SRWLock)
                        ^
D:/dev/swst/pkg/3c/51/ca71/src/sdir/include\boost/winapi/srw_lock.hpp(78,49): error: no type named '_RTL_SRWLOCK' in the global namespace; did you mean simply '_RTL_SRWLOCK'?
    ::ReleaseSRWLockExclusive(reinterpret_cast< ::_RTL_SRWLOCK* >(SRWLock));
                                                ^~~~~~~~~~~~~~
                                                _RTL_SRWLOCK
D:/dev/swst/pkg/3c/51/ca71/src/sdir/include\boost/winapi/srw_lock.hpp(61,32): note: '_RTL_SRWLOCK' declared here
typedef struct BOOST_MAY_ALIAS _RTL_SRWLOCK {
                               ^
D:/dev/swst/pkg/3c/51/ca71/src/sdir/include\boost/winapi/srw_lock.hpp(78,5): error: no member named 'ReleaseSRWLockExclusive' in the global namespace; did you mean simply
      'ReleaseSRWLockExclusive'?
    ::ReleaseSRWLockExclusive(reinterpret_cast< ::_RTL_SRWLOCK* >(SRWLock));
    ^~~~~~~~~~~~~~~~~~~~~~~~~
    ReleaseSRWLockExclusive
D:/dev/swst/pkg/3c/51/ca71/src/sdir/include\boost/winapi/srw_lock.hpp(76,25): note: 'ReleaseSRWLockExclusive' declared here
BOOST_FORCEINLINE VOID_ ReleaseSRWLockExclusive(PSRWLOCK_ SRWLock)
                        ^
... output stripped ...

When compiling with the latest Visual Studio (2019 -- 16.1.1) and targeting the app for ARM64, a warning is emitted when using a boost::mutex instance. Namely, here's the warning:

boost\thread\win32\basic_timed_mutex.hpp(271,1): warning C4302:  'type cast': truncation from 'void *const ' to 'long'

The fix is in boost/detail/interlocked.hpp. Namely, on line 73 in interlocked.hpp, change this:

# if defined(_M_IA64) || defined(_M_AMD64) || defined(__x86_64__) || defined(__x86_64)

To this:

# if defined(_M_IX86) || defined(_M_IA64) || defined(_M_AMD64) || defined(__x86_64__) || defined(__x86_64) || defined(_M_ARM) || defined(_M_ARM64)

Note that _M_IX86, _M_ARM, and _M_ARM64 are all checked and use intrinsics. This follows the documentation from Microsoft: _InterlockedCompareExchangePointer Intrinsic Functions

This change both fixes the warning for ARM64 apps, as well as uses the available and documented intrinsics for x86 apps.

Originally reported over here: boostorg/thread#285

Hi!

I'm defining _WIN32_WINNT to _WIN32_WINNT_VISTA in my project, but then I get the following error from boost:

.../boost/process/detail/windows/locale.hpp(81): error C2039: 'WC_NO_BEST_FIT_CHARS_': is not a member of 'boost::winapi'

I found that this constant should be defined here:

#if BOOST_USE_WINAPI_VERSION >= BOOST_WINAPI_VERSION_WIN2K
BOOST_CONSTEXPR_OR_CONST DWORD_ WC_NO_BEST_FIT_CHARS_ = 0x00000400;
#endif

but unfortunately it evaluates to false because _WIN32_WINNT_VISTA is not defined at this point. Adding #include sdkddkver.h before comparing _WIN32_WINNT macro fixes this problem.

I think the right place for this is boost/winapi/config.hpp because that's where BOOST_USE_WINAPI_VERSION is defined.

This header appears to have been one of the earliest in the suite. It does not follow the flow of the rest of the winapi headers and should be refactored to fit in, and also moved into the right place. To maintain backwards compatibility, a deprecation warning header can be left in its place for one release (and another issue should then be filed to remove it in the following release).

I haven't been able to build boost using Visual Studio 2022-14.3 on Debug x64 configuration with sanitizer enabled. I am seeing a few issues. The first is a library naming problem when linking with errors such as:
msvc.link.dll bin.v2\libs\url\build\msvc-14.3\debug\address-sanitizer-on\threading-multi\boost_url-vc143-mt-gd-x64-1_81-asan.dll clang_rt.asan_dbg_dynamic_runtime_thunk-x86_64.lib(sanitizer_win_dynamic_runtime_thunk.cpp.obj) : error LNK2005: "void __cdecl __sanitizer::ForceWholeArchiveIncludeForSanitizerCommon(void)" (?ForceWholeArchiveIncludeForSanitizerCommon@__sanitizer@@YAXXZ) already defined in clang_rt.asan_dynamic_runtime_thunk-x86_64.lib(sanitizer_win_dynamic_runtime_thunk.cpp.obj) clang_rt.asan_dbg_dynamic_runtime_thunk-x86_64.lib(sanitizer_coverage_win_sections.cpp.obj) : error LNK2005: __start___sancov_cntrs already defined in clang_rt.asan_dynamic_runtime_thunk-x86_64.lib(sanitizer_coverage_win_sections.cpp.obj) clang_rt.asan_dbg_dynamic_runtime_thunk-x86_64.lib(sanitizer_coverage_win_sections.cpp.obj) : error LNK2005: __stop___sancov_cntrs already defined in clang_rt.asan_dynamic_runtime_thunk-x86_64.lib(sanitizer_coverage_win_sections.cpp.obj)
I managed to get around this problem by changing the references to the library(ies) above from non-dbg to dbg library names in tools\build\src\tools\msvc.jam lines 504-556. E.g.:
Line 504: clang_rt.asan_dynamic-x86_64 -> clang_rt.asan_dbg_dynamic-x86_64
Line 505: clang_rt.asan_dynamic_runtime_thunk-x86_64 -> clang_rt.asan_dbg_dynamic_runtime_thunk-x86_64
and so forth...

Past this issue, I've found another issue where it can't find a couple of Windows API functions:
compile-c-c++ bin.v2\libs\nowide\build\msvc-14.3\debug\address-sanitizer-on\threading-multi\cstdio.obj cstdio.cpp msvc.link.dll bin.v2\libs\log\build\msvc-14.3\debug\address-sanitizer-on\threadapi-win32\threading-multi\boost_log-vc143-mt-gd-x64-1_81-asan.dll Creating library bin.v2\libs\log\build\msvc-14.3\debug\address-sanitizer-on\threadapi-win32\threading-multi\boost_log-vc143-mt-gd-x64-1_81-asan.lib and object bin.v2\libs\log\build\msvc-14.3\debug\address-sanitizer-on\threadapi-win32\threading-multi\boost_log-vc143-mt-gd-x64-1_81-asan.exp event.obj : error LNK2019: unresolved external symbol WaitOnAddress referenced in function "public: static unsigned int __cdecl boost::atomics::detail::wait_operations_windows<struct boost::atomics::detail::core_operations<4,0,0>,4>::wait(unsigned int const volatile &,unsigned int,enum boost::memory_order)" (?wait@?$wait_operations_windows@U?$core_operations@$03$0A@$0A@@detail@atomics@boost@@$03@detail@atomics@boost@@SAIAEDIIW4memory_order@4@@Z) event.obj : error LNK2019: unresolved external symbol WakeByAddressSingle referenced in function "public: static void __cdecl boost::atomics::detail::wait_operations_windows<struct boost::atomics::detail::core_operations<4,0,0>,4>::notify_one(unsigned int volatile &)" (?notify_one@?$wait_operations_windows@U?$core_operations@$03$0A@$0A@@detail@atomics@boost@@$03@detail@atomics@boost@@SAXAECI@Z) bin.v2\libs\log\build\msvc-14.3\debug\address-sanitizer-on\threadapi-win32\threading-multi\boost_log-vc143-mt-gd-x64-1_81-asan.dll : fatal error LNK1120: 2 unresolved externals
I have also found a way to get around this problem by commenting out the #if defined(BOOST_USE_WINDOWS_H) in boost\winapi\wait_on_address.hpp line 22.
Is this something I am missing or support that should be added to sanitizer on msvc 14.3?

Hi,

when I try to include boost\thread\win32\thread_data.hpp in a x64 project, I get compilation error:

include\boost/thread/win32/thread_data.hpp(150,1): error C2665: '_InterlockedIncrement': none of the 4 overloads could convert all the argument types
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winbase.h(9334,1): message : could be 'unsigned __int64 _InterlockedIncrement(volatile unsigned __int64 *)'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winbase.h(9322,1): message : or 'unsigned long _InterlockedIncrement(volatile unsigned long *)'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\winbase.h(9313,1): message : or 'unsigned int _InterlockedIncrement(volatile unsigned int *)'
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\include\intrin0.h(195,1): message : or 'long _InterlockedIncrement(volatile long *)'
include\boost/thread/win32/thread_data.hpp(150,1): message : while trying to match the argument list '(int *)'

I think the issue is that the BOOST_INTERLOCKED_LONG32 in interlocked.hpp introduced in commit 65b9c99 is not (always) correct.
There is no "_InterlockedIncrement(int*)" in any of the header, the closest I found is "_InterlockedIncrement(unsigned int*)" so maybe BOOST_INTERLOCKED_LONG32 can be defined as unsigned int instead of int ?

Winapi needs updates to support UWP Windows Store application development.
Build job: https://ci.appveyor.com/project/jeking3/winapi/build/job/mfhg74xyt5jrt2tk
There are too many failures to list them here individually.

It's very unfortunate that Winapi places all of its headers into boost/detail instead of boost/winapi/.... This irregularity means that every header is an exception for the purposes of determining dependencies.

In basic_types.hpp, there is a code snippet like below:

Wondering is it necessary to define STRICT here? Or can it be rename to something else like BOOST_WINAPI_STRICT? It is nice to keep the global namespace pollution as little as possible.

In boostorg/dll#10 it was discovered that Windows Embedded Compact 2013 is currently not supported. That leads to errors like:

1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(415): error C2061: syntax error : identifier 'LPVOID'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2146: syntax error : missing ';' before identifier 'LockResource'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2433: 'LPVOID' : 'inline' not permitted on data declarations
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2065: 'HGLOBAL' : undeclared identifier
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2146: syntax error : missing ')' before identifier 'hResData'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2059: syntax error : ')'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2143: syntax error : missing ';' before '{'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2447: '{' : missing function header (old-style formal list?)
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(624): error C2061: syntax error : identifier 'LPDWORD'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(645): error C2061: syntax error : identifier 'LPDWORD'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(656): error C2061: syntax error : identifier 'LPDWORD'

Inclusion of #include <windows.h> leads to errors with linkage:

1>D:\libraries\boost_1_63_0\boost/detail/winapi/dll.hpp(58): error C2375: 'LoadLibraryW' : redefinition; different linkage
1>          C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\winbase.h(1261) : see declaration of 'LoadLibraryW'
1>D:\libraries\boost_1_63_0\boost/detail/winapi/dll.hpp(100): error C2375: 'VirtualQuery' : redefinition; different linkage
1>          C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\winbase.h(1013) : see declaration of 'VirtualQuery'

WINAPI is defined in the following way:

#elif (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED)
#define CALLBACK    __stdcall
#define WINAPI      __stdcall
#define WINAPIV     __cdecl
#define APIENTRY    WINAPI
#define APIPRIVATE  __stdcall
#define PASCAL      __stdcall
#else

Defining BOOST_USE_WINDOWS_H helps to workaround all the issues.

When I'm building my solution in release mode I keep getting this warning which is treated as an error.
Specifically it happens in some files in the winapi folder, such as get_last_error.hpp, on the GetLastError function

I dont want to use pragma disable warning on my projects, does anyone have any idea of why this happens..?

I'll add it, this is a reminder

We need a suite of tests that exercise the large number of compile-time branches in the project and ensure compatibility with Visual Studio versions (2010 through 2017) and older MinGW 32-bit and newer MinGW-x64.

Hi,

I am trying to build my projects in VS2022 (17.0.3) with the latest build tools in Release(x64) mode. I get the following errors -

Other relevant settings -
Disable language Extensions - set to NO

The projects build fine in Debug mode, so I wonder if upgrading to a more latest Boost version would help in this case.

Thanks in anticipation!

Use of BOOST_SYMBOL_IMPORT is not a good choice.

Something like BOOST_WINAPI_SYMBOL_IMPORT is needed, so that it could be defined to nothing for #ifdef _WIN32_WCE

It could be an easy solution but...

But there is a complication for Windows Mobile 6.0, (SDK is included into Visual Studio 2008 Prof).
Half of the WINAPI functions are __declspec(dllimport), and another half are linked locally with corelib.dll

So, ideally all WINAPI mapping in boost::winapi should have either BOOST_WINAPI_SYMBOL_IMPORT1 or BOOST_WINAPI_SYMBOL_IMPORT2.

Hence for defined(_WIN32_WCE) && defined(WIN32_PLATFORM_PSPC) only one of those will be defined to nothing, and another half will be defined to BOOST_SYMBOL_IMPORT normally.

My preliminary experiments showed that the mentioned changes and and a couple #ifdefs for missing Ex WINAPIs are enough to make this WM and CE-related regression in boost 1.67 go away. Deciding BOOST_WINAPI_SYMBOL_IMPORT1 vs BOOST_WINAPI_SYMBOL_IMPORT2 manually may take a few hours of manual work.

I'm experiencing build failures with Boost 1.68 using the latest SVN/Git revisions of GCC 8.2.1 and MinGW-w64. I have set the default _WIN32_WINNT for MinGW-w64 to 0xA00 (i.e., Windows 10), and am attempting to build through the latest version of MSYS2.

I'm getting several errors similar to this one when building:

gcc.compile.c++ bin.v2\libs\log\build\gcc-8.2.1\release\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\init_from_settings.o
In file included from ./boost/thread/win32/thread_primitives.hpp:31,
                 from ./boost/thread/win32/thread_heap_alloc.hpp:9,
                 from ./boost/thread/detail/thread_heap_alloc.hpp:15,
                 from ./boost/thread/tss.hpp:10,
                 from ./boost/log/sinks/basic_sink_frontend.hpp:30,
                 from ./boost/log/sinks/unlocked_frontend.hpp:26,
                 from ./boost/log/sinks.hpp:22,
                 from libs\log\src\setup\init_from_settings.cpp:54:
./boost/winapi/handles.hpp:49:9: error: '::CompareObjectHandles' has not been declared
 using ::CompareObjectHandles;
         ^~~~~~~~~~~~~~~~~~~~

It seems like either there's an issue with how CompareObjectHandles is declared in this header file, or there's an issue with MinGW-w64 that needs addressing.

The following headers print a deprecation warning, and given they were already deprecated in a previous release, they can now be removed:

include/boost/detail/winapi/GetCurrentProcess.hpp
include/boost/detail/winapi/GetCurrentThread.hpp
include/boost/detail/winapi/GetLastError.hpp
include/boost/detail/winapi/GetProcessTimes.hpp
include/boost/detail/winapi/GetThreadTimes.hpp

BOOST_INTERLOCKED_EXCHANGE_ADD and other functions compile making use of clang-cl, however, when used, these cause linker errors because the MinGW functions are used instead of the intrinsic.
Below, you can find the production.

run.bat

cl.exe /IC: \Boost_167_x64 /DBOOST_ALL_NO_LIB /nologo /c /GR /EHsc /fp:precise /FS /std:c++17 /diagnostics:caret /O2 /I. /MDd /Zc:forScope /bigobj /Zc:wchar_t /Zc:inline m.cpp
move m.obj m.msvc.obj
link m.msvc.obj /LIBPATH:C: \Boost_167_x64\stage\release\lib /LIBPATH:C:\ Boost_167_x64\stage\debug\lib

c: \llvm_6_0_0\bin\clang-cl.exe -fms-compatibility-version=19.11 -w -Wno-unused-command-line-argument /IC: \Boost_167_x64 /DBOOST_ALL_NO_LIB /nologo /c /GR /EHsc /fp:precise /FS /std:c++17 /diagnostics:caret /O2 /I. /MDd /Zc:forScope /bigobj /Zc:wchar_t m.cpp
move m.obj m.clang.obj
link m.clang.obj /LIBPATH:C: \Boost_167_x64\stage\release\lib /LIBPATH:C: \Boost_167_x64\stage\debug\lib

m.cpp

// Reduced from barrier.hpp
#include <boost/detail/interlocked.hpp>

int main(int, char**)
{
long active_count = 0, lock_flag_value = 1;
long newValue = BOOST_INTERLOCKED_EXCHANGE_ADD(&active_count, lock_flag_value);
return 0;
}

Extra info:

Looks like MSVC gives true for #if defined( BOOST_MSVC ) && BOOST_MSVC >= 1400 (line 80) while Clang ends up with #elif defined( WIN32 ) || defined( _WIN32 ) || defined( WIN32 ) || defined( CYGWIN ) (line 154)

By result, <intrin.h> does not get included, which causes a link error:
unresolved external symbol __imp_InterlockedExchangeAdd referenced in function main
Defining BOOST_USE_INTRIN_H can be used as workaround.

The Pool tests use -Werror and fail under MinGW with

..\../boost/winapi/system.hpp:52:9: error: ISO C++ prohibits anonymous structs [-Werror=pedantic]
         } DUMMYSTRUCTNAME;
         ^

The member is given a dummy name, but the struct itself isn't.

Build job: https://ci.appveyor.com/project/jeking3/winapi/build/job/ri0d2776mf80d1hn

ompile-c-c++ bin.v2\libs\winapi\test\~hdr-use-winh-winapi-jobs~hpp.test\msvc-14.1\debug\threading-multi\~hdr-use-winh-winapi-jobs~hpp.obj
decl_header.cpp
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(80): error C2039: 'OpenJobObjectA': is not a member of '`global namespace''
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(80): error C2873: 'OpenJobObjectA': symbol cannot be used in a using-declaration
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(94): error C2039: 'CreateJobObjectA': is not a member of '`global namespace''
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(94): error C2664: 'boost::detail::winapi::HANDLE_ boost::detail::winapi::CreateJobObjectA(boost::detail::winapi::LPSECURITY_ATTRIBUTES_,boost::detail::winapi::LPCSTR_)': cannot convert argument 1 from '_SECURITY_ATTRIBUTES *' to 'boost::detail::winapi::LPSECURITY_ATTRIBUTES_'
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(94): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(99): error C2039: 'CreateJobObjectA': is not a member of '`global namespace''
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(99): error C2664: 'boost::detail::winapi::HANDLE_ boost::detail::winapi::CreateJobObjectA(boost::detail::winapi::LPSECURITY_ATTRIBUTES_,boost::detail::winapi::LPCSTR_)': cannot convert argument 1 from '_SECURITY_ATTRIBUTES *' to 'boost::detail::winapi::LPSECURITY_ATTRIBUTES_'
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(99): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(104): error C2039: 'OpenJobObjectA': is not a member of '`global namespace''
C:\projects\boost-root\boost/detail/winapi/jobs.hpp(104): error C3861: 'OpenJobObjectA': identifier not found

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.

I need a few functions from DbgHelp.h for an extension of boost.DLL, would this fit into this library? It's not the winapi strictly speaking, but it's so heavily dependent on that, that I'd like to add it here as soon as it's tested.

https://github.com/boostorg/winapi/blob/develop/include/boost/winapi/basic_types.hpp#L262

See:
http://www.boost.org/development/tests/develop/output/igaztanaga-develop-gcc-4-9c++14-beast-gcc-4-9c+-warnings.html#base64

From ::CreateFile

FILE_FLAG_RANDOM_ACCESS
FILE_FLAG_SEQUENTIAL_SCAN
...

However users complain, that it is not available from Boost.WinAPI:

Phil Bouchard:

• I had to change the scope of GetModuleFileNameA in:
  if (!GetModuleFileNameA(handle, file_name_, DEFAULT_PATH_SIZE_))

Currently that line looks like this https://github.com/boostorg/stacktrace/blob/1614e8ff7d79c091bc9216f4f138670db3db8a33/include/boost/stacktrace/detail/location_from_symbol.hpp#L58 , so Phil dropped the boost::detail::winapi:: to use the global function

This is an issue that surfaced in the uuid project, where seed_rng does not work with UWP non-desktop. To support newer Windows platforms, the random project will need access to bcrypt. BCrypt will be used by future boostorg/random for all platforms at Windows 7 or later in the random_device code. BCrypt is also available in MinGW-x64, but it is not available in MinGW.

if a project is compiled with ISOLATION_AWARE_ENABLED, some declarations in boost.winapi are incompatible with <windows.h>

#include <windows.h>
#include <boost/winapi/dll.hpp>

yields

[...]\boost\winapi\dll.hpp(38): error C2375: 'IsolationAwareLoadLibraryA': redefinition; different linkage
[...]\winbase.inl(287): note: see declaration of 'IsolationAwareLoadLibraryA'

because under ISOLATION_AWARE_ENABLED, the functions are inline and not __declspec(dllimport)

Build job: https://ci.appveyor.com/project/jeking3/winapi/build/job/9jtkes24qr42js6a

ompile-c-c++ bin.v2\libs\winapi\test\~hdr-post-winh-winapi-handles~hpp.test\msvc-14.1\release\threading-multi\~hdr-post-winh-winapi-handles~hpp.obj
windows_h_post.cpp
C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\um\handleapi.h(81): error C2732: linkage specification contradicts earlier specification for 'CompareObjectHandles'
C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\um\handleapi.h(78): note: see declaration of 'CompareObjectHandles'