Я обновляю довольно старое приложение. Он использовал INI-файл для доступа ко всему окну, создавая и освобождая INI-доступ к экземплярам класса здесь и там.Является ли Windows NT кэшем или скрывает записи INI-файлов?
Я хочу централизовать это несколько экземпляров, по одному на используемый файл. Таким образом, мы избавлялись бы от экземпляров, создающих/освобождающих всюду копируемую копию, и имели бы свободу полностью заменить эти классы, было бы решение переключиться с INI на другое хранилище настроек.
Следует ли использовать WritePrivateProfileString (NULL, NULL, NULL ...) для применения изменений? Предположим, что: 1) доступ идет непосредственно к реальным INI-файлам, а не к отображаемым в реестре. 2) ОС семейства NT (возможно, редко Win2000, скорее всего WinXP и позже). Win9x/ReactOS/WinE/Odin/etc не заботятся.
Итак, нужно ли мы спрятать сбережения ini прямо сейчас или нет?
NT не кэширует запись в реестре, теперь не нужно regFlushKey. Но как насчет файлов INI?
Страница MSDN о WritePrivateProfileString описывает только технологию промывки по файлам Win9x и NT File-to-Reg. Он молчит о реальных файлах INI.
В Windows NT реестр состоит из нескольких физических файлов. –
Да, я надеюсь, что он изменился в NT так же, как в реестре. ProcMon - хороший намек, но он не доказывает. Просто потому, что мы имитируем однозадачную среду, и если диск Windows не занят, он очистит кеш, а почему бы и нет. Но что, если несколько потоков/программ обновили один и тот же файл? Что делать, если программа сильно разбилась? –
Лично я читал это место как «окна сбрасывает содержимое (только написанные значения) виртуального ini-файла в базовый реальный конец хранилища реестра» –