les_stockton
2nd January 2002 23:09 UTC
WriteIniStr wont work completely on NT
I've tested this on several systems, XP, Windows 2000, 98, ME and even 95. WriteIniStr will allow me to write to the drivers32 section of the system.ini file, but not on NT. I can write to a new section, but not to an existing section such as mci. drivers32 section doesn't exist under NT4 and WriteIniStr wont create one. If I create one, it still wont write to it.
The only thing I've been able to do is to write a dummy section just for testing.
Does anyone know how to solve this problem?
dbareis
3rd January 2002 08:03 UTC
Re: WriteIniStr wont work completely on NT
Have you tried manually creating these in regedit to prove it is not a security issue?
les_stockton
3rd January 2002 14:42 UTC
why?
I'm not sure I understand. Why would I use regedit to write to the system.ini file?
Repzilon
3rd January 2002 14:55 UTC
system.ini and win.ini are legacy from Windows 3.x and are used only on "crashy" Windows Kernels (9x, Me). On NT Kernels (NT4, 2000, XP all editions), their settings are mapped to registry.
And for one of these 2 files (I do not remember which one), there are special versions of API fonctions:
Normal / Special
GetPrivateProfileString / GetProfileString
GetPrivateProfileInt / GetProfileInt
GetPrivateProfileSection / GetProfileSection
les_stockton
3rd January 2002 15:16 UTC
understood
Understood. However, I'm hoping to write to system.ini because I'm using MCI for video, and I'm stuck using it because of the software I have, which I can't replace just yet. As it is, MCI uses system.ini unless they've updated it, which I doubt.
If it has been mapped to the registry, where does the mci section and the driver32 section get mapped?
Repzilon
3rd January 2002 15:30 UTC
Form Visual C++ 5.0 Help :
The GetProfileString function retrieves the string associated with the specified key in the given section of the WIN.INI file. This function is provided for compatibility with 16-bit Windows-based applications. Win32-based applications should store initialization information in the registry.
DWORD GetProfileString( LPCTSTR lpAppName,
// address of section name
LPCTSTR lpKeyName,
// address of key name
LPCTSTR lpDefault,
// address of default string
LPTSTR lpReturnedString,
// address of destination buffer
DWORD nSize
// size of destination buffer
);
Parameters
lpAppName
Pointer to a null-terminated string that specifies the section containing the key. If this parameter is NULL, the function copies all section names in the file to the supplied buffer.
lpKeyName
Pointer to a null-terminated string containing the key name whose associated string is to be retrieved. If this parameter is NULL, the function copies all keys in the given section to the supplied buffer. Each string is followed by a null character, and the final string is followed by a second null character.
lpDefault
Pointer to a null-terminated default string. If the lpKeyName key cannot be found in the initialization file, GetPrivateProfileString copies the default string to the lpReturnedString buffer. This parameter cannot be NULL.
Avoid specifying a default string with trailing blank characters. The function inserts a null character in the lpReturnedString buffer to strip any trailing blanks.
Windows 95: Although lpDefault is declared as a constant parameter, Windows 95 strips any trailing blanks by inserting a null character into the lpDefault string before copying it to the lpReturnedString buffer.
Windows NT: Windows NT does not modify the lpDefault string. This means that if the default string contains trailing blanks, the lpReturnedString and lpDefault strings will not match when compared using the lstrcmp function.
lpReturnedString
Pointer to a buffer that receives the character string.
nSize
Specifies the size, in characters, of the buffer pointed to by the lpReturnedString parameter.
Return Values
If the function succeeds, the return value is the number of characters copied to the buffer, not including the null-terminating 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
If the string associated with the lpKeyName parameter is enclosed in single or double quotation marks, the marks are discarded when the GetProfileString function returns the string.
The GetProfileString function is not case-sensitive; the strings can contain a combination of uppercase and lowercase letters.
A section in the WIN.INI file must have the following form:
[section]
key=string
.
.
.
An application can use the GetPrivateProfileString function to retrieve a string from a specified initialization file.
The lpDefault parameter must point to a valid string, even if the string is empty (that is, even if its first character is a null character).
Windows NT:
Calls to profile functions may be mapped to the registry instead of to the initialization files. This mapping occurs when the initialization file and section are specified in the registry under the following keys:
HKEY_LOCAL_MACHINE\Software\Microsoft\
Windows NT\CurrentVersion\IniFileMapping
When the operation has been mapped, the GetProfileString 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 Win32 Profile functions (Get/WriteProfile*, Get/WritePrivateProfile*) use the following steps to locate initialization information:
1. Look in the registry for the name of the initialization file, say myfile.ini, under IniFileMapping:
HKEY_LOCAL_MACHINE\Software\Microsoft\
Windows NT\CurrentVersion\IniFileMapping\myfile.ini
2. Look for the section name specified by lpAppName. This will be a named value under myfile.ini, or a subkey of myfile.ini, or will not exist.
3. If the section name specified by lpAppName is a named value under myfile.ini, 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 of myfile.ini, 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 under myfile.ini, then there will be an unnamed value (shown as "<No Name>") under myfile.ini that specifies the default location in the registry where you will find the keys for the section.
6. If there is no subkey for myfile.ini, or if there is no entry for the section name, then look for the actual myfile.ini 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.