@monster Have you tried running the compiled exe on a Windows 7 machine with the interlockedExchangeAddNoFence64 function? As far as I understand, this function is a compiler intrinsic, meaning that the compiler internally knows how to spit out assembly instructions for every place that function is called. So while interlockedExchangeAddNoFence64 indeed first started appearing in the Windows 8 **SDK** it does not mean it won't work on earlier Windows Systems.
Instead interlockedExchangeAddNoFence64 will not work if you compile with an older compiler which did not know this intrinsic function. ref.: [InterlockedExchangeAddNoFence64 function](https://msdn.microsoft.com/en-us/library/hh972658.aspx) > This function is implemented using a compiler intrinsic where possible. For > more information, see the WinBase.h header file and > [_InterlockedExchangeAdd64_nf](https://msdn.microsoft.com/en-us/library/191ca0sk.aspx). And from [Compiler Intrinsics](https://msdn.microsoft.com/en-us/library/26td21ds.aspx): > Most functions are contained in libraries, but some functions are built in > (that is, intrinsic) to the compiler. These are referred to as intrinsic > functions or intrinsics. If a function is an intrinsic, the code for that > function is usually inserted inline, avoiding the overhead of a function call > and allowing highly efficient machine instructions to be emitted for that > function. One additional hint that InterlockedExchangeAddNoFence64 is not depending on a library (making it OS-agnostic), is that the MSDN page does not list the library file in which this function is implemented, in contrast to the [FormatMessage function](https://msdn.microsoft.com/en-us/library/ms679351.aspx) which lives in `Kernel32.dll` according to Microsoft (listed in the _Requirements_ table on the bottom of the MSDN page) BTW, our beloved gcc does the same thing, they just have different names. Atomic operations usally start with `__atomic` in gcc.
