В последней оффлайновой MSDN от 2008-го о длительности подписки и периодичности уведомлений сказано только это:

This function detects a single change. After the caller receives a notification event, it should call the function again to receive the next notification.

В онлайн-документации MS аж выделено следующее добавление:

Note On Windows NT, Windows 2000, and Windows XP calling RegNotifyChangeKeyValue for a particular key handle causes change notifications to continue to occur for as long as the key handle is valid. This causes a second call to RegNotifyChangeKeyValue to return immediately, if any changes have occurred in the interim period between the first and second calls. If the API is being used asynchronously, the passed event handle will be signaled immediately if any interim changes have occurred.

Как это все понимать? MSDN 2008 выпускалась уже после Vista. Если в работе функции произошли такие радикальные изменения, то странно, почему это не было отражено.

Кто пользовался функцией в разных системах — что меняется между NT/2k/XP и последующими версиями?

Microsoft Windows 98 does not keep track of interim changes. Calling
RegNotifyChangeKeyValue only notifies you of changes occurring after the
call.

(c) https://comp.os.ms-windows.programmer.win32.narkive.com/pKV4mduh/xp-registry-monitoring-regnotifychangekeyvalue-and-createevent
Просто мс выпилила из статьи описание поведения под 9х руками течврайтера-джуниора, без понимания контекста.

Здравствуйте, ononim, Вы писали:

O>

Microsoft Windows 98 does not keep track of interim changes. Calling
O>RegNotifyChangeKeyValue only notifies you of changes occurring after the
O>call.

О, спасибо, теперь стало чуть понятнее.

Раньше никогда не доводилось пользоваться, а сейчас смотрю и изумляюсь, до чего уродливый механизм. Это ж надо было додуматься ограничить уведомления единственным разом, чтоб потом городить логику промежуточного накопления...

Да и теперь, судя по всему, тоже не получится использовать. Хотел избавиться от частого поллинга реестровых ключей, но уже и не знаю, стоит ли одну кривизну менять на другую. Тем более, что есть вероятность изначального отсутствия в реестре не только "концевых" ключей, в которых надо проверять элементы, но и "корневого" подключа в Windows\CurrentVersion. А если мониторить весь CurrentVersion, то обращений к реестру станет больше на пару порядков, чем при тупом поллинге.

ЕМ>Раньше никогда не доводилось пользоваться, а сейчас смотрю и изумляюсь, до чего уродливый механизм. Это ж надо было додуматься ограничить уведомления единственным разом, чтоб потом городить логику промежуточного накопления...
Если бы RegNotifyChangeKeyValue умел возвращать больше чем одно уведомление за раз, то все равно пришлось бы делать промежуточнрое накопление. ReadDirectoryChanges именно так и работает.

Здравствуйте, ononim, Вы писали:

O>Если бы RegNotifyChangeKeyValue умел возвращать больше чем одно уведомление за раз, то все равно пришлось бы делать промежуточнрое накопление.

Только для режима с ожиданием. Событие-то можно дергать при каждом изменении.

O>>Если бы RegNotifyChangeKeyValue умел возвращать больше чем одно уведомление за раз, то все равно пришлось бы делать промежуточнрое накопление.
ЕМ>Только для режима с ожиданием. Событие-то можно дергать при каждом изменении.
ReadDirectoryChangesW тоже так же работает в асинхронном (aka overlapped) режиме, получил уведомление об одном или нескольких изменениях — будь добр запустить новую ReadDirectoryChangesW, чтобы получить последующие. Количество событий в одном уведомлении никакой роли не играет, по сути это чисто оптимизация. Программисту проще как раз по одному разгребать, чтоб не заниматься разгребанием цепочки струтур врукопашную.

Здравствуйте, ononim, Вы писали:

O>ReadDirectoryChangesW тоже так же работает

Она возвращает непосредственно данные, а RegNotifyChangeKeyValue — только уведомления о факте наличия изменений. Поэтому было бы удобнее один раз подписаться, и затем тупо мониторить состояние события.

O>>ReadDirectoryChangesW тоже так же работает
ЕМ>Она возвращает непосредственно данные, а RegNotifyChangeKeyValue — только уведомления о факте наличия изменений. Поэтому было бы удобнее один раз подписаться, и затем тупо мониторить состояние события.
Думаю очевидно что это все реализовано через одинаковый механизм overlapped IO: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-zwnotifychangekey
Ну а то что RegNotifyChangeKeyValue ничего не возвращает — так это Дэйву в свое время не хватило времени допилить, а потом уже никто и не посмел.