我正在更新一个相当旧的应用程序。它在代码周围使用 INI 文件访问，到处创建和释放 INI 访问类实例。
我想将其集中到多个单个实例，每个使用的文件一个实例。 因此，我们将摆脱在各处创建/释放复制粘贴的实例，并且可以自由地完全替换这些类，这将决定从 INI 切换到其他设置存储。
是否应该调用 WritePrivateProfileString(NULL, NULL, NULL...) 来应用更改？ 假使，假设: 1) 访问直接进入真实的 INI 文件，而不是注册表映射的文件。 2)操作系统是NT系列(可能很少是Win2000，最有可能是WinXP及更高版本)。 Win9x/ReactOS/WinE/Odin/etc 不关心。
那么，我们现在是否应该明确地清除 ini 节省的资金？
NT 不缓存注册表项写入，现在不需要 regFlushKey。 但是 INI 文件呢？
有关 WritePrivateProfileString 的 MSDN 页面仅描述了 Win9x 和 NT 文件到注册表映射的刷新技术。它对真正的 INI 文件保持沉默。
最佳答案
文档自相矛盾(我的粗体):
The system keeps a cached version of the most recent registry file mapping to improve performance. If all parameters are NULL, the function flushes the cache. While the system is editing the cached version of the file, processes that edit the file itself will use the original file until the cache has been cleared.
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 的使用。
为了仔细检查，我在运行 Process Monitor 时调用了 WritePrivateProfileString 。正如预期的那样，Windows 打开 INI 文件，更新它并再次关闭它。
无需冲洗。
关于windows - Windows NT 是否缓存或刷新 INI 文件写入内容？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10912352/