Click to Rate and Give Feedback
MSDN
MSDN Library
System Services
Registry
Registry Reference
Registry Functions
 GetPrivateProfileString Function
GetPrivateProfileString Function

Retrieves a string from the specified section in an initialization file.

Note  This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry.

Syntax

DWORD WINAPI GetPrivateProfileString(
  __in   LPCTSTR lpAppName,
  __in   LPCTSTR lpKeyName,
  __in   LPCTSTR lpDefault,
  __out  LPTSTR lpReturnedString,
  __in   DWORD nSize,
  __in   LPCTSTR lpFileName
);

Parameters

lpAppName [in]

The name of the section containing the key name. If this parameter is NULL, the GetPrivateProfileString function copies all section names in the file to the supplied buffer.

lpKeyName [in]

The name of the key whose associated string is to be retrieved. If this parameter is NULL, all key names in the section specified by the lpAppName parameter are copied to the buffer specified by the lpReturnedString parameter.

lpDefault [in]

A default string. If the lpKeyName key cannot be found in the initialization file, GetPrivateProfileString copies the default string to the lpReturnedString buffer. If this parameter is NULL, the default is an empty string, "".

Avoid specifying a default string with trailing blank characters. The function inserts a null character in the lpReturnedString buffer to strip any trailing blanks.

lpReturnedString [out]

A pointer to the buffer that receives the retrieved string.

nSize [in]

The size of the buffer pointed to by the lpReturnedString parameter, in characters.

lpFileName [in]

The name of the initialization file. If this parameter does not contain a full path to the file, the system searches for the file in the Windows directory.

Return Value

The return value is the number of characters copied to the buffer, not including the terminating null character.

If neither lpAppName nor lpKeyName is NULL and the supplied destination buffer is too small to hold the requested string, the string is truncated and followed by a null character, and the return value is equal to nSize minus one.

If either lpAppName or lpKeyName is NULL and the supplied destination buffer is too small to hold all the strings, the last string is truncated and followed by two null characters. In this case, the return value is equal to nSize minus two.

Remarks

The GetPrivateProfileString function searches the specified initialization file for a key that matches the name specified by the lpKeyName parameter under the section heading specified by the lpAppName parameter. If it finds the key, the function copies the corresponding string to the buffer. If the key does not exist, the function copies the default character string specified by the lpDefault parameter. A section in the initialization file must have the following form:

[section]
key=string
      .
      .
      .

If lpAppName is NULL, GetPrivateProfileString copies all section names in the specified file to the supplied buffer. If lpKeyName is NULL, the function copies all key names in the specified section to the supplied buffer. An application can use this method to enumerate all of the sections and keys in a file. In either case, each string is followed by a null character and the final string is followed by a second null character. If the supplied destination buffer is too small to hold all the strings, the last string is truncated and followed by two null characters.

If the string associated with lpKeyName is enclosed in single or double quotation marks, the marks are discarded when the GetPrivateProfileString function retrieves the string.

The GetPrivateProfileString function is not case-sensitive; the strings can be a combination of uppercase and lowercase letters.

To retrieve a string from the Win.ini file, use the GetProfileString function.

The system maps most .ini file references to the registry, using the mapping defined under the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
     CurrentVersion\IniFileMapping

This mapping is likely if an application modifies system-component initialization files, such as Control.ini, System.ini, and Winfile.ini. In these cases, the function retrieves information from the registry, not from the initialization file; the change in the storage location has no effect on the function's behavior.

The profile functions use the following steps to locate initialization information:

  1. Look in the registry for the name of the initialization file under the IniFileMapping key.
  2. Look for the section name specified by lpAppName. This will be a named value under the key that has the name of the initialization file, or a subkey with this name, or the name will not exist as either a value or subkey.
  3. If the section name specified by lpAppName is a named value, then that value specifies where in the registry you will find the keys for the section.
  4. If the section name specified by lpAppName is a subkey, then named values under that subkey specify where in the registry you will find the keys for the section. If the key you are looking for does not exist as a named value, then there will be an unnamed value (shown as <No Name>) that specifies the default location in the registry where you will find the key.
  5. If the section name specified by lpAppName does not exist as a named value or as a subkey, then there will be an unnamed value (shown as <No Name>) that specifies the default location in the registry where you will find the keys for the section.
  6. If there is no subkey or entry for the section name, then look for the actual initialization file on the disk and read its contents.

When looking at values in the registry that specify other registry locations, there are several prefixes that change the behavior of the .ini file mapping:

  • ! - this character forces all writes to go both to the registry and to the .ini file on disk.
  • # - this character causes the registry value to be set to the value in the Windows 3.1 .ini file when a new user logs in for the first time after setup.
  • @ - this character prevents any reads from going to the .ini file on disk if the requested data is not found in the registry.
  • USR: - this prefix stands for HKEY_CURRENT_USER, and the text after the prefix is relative to that key.
  • SYS: - this prefix stands for HKEY_LOCAL_MACHINE\SOFTWARE, and the text after the prefix is relative to that key.

Requirements

Client Requires Windows Vista, Windows XP, or Windows 2000 Professional.
Server Requires Windows Server 2008, Windows Server 2003, or Windows 2000 Server.
Header

Declared in Winbase.h; include Windows.h.

Library

Use Kernel32.lib.

DLL

Requires Kernel32.dll.

Unicode/ANSI

