Если это критично, то читаем маны: To avoid this problem, use the GetTickCount64 function.21.12.11 13:29 Автор: kstati <Евгений Борисов> Статус: Elderman
не все на 64 битах сидят и ты должен это учитывать.
P.S. зачем я это говорю, это же очевидно
Это-то при чём. Функция висит в том числе и на 32-х битных ос. Только что проверил на своей семёрке. Или мало примеров функций, возвращающих данные длиннее, чем разрядность системы?22.12.11 12:50 Автор: kstati <Евгений Борисов> Статус: Elderman
NtQuerySystemTime may be altered or unavailable in future versions of Windows.
а если серьёзно, то проблема решаема, только не так как она была предложена
Ну волков бояться... M$ достаточно параноидально относится к совместимости, а эта функция успела обрести популярность.22.12.11 00:43 Автор: HandleX <Александр М.> Статус: The Elderman
про волков это зря, у нас такое не пройдёт, и правильно22.12.11 02:57 Автор: + <Mikhail> Статус: Elderman Отредактировано 05.01.12 20:47 Количество правок: 1
Смысл, в том, что нередко необходимо ждать HANDLE-а не INFINITE, но выходить по таймауту. Обрати внимание, что все API Waitxxx функции имеют таймаут в качестве одного из аргументов.
Но при этом оконное приложение (тред на котором выподняется оконная процедура) не должет быть блокирован на Wait функции. По этой причине выполняется прокачка сообщений вместе с ожиданием HANDLE-а. Microsoft версия такой функции не имеет таймаута.
Дык handle-а-то таким способом не получишь!18.12.11 06:23 Автор: Zef <Alloo Zef> Статус: Elderman