默認情況下，GetTickCount和timeGetTime具有相同的分辨率 - 15.625ms，但在調用timeBeginPeriod（1）後，GetTickCount仍會每15.625 ms更新一次，而timeGetTime每隔1ms更新一次，爲什麼？爲什麼GetTickCount和timeGetTime具有不同的分辨率？
在Bug in waitable timers?，筆者提到：
我想知道的是：爲什麼的GetTickCount和timeGetTime來自同一個RTC，但有兩種解決的？
謝謝！
我認爲OP在計時器，中斷和計時器滴答聲之間變得混亂。
量程間隔是計時器滴答週期。它以18.2滴/秒的速度硬連線進入系統。這絕不會因任何原因而變化，並且不基於系統CPU時鐘（顯然！）。
您可以向系統詢問兩個不同的事情：日期和時間（GetTime）或系統運行的時間量（GetTickCount/GetTickCount64）。
如果您對系統正常運行時間感興趣，請使用GetTickCount。根據我的理解，GetInterruptTime只返回在實時中斷期間花費的時間（與花在運行應用程序或閒置的時間相反）。
我不確定告訴新程序員停止詢問「爲什麼？」會幫助他們。是的，OP沒有看到或閱讀過提到的頁面上的評論;但在這裏詢問不應該只是對已經用盡所有其他途徑的搜索者（可能包括C的看石頭）給予的特權。我們都在這裏學習。不要告訴他們爲什麼他們的問題是毫無意義的。沒有理由不問。定時器可能會讓人困惑！
實際上，您引用的表對於QueryPerformanceCounter是錯誤的。 QPC（簡稱）是根據3種可能的時序源實現的，分別是1：HPET，2：PM ACPI定時器，3：RDTSC。 根據條件，內核啓動選項，bios中的錯誤以及芯片組提供的ACPI代碼中的錯誤進行啓發式決策。所有這些錯誤都是在Microsoft實驗室的每個硬件基礎上發現的。 Linux和BSD程序員必須自己找到困難，通常必須重寫ACPI代碼以解決問題。由於不同的原因，Linux社區開始討厭RDTSC以及ACPI。但無論如何...
timeReadTime與GetTickCount不同，因爲根據文檔指定的GetTickCount如何使其行爲不能被更改的穩定性。 但是在某些情況下需要Windows才能獲得更好的Tick分辨率，以便實現更好的定時器功能。 （定時器與消息發送到應用程序GetMessage或PeekMessage函數，然後分支在良好的回調處理定時器） 這是多媒體，如聲音/音頻同步所需。
顯然，遊戲或實時編程甚至需要更好的精度，並且不能使用定時器。相反，他們使用繁忙的等待，或者只有一次睡眠：通過調用OpenGL或DirectX uppon backbuffer/frontbuffer交換的VSync。視頻驅動程序將喚醒屏幕本身的等待線程uppon VSync信號。這是一個基於事件的睡眠，就像一個定時器，但不基於定時器中斷。
應該指出，現代內核有動態滴答（無縫內核，從Windows 8或Linux 2.6.18）。滴答中斷的最佳頻率不能低於1ms以避免窒息，但沒有上限。如果沒有應用程序正在運行併發布計時事件，則計算機可能會無限期地休眠，從而使CPU進入最深度睡眠狀態（Intel Enhanced Speed Step C7狀態）。之後的下一次喚醒事件，大部分時間都是由於設備中斷造成的，主要是USB。 （鼠標移動或其他東西）
相關閱讀：http://blogs.msdn.com/b/larryosterman/archive/2009/09/02/what-s-the-difference-between-gettickcount-and-timegettime .aspx – 2013-03-13 12:56:17
我不明白，爲什麼在地球上你會期望兩個不同的* winapi函數表現相同？如果它被設計爲相同，那麼當然不需要添加單獨的功能。 – 2013-03-13 14:45:53
@CodyGray感謝您的信息。正如作者所說：「KeGetTickCount得到滴答計數; KeQueryInterruptTime得到中斷時間計數」。滴答計數和中斷時間計數有什麼不同？我很困惑有多少基於計時器的窗口使用？ – ajaxhe 2013-03-14 01:17:36