Asp Forum - GetPrivateProfileString and IniFileMapping Registry Key

unknown

5/3/2012 8:07:00 PM

If two developers called their INI file "CONFIG.INI" or "SETTINGS.INI"and
put it in their own private folder, say under APPDATA, and one mapped his
INI file to the registry, would the other product stop working and get
mostly default values?

From MSDN, it seem so, especially if they also used the same section names,
like [Config], or [Settings] :

GetPrivateProfileString function:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724353%28v=vs....

8 Answers

GS

5/3/2012 9:08:00 PM

Farnsworth pretended :
> If two developers called their INI file "CONFIG.INI" or "SETTINGS.INI"and put
> it in their own private folder, say under APPDATA, and one mapped his INI
> file to the registry, would the other product stop working and get mostly
> default values?
>
> From MSDN, it seem so, especially if they also used the same section names,
> like [Config], or [Settings] :
>
> GetPrivateProfileString function:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724353%28v=vs....

Not sure what you mean by "mapped his INI file to the Registry". My
understanding is that we use one OR the other, and if using INI files
then it should go in the app's folder that has write access.

Also, calls made to the Registry are handled by different APIs than
calls made to INI files. I expect our apps will access the stored data
according to which API wrappers they use. Since both are in separate
places I don't see how there would be a conflict that would cause an
app to stop working!

IOW, settings stored in the Registry are separate from settings stored
in an INI file. One developer is not going to look for his INI file OR
Registry keys in another developer's folder[s] OR Registry keys,
...normally!<g>

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

GS

5/3/2012 9:17:00 PM

Just for clarity...

I stopped using the Registry when I started addressing client demands
for portable apps. I now run reg-free via manifests and every app has
its own 'app.ini' file AND 'app.dat' and/or 'config.dat' and I've never
had any issues with accessing those files even with multiple instances
of the same app running.

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

unknown

5/4/2012 2:11:00 AM

"GS" <gs@somewhere.net> wrote in message news:jnus3g$fjk$1@dont-email.me...
> Farnsworth pretended :
>> If two developers called their INI file "CONFIG.INI" or "SETTINGS.INI"and
>> put it in their own private folder, say under APPDATA, and one mapped his
>> INI file to the registry, would the other product stop working and get
>> mostly default values?
>>
>> From MSDN, it seem so, especially if they also used the same section
>> names, like [Config], or [Settings] :
>>
>> GetPrivateProfileString function:
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724353%28v=vs....
>
> Not sure what you mean by "mapped his INI file to the Registry". My
> understanding is that we use one OR the other, and if using INI files then
> it should go in the app's folder that has write access.
>
> Also, calls made to the Registry are handled by different APIs than calls
> made to INI files. I expect our apps will access the stored data according
> to which API wrappers they use. Since both are in separate places I don't
> see how there would be a conflict that would cause an app to stop working!
>
> IOW, settings stored in the Registry are separate from settings stored in
> an INI file. One developer is not going to look for his INI file OR
> Registry keys in another developer's folder[s] OR Registry keys,
> ..normally!<g>
>
> --
> Garry

In the link I posted, look for "IniFileMapping". There are 6 items listed.
Start reading from the last one. Basically Windows redirects to the registry
if the file name is listed under the IniFileMapping subkey. The INI file
path doesn't seem to matter, just the file name only.

Ralph

5/4/2012 3:49:00 AM

On Thu, 3 May 2012 22:10:58 -0400, "Farnsworth" <nospam@nospam.com>
wrote:

