Boost C++ Libraries: Ticket #8070: prefer GetTickCount64 over GetTickCount

owner, status, severity changed

viboes — Sat, 16 Feb 2013 08:02:38 GMT

owner changed from Anthony Williams to viboes
status new → assigned
severity Problem → Cosmetic

Could you post the exact compiler report here?

alex@… — Sat, 16 Feb 2013 16:39:34 GMT

Absolutely:

C28159 Consider using another function instead.

Consider using 'GetTickCount64' instead of 'GetTickCount'.

Reason: GetTickCount overflows roughly every 49 days. Code that does not take that into account can loop indefinitely. GetTickCount64 operates on 64 bit values and does not have that problem.

viboes — Sat, 16 Feb 2013 21:42:56 GMT

Can we check if this function is available using conditional compilation?

alex@… — Sat, 16 Feb 2013 22:07:29 GMT

According to MSDN, this is available for WINNT >= 0x0600 (aka Vista/Server 2008)

milestone changed

viboes — Sat, 16 Feb 2013 23:23:46 GMT

milestone To Be Determined → Boost 1.54.0

status changed; resolution set

viboes — Sat, 23 Mar 2013 01:54:50 GMT

status assigned → closed
resolution → fixed

Committed revision [83525].

anonymous — Tue, 02 Jul 2013 15:54:27 GMT

Boost 1.54.0: This is breaking Windows XP compatibility for me: I'm compiling on Windows 7 with MinGW, but my users are on XP and are now seeing" Procedure Entry Point Not Found in Kernel32.dll". I have to revert back to Boost 1.52.

Regards, Zenju

schorsch_76@… — Wed, 03 Jul 2013 10:00:33 GMT

Same problem here as Zenju,

there seems no compatibility switch in the source. Is there an official statement for boost to not support XP anymore? Have not found anything in the release notes, that XP is no more supported.

Regards, Georg

status changed; resolution deleted

viboes — Wed, 03 Jul 2013 21:13:17 GMT

status closed → reopened
resolution fixed

Sorry for the disturbance. Please could you comment this line

22 #define BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64

in the following context.

branches/release/boost/thread/win32/thread_primitives.hpp
r81667 	r83525
18	18	#include <algorithm>
19	19
 	20	#ifndef BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64
 	21	#if _WIN32_WINNT >= 0x0600
 	22	#define BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64
 	23	#endif
 	24	#endif

Could someone try using a more restrictive check than

_WIN32_WINNT >= 0x0600

Maybe something specific to Vista?

viboes — Wed, 03 Jul 2013 21:17:30 GMT

Committed revision [84946]. Rollback.

anonymous — Thu, 04 Jul 2013 19:53:24 GMT

Thanks for the quick response! After commenting out BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64 and recompiling Boost 1.54, my binaries are running fine on XP again! Currently 30% of my users are still running XP so thanks for supporting this not so small scenario!

Regards, Zenju

milestone changed

viboes — Sat, 03 Aug 2013 11:22:09 GMT

milestone Boost 1.54.0 → To Be Determined

viboes — Sun, 15 Sep 2013 15:39:35 GMT

Could someone try if

branches/release/boost/thread/win32/thread_primitives.hpp

#ifndef BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64
#if _WIN32_WINNT >= 0x0600 && ! defined _WIN32_WINNT_WS08
#define BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64
#endif
#endif

works for Windows XP?

anonymous — Mon, 16 Sep 2013 16:37:03 GMT

yes it works

milestone changed

viboes — Mon, 16 Sep 2013 16:55:55 GMT

milestone To Be Determined → Boost 1.55.0

Committed revision [85701]. Committed revision [85714].

Wed, 18 Sep 2013 10:05:43 GMT

Just tested on Win8.1(boost rev. 85771) and it doesn't compile: libs\thread\src\win32\thread.cpp(433) : error C2653: 'win32' : is not a class or namespace name I believe it should be: unsigned long const elapsed_milliseconds=detail::win32::GetTickCount()-target_time.start;

viboes — Wed, 18 Sep 2013 10:59:57 GMT

