DOCUMENT:Q68827 06-NOV-1999 [win16sdk] TITLE :Updating Cached Private Profiles (.INI Files) PRODUCT :Microsoft Windows Software Development Kit PROD/VER:WINDOWS:3.0,3.1 OPER/SYS: KEYWORDS:kb16bitonly ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Windows Software Development Kit (SDK) versions 3.0, 3.1 ------------------------------------------------------------------------------- SUMMARY ======= Under Windows version 3.1, the first time a private profile (.INI file) is accessed, the system will call the GetFileTime() API and store this value. The WriteProfileString() API will then call the GetFileTime() API and compare the return value to the stored value. If the two values match, the file is considered valid for two seconds. The function makes the changes and writes the new contents to disk. If the two values do not match, the profile is reread into a buffer and the change is made. The same principle holds true for reading values from a private profile. The reasoning behind the two second limit is that most applications read private profiles in a burst, at application startup, and write in a burst, at application shutdown. The penalty of one read in a twenty read sequence is considered acceptable, given the benefits. In Windows version 3.0, an application that has a private profile will not respond to changes made to that private profile by a text editor. When a text editor updates a private profile, the file on disk is modified. However, GetPrivateProfileString() and GetPrivateProfileInt() do not read from the disk file, instead the functions read from a copy of the file in a cache. WritePrivateProfileString() will update the appropriate sections in both the cached file and the disk file, however, the functions will not reload the disk file into the cache unless the entire cache is invalidated. The information included below discusses how to force a private profile to be recached from a disk file. MORE INFORMATION ================ Windows caches .INI files to reduce access time. This design allows the file to remain in memory until a different .INI file is loaded or until an application forces recaching of the file. To force an .INI file to be recached, make the following call (where is the name of the application's private profile): WritePrivateProfileString(NULL, NULL, NULL, ) This call will force the entire .INI file that is in the cache to be invalidated. The next call to either GetPrivateProfileString() or GetPrivateProfileInt() will cause the disk file to be recached. While .INI files are cached to optimize access time, the following are examples of how and when an .INI file could be recached. 1. The application could update the cache from disk each time the application requires information from the profile. Calling the WritePrivateProfileString function as outlined above would clear the cache. NOTE: Because the file is recached with every access, the benefit of the cache is lost with this method. 2. Create a separate program or function that the user would invoke to explicitly invalidate the cache. The following is some code for that purpose that could be placed into the GENERIC sample application supplied with the Windows Software Development Kit (SDK): BOOL InitInstance(HANDLE hInstance, int nCmdShow) { LPSTR lpApplicationName, lpKeyName, lpDefault, lpReturnedString; int nSize; /* initialize variables */ ... WritePrivateProfileString(NULL, NULL, NULL, "MY.INI"); GetPrivateProfileString(lpApplicationName, lpKeyName, lpDefault, lpReturnedString, nSize, "MY1.INI"); MessageBox(NULL, "Cache Refreshed", szApp, MB_ICONINFORMATION | MB_OK); return TRUE; } Using a program or function like this will cause the .INI file to be recached only when it is changed by an editor, therefore the benefit of the cache is retained. However, it is necessary for the user to call another application or function after the profile is changed with an editor. 3. If neither of these techniques is suitable, the application could check the time and date stamp on the .INI file before each access to see if cache invalidation is necessary. This option provides the benefits of the cache without requiring the user to call another program. The overhead required to read the time and date stamp is minimal compared to recaching the file with every call to either the GetPrivateProfileString or GetPrivateProfileInt functions. Additional query words: no32bit 3.00 3.10 3.x SR# G910109-169 ====================================================================== Keywords : kb16bitonly Technology : kbAudDeveloper kbWin3xSearch kbSDKSearch kbWinSDKSearch kbWinSDK300 kbWinSDK310 Version : WINDOWS:3.0,3.1 ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 1999.