>"GS" <gs@somewhere.net> wrote in message news:jnus3g$fjk$1@dont-email.me...
>> Farnsworth pretended :
>>> If two developers called their INI file "CONFIG.INI" or "SETTINGS.INI"and
>>> put it in their own private folder, say under APPDATA, and one mapped his
>>> INI file to the registry, would the other product stop working and get
>>> mostly default values?
>>>
>>> From MSDN, it seem so, especially if they also used the same section
>>> names, like [Config], or [Settings] :
>>>
>>> GetPrivateProfileString function:
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724353%28v=vs....
>>
>> Not sure what you mean by "mapped his INI file to the Registry". My
>> understanding is that we use one OR the other, and if using INI files then
>> it should go in the app's folder that has write access.
>>
>> Also, calls made to the Registry are handled by different APIs than calls
>> made to INI files. I expect our apps will access the stored data according
>> to which API wrappers they use. Since both are in separate places I don't
>> see how there would be a conflict that would cause an app to stop working!
>>
>> IOW, settings stored in the Registry are separate from settings stored in
>> an INI file. One developer is not going to look for his INI file OR
>> Registry keys in another developer's folder[s] OR Registry keys,
>> ..normally!<g>
>>
>> --
>> Garry
>
>In the link I posted, look for "IniFileMapping". There are 6 items listed.
>Start reading from the last one. Basically Windows redirects to the registry
>if the file name is listed under the IniFileMapping subkey. The INI file
>path doesn't seem to matter, just the file name only.
>

That is a feature! <g>

Since Windows 286 there has been magic associated with the files
CONFIG.INI, SYSTEM.INI, and WIN.INI. Any developer opting to use those
names for their own purpose was headed for trouble.

Previous to 32-bit Windows, developers not only regularly used these
files for their application data but were encouraged to do so. With
32-bit Windows developers were encourage to abandon these INI files
(actually all INI files). The problem was they were also used for
"Windows Stuff" (another highly technical term. <g>), and for awhile
there you had programs living in both worlds.

This behavior by GetPrivateProfileString was really a rather niffy bit
of backward-compatibility by MS - back when they cared about such
things.

-ralph

GS

5/4/2012 6:51:00 AM

Farnsworth used his keyboard to write :
> "GS" <gs@somewhere.net> wrote in message news:jnus3g$fjk$1@dont-email.me...
>> Farnsworth pretended :
>>> If two developers called their INI file "CONFIG.INI" or "SETTINGS.INI"and
>>> put it in their own private folder, say under APPDATA, and one mapped his
>>> INI file to the registry, would the other product stop working and get
>>> mostly default values?
>>>
>>> From MSDN, it seem so, especially if they also used the same section
>>> names, like [Config], or [Settings] :
>>>
>>> GetPrivateProfileString function:
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724353%28v=vs....
>>
>> Not sure what you mean by "mapped his INI file to the Registry". My
>> understanding is that we use one OR the other, and if using INI files then
>> it should go in the app's folder that has write access.
>>
>> Also, calls made to the Registry are handled by different APIs than calls
>> made to INI files. I expect our apps will access the stored data according
>> to which API wrappers they use. Since both are in separate places I don't
>> see how there would be a conflict that would cause an app to stop working!
>>
>> IOW, settings stored in the Registry are separate from settings stored in
>> an INI file. One developer is not going to look for his INI file OR
>> Registry keys in another developer's folder[s] OR Registry keys,
>> ..normally!<g>
>>
>> -- Garry
>
> In the link I posted, look for "IniFileMapping". There are 6 items listed.
> Start reading from the last one. Basically Windows redirects to the registry
> if the file name is listed under the IniFileMapping subkey. The INI file path
> doesn't seem to matter, just the file name only.

Okay, I get it! Sounds like a useless and convoluted process to me.
Can't imagine why anyone would want to go there. The context of the
article seems to align with Ralph's contribution. I remember win.ini
back in Win3.1 days, but don't know why anyone would implement this
with current apps. IMO any app old enough to be using this concept is
probably just around for nostalgic purposes. Interesting, though,
nonetheless...

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

ObiWan

5/4/2012 6:57:00 AM

> If two developers called their INI file "CONFIG.INI" or
> "SETTINGS.INI"and put it in their own private folder, say under
> APPDATA, and one mapped his INI file to the registry, would the other
> product stop working and get mostly default values?

Uhm... let's see if I understood; you're saying that you have two
different apps, say "foo.exe" and "bar.exe" installed into their own
folders but storing their stuff into INI files; both apps use
"config.ini" as the name for its INI file and such an INI file is
stored under APPDATA ... well, if you don't use APPDATA\AppName as the
path then... yes, basically the two apps will be pointing to the same
file (mapped to registry or not), and this will royally screw things

