GetTickCount64

In the past GetTickCount has been a good friend to scenarios where you want simple time counting. One typical usage is to count the timeout by yourself. Say, you want to wait for your objects for 10 seconds while allowing your Window messages loop to proceed uninterrupted. Instinctively you write code like:

1: DWORD dwTimeout = GetTickCount() + dwMilliseconds; 

2:   

3: while (dwTimeout > GetTickCount()) 

4: { 

5:   

6: 

.... 

7:   

8: MsgWaitForMultipleObjects(); 

9:   

10: .... 

11: } 

12:  

With some experience you know that this function has a seemingly innocent but in fact very serious restriction: GetTickCount() wraps every 49.7 days, which translates to: every 49.7 days, this block of code will have a dwMilliseconds millisecond Window to fail. Every n milliseconds per every 49.7 days may sound safe to ignore. Well, this might be true for casual freeware running on client computers. But for servers that run 24/7, or for components that ship with Windows. This will fail, and it will fail at the worst timing ever, period.

Starting Vista, Windows offer an 64 bits version of GetTickCount called GetTickCount64(). a 64 bits tick count is practically timeless (if it ever wraps, the speed of light will become negative and the universe will vanish). With this new API, the simple implementation became solid again and your logic can be as simple as you'd like.

Sound all good? Perhaps. Let's switch to API designer's seat and think about the problem again: GetTickCount is a API that looks simple, really simple, so simple that it attracts lots of usage. However, beneath the skin of oh-it-is-so-easy-to-use, the API itself is in fact cumbersome to use correctly. This illusion of simplicity invites bug that is very difficult to reproduce and investigate. So think the problem again, does it sound as good?

"When reviewing an API design, think about how it will be abused". I don't remember where this sentence came from but it has been proofing itself again and again. If the designer of GetTickCount thought about how this innocent API would lead many hard bugs, he or she will probably use the 64 bits time counter from day 0.

So, for you my dear reader, what can you take out today? I'll say two things:

1. Windows Vista is better from fundamental API support

2. When designing API, think about how they can be abused and how likely they're abused

I really hope my API won't be picked for bad API design discussion. oh well.