Windows NT是否缓存或刷新INI文件写入？

我正在更新一个相当旧的应用程序。它使用INI文件访问所有代码，在这里和那里创建和释放INI访问类实例

我想将其集中到几个单独的实例，每个使用的文件一个。 因此，我们将摆脱创建/释放粘贴在任何地方的副本的实例，并有完全替换这些类的自由，这将是从INI切换到其他存储设置的决定

是否应该调用WritePrivateProfileString（NULL，NULL，NULL…）来应用更改？ 假设： 1） 访问权限直接进入真实的INI文件，而不是注册表映射的文件。 2） 操作系统属于NT系列（可能很少使用Win2000，最有可能是WinXP及更高版本）。Win9x/ReactOS/WinE/Odin/etc不受关注

那么，我们现在是否应该明确地冲销ini节约

NT不缓存注册表项写入，现在不需要重新注册FlushKey。 但是INI文件呢

---

MSDN页面关于WritePrivateProfileString仅介绍刷新技术wrt Win9x和NT文件到Reg的映射。对于真实的INI文件，它是沉默的。

文档自相矛盾（我的粗体）：

系统保留最新的注册表文件映射的缓存版本，以提高性能。如果所有参数都为NULL，则函数将刷新缓存。当系统编辑文件的缓存版本时，编辑文件本身的进程将使用原始文件，直到清除缓存

Windows正在缓存映射还是文件（什么文件）？但示例代码中的注释清楚地表明：

// Force the system to read the mapping into shared memory 
// so that future invocations of the application will see it 
// without the user having to reboot the system

缓存的是注册表文件映射。如果更改注册表中的映射，则需要告诉Windows刷新其缓存

这也与Windows 3.1中API的使用一致，在Windows 3.1中，您不需要刷新任何内容。Windows不太可能从根本上改变API的使用

为了再次检查，我在运行时调用了

WritePrivateProfileString

。正如预期的那样，Windows会打开INI文件，进行更新，然后再次关闭它

---

不需要刷新。

在Windows NT中，注册表由多个物理文件组成。是的，我希望它在NT中更改，就像注册表写入一样。ProcMon是一个很好的提示，但它不能证明。只是因为我们模拟了一个任务环境，如果Windows磁盘不忙，它会刷新缓存，为什么不呢。但是如果多个线程/程序更新了同一个文件呢？如果程序严重崩溃怎么办？就我个人而言，我读过类似“windows将虚拟ini文件的内容（只是写入的值）刷新到底层real registry存储后端”这样的地方，我是否误解了你的问题？你不是在使用真正的INI文件吗？那你为什么关心注册表是如何实现的呢？示例代码中的注释强烈暗示它是正在缓存的映射，因为刷新是在创建映射之后以及调用

WritePrivateProfileString

之前完成的。我猜这个函数是在用户模式下运行的，所以如果你的应用程序在错误的时间严重崩溃，你可能会得到一个损坏的INI文件。最后，INI写入总是立即可用；添加一个未记录的缓存将打破这一假设。我不“在乎”，我只是用它来暗示NT系列在其9x系列的优先级上有多大的不同。但这样一个突破性的假设对95/98有效。