Implemented as GetPrivateProfileStringW (Unicode) and GetPrivateProfileStringA (ANSI).

See Also

GetProfileString
WritePrivateProfileString


Send comments about this topic to Microsoft

Build date: 8/14/2008

Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
ini files vr windows registry      eadthem   |   Edit   |  
strongly consider using .ini files instead of windows registry

registry is a dangerous thing that is only friend to viruses and spyware

ini files are simple plain text and easy to read and no risk of damaging another program long as you stick to your ini file in your programs directory

if ini is such a evil windows 16bit thing then perhaps you may want to look in to xml witch is more complex and a little more flexible and likely wont work first try unlike ini file
Tags What's this?: Add a tag
Flag as ContentBug
This whole ini vs registry is interesting;      clearrock   |   Edit   |  
Some time ago ms 'recommended' that we use the reg rather than ini.
Reg is better for me as it is more 'Hidden' from the user. I can make easy use of User / Machine data etc.. but with Vista that has all gone crazy. Now I'm being told that the reg is 'registry is a dangerous thing that is only friend to viruses and spyware' to what end then is my ini LESS prone to the same problem. Can ms work out a way that bonafide developers can still easily access HKEY_L_M at a sensible cost.
Tags What's this?: Add a tag
Flag as ContentBug
Application access to HKLM      CarolBuchmiller - MSFT   |   Edit   |  

Assuming that setup for an application runs at elevated security level, it is possible to change the default security descriptor for the HKEY_LOCAL_MACHINE\Software\[My Company]\[My App] key (or subkey) using the RegSetKeySecurity function.

Tags What's this?: Add a tag
Flag as ContentBug
Does GetPrivateProfileString open file for each request      leeclements   |   Edit   |  

I am using GetPrivateProfileString to retrieve values from an INI file, however, does the windows os keep the file open for subsequent requests until the owning process is terminated or does it open the file each time and begin searching from the top?

The reason I ask is that the INI file in question has been modified to include multiple sections with the same name and I want to understand how the API would handle this before we correct it - as this has an impact on our reporting.

Any thoughs are appreciated.

Lee

Tags What's this?: Add a tag
Flag as ContentBug
"registry is a dangerous thing that is only friend to viruses and spyware" ???      Ometochtli   |   Edit   |  
eadthem: "registry is a dangerous thing that is only friend to viruses and spyware"
That's ridiculous.. who told you that? The registry is like having all your ini files in one place instead of scattered all over the place. There are advantages and disadvantages to both methods, but your statement has absolutely no merit.
Tags What's this?: Add a tag
Flag as ContentBug
@Eadthem      Maintex   |   Edit   |  
Could not disagree more with you eadthem.

Registry is not a dangerous thing for a developer, it is extremely useful. The only way I would bend on this is to say that it is dangerous for a user, but if you did your coding right, your installation package right and your interfaces efficiently, the user should not need to even know about the registry.

And exactly how is the registry only a friend to viruses and spyware? What difference in use do they have to normal applications? I fail to see how they help viruses more than valid applications? I expect you will argue that the registry allows viruses to attack the settings of other applications - again, if you do your coding right; you can set up security on your application's keys. Then again, even if you did not set security on your keys, how is it any different to a virus attacking your ini file?

I can only surmise that your statements are completely without merit - please prove me wrong if you can though as I would be interested to see your reasoning.

Now, for some useful information from my point of view:

INI Files are ok, but i'd only use them if I could not use the registry for some reason or I knew that the application was to be used in an environment where the application could be copied from one machine to another fairly regularly (i.e. server to client) without going through an update or installation procedure. Even then, you could still do it with a registry update procedure within the application start code (reading and updating the registry based on an updated .reg file within the application directory).

The registry is probably the best way of storing settings for your application, but the problem with this is that it is not very easy to do (unless you have written/got a class to do the work for you in your application) and it is not very portable. However, most backups make a backup of the registry and this is another big benefit, on a restore of a stuffed up machine, you get your full settings back for your application (as long as the installation procedure of your app does not reset them to defaults ;) ). As for security, that can be set up and is more secure than an INI file but not 100% secure. I know that someone will counter my portability argument with exporting and importing of trees within the registry - which is true, but when I think of portability in a worst case scenario, I think of the user or some semi-technical guy on site doing the copying - and would you really want them to be tinkering with the registry or having to guide them over the phone how to do the importing and exporting?

Ok, now to XML files. Personally, I think XML files are great, but I'm not sure I'd want to store my settings in them. They are good for transporting information across a network such as the internet (even if it needs to be secured because encrypting information is relatively easy using the .NET framework and XML files). A lot of the latest programming languages now support XML files and features and provide access to read and write them much more easily than we ever had with INI files. I guess it is down to personal preference with XML files and settings - to me, they seem a bit of an overkill for simple settings.

Finally, databases. Why have these not been mentioned I wonder? I think every medium to large scale application should use for settings - when the database is in a centralised location. Your application data and user settings should all be in here - it is easily maintained, backed up, replicated, modified, read, written and can be extremely secure. If there was any chance to use a database - I would go for that option any day.

To summarise this very, very long submission: for a small scale application I would use the registry and make sure your application was very well designed, well coded and flexible/adaptable (that's how every project should be anyway). For a medium to large scale application - without a doubt - use a database.
Tags What's this?: null (x) Add a tag
Flag as ContentBug
Processing
© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Page view tracker