My bad :( Committed revision [85772].

viboes — Sat, 21 Sep 2013 20:45:54 GMT

Committed revision [85815].

status changed; resolution set

viboes — Sat, 21 Sep 2013 20:50:01 GMT

status reopened → closed
resolution → fixed

status, version, severity changed; resolution deleted

anonymous — Mon, 18 Nov 2013 17:04:52 GMT

status closed → reopened
version Boost 1.52.0 → Boost 1.55.0
resolution fixed
severity Cosmetic → Problem

Hi,

the "Procedure Entry Point Not Found" for GetTickCount64 is back or I should better say was not resolved in first place. The

#ifndef BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64
#if _WIN32_WINNT >= 0x0600 && ! defined _WIN32_WINNT_WS08
#define BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64
#endif
#endif

check always enables the GetTickCount64, because _WIN32_WINNT is usually set to 0x0600. This value for _WIN32_WINNT OTOH is *always* required, even when targetting XP in order to have access to Vista and later Win32 structs when the very same executable is supposed to run on later versions of Windows. Commenting out BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64 again fixes the issue, but I would very much prefer to use a vanilla version of boost without requiring manual source changes before I can use.

Regards, Zenju

viboes — Tue, 19 Nov 2013 22:21:23 GMT

Replying to anonymous:

Hi,

the "Procedure Entry Point Not Found" for GetTickCount64 is back or I should better say was not resolved in first place. The
#ifndef BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64
#if _WIN32_WINNT >= 0x0600 && ! defined _WIN32_WINNT_WS08
#define BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64
#endif
#endif
check always enables the GetTickCount64, because _WIN32_WINNT is usually set to 0x0600. This value for _WIN32_WINNT OTOH is *always* required, even when targetting XP in order to have access to Vista and later Win32 structs when the very same executable is supposed to run on later versions of Windows.

Is _WIN32_WINNT_WS08 defined?

viboes — Tue, 19 Nov 2013 22:21:49 GMT

BTW, what are the android.exe?

tcourtney — Wed, 04 Dec 2013 19:53:52 GMT

I have a question about this issue and the proposed solution. We compile our software on Windows 7 but want the binaries to be compatible for all versions of Windows. It seems that any solution for this issue that relies on #ifdef, #define to determine the OS properties is only valid for the OS that the software was compiled on. I don't see how a solution based on static, compile time #ifdef logic could support both GetTickCount for XP and GetTickCount64 for Windows 7 using the same binary. This #ifdef fix only makes it possible to compile the code on XP or Windows7. But that doesn't fix the issue for my company because we need to release the same binary for XP and Windows 7.

viboes — Wed, 04 Dec 2013 22:09:06 GMT

Replying to tcourtney:

I have a question about this issue and the proposed solution. We compile our software on Windows 7 but want the binaries to be compatible for all versions of Windows. It seems that any solution for this issue that relies on #ifdef, #define to determine the OS properties is only valid for the OS that the software was compiled on. I don't see how a solution based on static, compile time #ifdef logic could support both GetTickCount for XP and GetTickCount64 for Windows 7 using the same binary. This #ifdef fix only makes it possible to compile the code on XP or Windows7. But that doesn't fix the issue for my company because we need to release the same binary for XP and Windows 7.

And you propose ...

raad@… — Thu, 19 Dec 2013 11:45:28 GMT

_WIN32_WINNT_WS08 is always defined if the windows.h from at least the Windows SDK 6.0 is included before Boost.Thread, so the value of BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64 can now vary in different source files depending on include order, which leads to serious bugs.

_WIN32_WINNT is the lowest Windows version the software is supposed to run on, so defining it as 0x0600 while still wanting to support Windows XP is incorrect and boost users should fix their code. Boost.Thread is by far not the only library that would drop support for Windows XP when _WIN32_WINNT is defined as 0x0600.

So if you want a static check for the minimum required Windows version at compile time, the check for (_WIN32_WINNT >= 0x0600) was absolutely correct. If you want a dynamic check at runtime, you need to call GetProcAddress.

viboes — Tue, 28 Jan 2014 20:59:04 GMT

Replying to raad@…:

_WIN32_WINNT_WS08 is always defined if the windows.h from at least the Windows SDK 6.0 is included before Boost.Thread, so the value of BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64 can now vary in different source files depending on include order, which leads to serious bugs.

_WIN32_WINNT is the lowest Windows version the software is supposed to run on, so defining it as 0x0600 while still wanting to support Windows XP is incorrect and boost users should fix their code. Boost.Thread is by far not the only library that would drop support for Windows XP when _WIN32_WINNT is defined as 0x0600.

So if you want a static check for the minimum required Windows version at compile time, the check for (_WIN32_WINNT >= 0x0600) was absolutely correct. If you want a dynamic check at runtime, you need to call GetProcAddress.

I have no access to a Windows machine now. I would be grateful of could you provide a patch that works for any windows release.

milestone changed

viboes — Tue, 28 Jan 2014 21:07:35 GMT

milestone Boost 1.55.0 → To Be Determined

attachment set

raad@… — Sun, 02 Feb 2014 14:40:52 GMT

attachment → gettickcount64.patch

Determine GetTickCount64 support at runtime

raad@… — Sun, 02 Feb 2014 14:56:27 GMT

Please find attached a patch with a run-time check for GetTickCount64 availability. Please note that ticks_type is always 64-bit with this patch and I don't think it's possible to implement this header-only without a huge run-time overhead, so there is a new cpp file.

Alternatively, for the correct compile-time check for the target Windows version, you could just revert commit 3ac48bdd65c4713438779e65a3f5ee4324a03b55 and add a macro like BOOST_THREAD_WIN32_DONT_USE_GET_TICK_COUNT_64 for those who are not willing to set their target Windows version correctly via _WIN32_WINNT. Or only let the user set BOOST_THREAD_WIN32_HAS_GET_TICK_COUNT_64.

viboes — Sun, 02 Feb 2014 21:39:18 GMT

Thanks for the patch. I will take a deeper look as soon as I reinstall all the needed tools on my new Windows machine.

milestone changed

viboes — Sat, 01 Mar 2014 07:52:49 GMT

milestone To Be Determined → Boost 1.56.0

https://github.com/boostorg/thread/commit/143adde27d7bf06d972d2ff0c4757f715e6107f2

status changed; resolution set

viboes — Wed, 12 Mar 2014 22:46:26 GMT

status reopened → closed
resolution → fixed