This is why you should use APPDATA\AppName to store the settings, this
way each app will store its stuff inside its own APPDATA subfolder and
having INI files (mapped or not) with the same name won't cause issues;
as a note, if you decide to go for INI file, it's a good idea storing
the application "global" settings into an INI file sitting inside the
app own folder and using a second INI file in APPDATA\AppName to store
the user specific settings; in this case, referring to the two apps
above, you may have

C:\Program Files\foo\config.ini
%APPDATA%\foo\config.ini

and

C:\Program Files\bar\config.ini
%APPDATA%\bar\config.ini

and, as you see, the two INI files (be those mapped to the registry or
not) won't "overwrite" each other

> From MSDN, it seem so, especially if they also used the same section
> names, like [Config], or [Settings] :

Nope, the API asks for the INI pathname so if the path is different the
mapping will go to a different area of the registry

unknown

5/4/2012 5:43:00 PM

"ObiWan" <alb.20.trashsink@spamgourmet.com> wrote in message
news:20120504085703.000051a9@deathstar.mil...
>
>> If two developers called their INI file "CONFIG.INI" or
>> "SETTINGS.INI"and put it in their own private folder, say under
>> APPDATA, and one mapped his INI file to the registry, would the other
>> product stop working and get mostly default values?
>
> Uhm... let's see if I understood; you're saying that you have two
> different apps, say "foo.exe" and "bar.exe" installed into their own
> folders but storing their stuff into INI files; both apps use
> "config.ini" as the name for its INI file and such an INI file is
> stored under APPDATA ... well, if you don't use APPDATA\AppName as the
> path then... yes, basically the two apps will be pointing to the same
> file (mapped to registry or not), and this will royally screw things

What I was suggesting is that the two INI files are in two different
subfolders under APPDATA.

>> From MSDN, it seem so, especially if they also used the same section
>> names, like [Config], or [Settings] :
>
> Nope, the API asks for the INI pathname so if the path is different the
> mapping will go to a different area of the registry

MSDN says otherwise. The full path is "don't care", and just the file name
is used. Please look in the registry under the subkey below to see the file
names. No path information are used! I haven't tested this, so I am not 100%
sure.

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

Ralph

5/4/2012 7:47:00 PM

On Fri, 4 May 2012 13:43:01 -0400, "Farnsworth" <nospam@nospam.com>
wrote:

>>
>> Nope, the API asks for the INI pathname so if the path is different the
>> mapping will go to a different area of the registry
>
>MSDN says otherwise. The full path is "don't care", and just the file name
>is used. Please look in the registry under the subkey below to see the file
>names. No path information are used! I haven't tested this, so I am not 100%
>sure.
>
>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
>NT\CurrentVersion\IniFileMapping
>

You are correct Path is ignored when accessing these files, which made
sense in creating such a mechanism since there is to be one, and only
one, instance of each of these files on a box. This helped to sure
that.

This was not just for 3rd party application developers but for use by
Microsoft applications and utilities as well. (Back then they were not
only backward-compatible, but also tended to eat what they cooked.)

Historically 16-bit Windows provided two separate 'groups' of
Get/Write Profile data. One was for the important "Public" files
(box-wide), the other, for "Private" ones (user/instance-wide). For
example, GetProfileString() didn't accept either an INI name or path -
it was assumed to read WIN.INI, so only the Section/Appname and Key
needed to be provided. The IniFileMapping entry made it very easy for
application code to transverse the Ini/Registry changes -
GetProfileString fetches the data no matter how it is stored.

In the 'fix' Microsoft made all the other INI functions unnecessary.
GetPrivateProfileString and WritePrivateProfileString provides all the
functionality you need for managing your own files.

-ralph

microsoft.public.vb.general.discussion

GetPrivateProfileString and IniFileMapping Registry Key

unknown

GS

GS

unknown

Ralph

GS

ObiWan

unknown

Ralph

x Login to ForumsZone