This allows to use any compatible types with INTERLOCKED_* macros, not just
the ones strictly matching the particular implementation of the intrinsics.
In particular, this fixes compilation for Cygwin64, which is an LP64 target,
meaning that long is 64-bit and _Interlocked* intrinsics use a different
integer type for its 32-bit integer arguments.
Additionally, enable use of intrin.h on Cygwin (32-bit).
The test has been updated to explicitly use 32-bit integer arguments.
There is a macro conflict for _InterlockedExchangePointer between intrin.h from
MSVC-12 and winnt.h from Windows SDK 8.1, which causes compilation failures.
This warning is not supposed to appear for global constants, however gcc 5.3
from MinGW spams this warning, at least for the invalid_handle_value constant.
Therefore we disable this warning for all constants declared in Boost.WinAPI.
This commit incorporates some of the changes made to
boost/smart_ptr/detail/sp_interlocked.hpp by Peter Dimov, namely:
- Define an internal config macro BOOST_INTERLOCKED_HAS_INTRIN_H when
the compiler is known to have a useful intrin.h header.
- Use this macro to select the common implementation based on intrin.h.
- Removed MinGW-w64 branch of implementation as it is now covered by
the common branch based on intrin.h.
- Added detection of clang-cl, a new MSVC pretender. The compiler is
assumed to have support for intrin.h.
- Added a separate branch for Windows CE >=6, with differently named
interlocked functions. No way to test this and no idea if this is
correct.
- For MSVC 8 and 9 don't use intrin.h as it reportedly conflicts
with <utility>. On these compilers we will declare the intrinsics
ourselves.
These macros conflict with the same named macros from Windows SDK and generate
warnings. Downstream libraries were ported to Boost.WinAPI replacement macros.
These macros may clash with macros defined by Windows SDK and generate warnings.
Downstream libraries need to be ported to Boost.WinAPI replacements and then
these definitions can be removed.
The compiler on Cygwin 64 does not define _WIN64. Instead, the macro is
defined in the private header. Without the macro we fail to detect 64-bit
Windows target and define basic types incorrectly. Include the private
header for now; we may switch to our private macro for this purpose
eventually.
Also avoid using boost/cstdint.hpp to define basic integer types as in
case of Cygwin 64, an LP64 platform, uint64_t and ULONGLONG are different
types.
Cygwin 64 implements LP64 model, meaning that `long` is 64-bit. Also,
clang emits warnings about __stdcall being ignored on targets other than
32-bit x86, so don't use it.
As part of this commit, convert Boost.WinAPI declarations to its local
calling convention macros equivalent to WINAPI and NTAPI and avoid
defining those macros when possible.
For MSVC-9 though the default is still Windows Vista as the Windows SDK used
with that compiler does not support Windows 7 definitions.
Also added a define for NTDDI version of the latest update to Windows 10. This
latest version is used by default when the user selects Windows 10 target.
The wProcessorArchitecture member of the SYSTEM_INFO struct was previously
inaccessible due to incorrect use of nameless unions/structs. This commit
fixes that to that the member should now be directly accessible as a
member of SYSTEM_INFO.
This commit also marks the nameless structs/unions with the __extension__
attribute to hopefully avoid gcc warnings about using this non-standard
feature.
MSVC-14.1 emits an error for the namespace alias because the same-named
symbol is visible from the point of the alias declaration. Instead, define
a new winapi namespace and import the boost::winapi namespace contents
into it.
Despite that the library now appears at the top level in the filesystem and
namespace, it is still not intended to be used by Boost users - the library
is purposed as an internal tool for Boost needs.
The old headers are still present and define the old namespace as an alias
to the new namespace. Thus backward compatibility is preserved. These headers
will be removed as soon as all dependent libraries are updated.
While at it, also made some nonessential cleanup in headers.
Reportedly, that code branch was not working an caused linking errors. As
reported in https://svn.boost.org/trac10/ticket/5431, Windows CE SDK still
provides Interlocked function definitions, but with slightly different
signatures. This PR keeps a single code branch for Windows CE that matches
the declarations described in the ticket. Untested.
This change is based on https://github.com/boostorg/winapi/pull/58
by James E. King, III <jking@apache.org>.
Fixes https://svn.boost.org/trac10/ticket/5431.
This change offers more control over the target Windows version. By
defining BOOST_USE_NTDDI_VERSION the user is able to specify the Windows
version down to the particular Service Pack. By default
BOOST_USE_NTDDI_VERSION will be deduced from either NTDDI_VERSION or
BOOST_USE_WINAPI_VERSION (which, in turn can be deduced from other
macros). In the latter case the macro will default to the latest known
Service Pack shipped for the given Windows version.
In addition to more control on the user's side this change also allows to
define APIs that first appeared in a Service Pack as opposed to RTM. This
allowed to fix compilation of RtlCaptureStackBackTrace.
Also updated the workaround for CryptReleaseContext since Windows SDK 10.0
no longer requires it.
