What's the story with INI files < Registry
Mat
What's the story with INI files < Registry
Does anyone know what the argument is for abandoning INI files
in favour of the Registry. Is it true that INI files are somehow
less reliable?
I am presently having some anomalies, where values from the INI file
are picked up only if previously the INI file was written to by
Delphi, and changes from the text editor to the INI file are simply
ignored. I have double, trepple quatrupple checked that the changes
in the ini file are saved and valid. This is very peculiar.
Is there an inherent problem with ini's. I find the advantage that
end-users of the Delphi app can change settings in the INI file
themselves, they could'nt do that with RegEdit, even I'd have
trouble with it. Am I behind the times?
I appreciate when you send me a CC email of your reply. I then
like to respond with a quick thank-you back, particularly if your
reply was so good that it made my day.
M...@lottery.powernet.co.uk. Long Live Borland > M$ GO GO GO
Dave Lacey
Yeh I prefer INI files as well, although I went to a microsoft
conference once a few years ago and they practically told us we weren't
ALLOWED to use ini files any more - we have to use the registry. I guess
in some ways this made me want to use INI files even more :)
But back to your question, I have had similar problems when using the
TIniFile that comes with Delphi (3 and 4 - haven't tried any lower
versions). I've also found that if your ini file gets over a certain
size (say about 50 lines, with some of them being long lines) then
suddenly accessing it slows down to a crawl. This prompted me to write
my own ini file object, which is a pretty simple thing, and actually you
can make it run faster than the Delphi one.
So I'm sorry I can't actually help you with your problem, but I
personally (and it is a personal thing I think) would recommend you
stick with INI files, but just write your own implementation of them ...
this will sort out any problems you are experiencing.
Seeya,
Dave
Earl F. Glynn
news:37525E...@lottery.powernet.co.uk...
> Does anyone know what the argument is for abandoning INI files
> in favour of the Registry. Is it true that INI files are somehow
> less reliable?
Microsoft zealots dump everything into the Registry. IMHO, if you
have data that doesn't need to be shared with another program it
shouldn't be in the registry. I NEVER write application-specific
data to the Registry -- I don't care what Bill Gates says.
> I am presently having some anomalies, where values from the INI file
> are picked up only if previously the INI file was written to by
> Delphi, and changes from the text editor to the INI file are simply
> ignored. I have double, trepple quatrupple checked that the changes
> in the ini file are saved and valid. This is very peculiar.
You've got to "flush" the INI cache:
...
IniFile := TIniFile.Create(Filename);
...
IniFile.Free;
// Flush INI cache
WritePrivateProfileString(NIL, NIL, NIL, pChar(Filename));
efg
_________________________________
efg's Computer Lab: http://www.efg2.com/lab
Delphi Books: http://www.efg2.com/lab/TechBooks/Delphi.htm
Earl F. Glynn E-Mail: Earl...@att.net
Overland Park, KS USA
Mike Orriss (TeamB)
> Does anyone know what the argument is for abandoning INI files
> in favour of the Registry.
>
1) Faster
2) More flexible - you can store binary values, not just strings
3) Better support for multiple users
IMO, whether you use INI files or the Registry, it is important to
allocate default values to every item (the user should be able to
delete an INI file or nuke a Registry entry).
This then makes user settings via the Registry very simple - you do not
need to worry about the actual user as the system takes care of it.
Mike Orriss (TeamB)
(No e-mail replies, please, unless explicitly requested!)
Rose X
registry. At least, the documentation implies that. You can search for
your app name in the registry in order to watch and find out if this is
happening.
Microsoft pushes hard for use of the registry; some folk feel this is
because having information in the registry guarantees that your app is
MS-only. MS argues that information is more organized and quickly
accessed.
Mat wrote:
>
> [Group: Pascal]
>
> What's the story with INI files < Registry
>
> Does anyone know what the argument is for abandoning INI files
> in favour of the Registry. Is it true that INI files are somehow
> less reliable?
>
> I am presently having some anomalies, where values from the INI file
> are picked up only if previously the INI file was written to by
> Delphi, and changes from the text editor to the INI file are simply
> ignored. I have double, trepple quatrupple checked that the changes
> in the ini file are saved and valid. This is very peculiar.
>
J.A. Korten
merge those with the registry!
If you want the code for merging reg-files (without an annoying
confirmation) to the registry just mail me and I will search where left the
code!
Greetings Johan Korten
Philippe Ranger
Does anyone know what the argument is for abandoning INI files
in favour of the Registry. Is it true that INI files are somehow
less reliable?
>>
An excellent question!
Adding to the answers you already got --
What an ini file tries to do, a database would do much better, especially if
it was unique and OS-maintained. No lost ini files, no overwrites, non-text
info, fast access, etc. That's the plan behind the registry. Problem is, as
often happens at MS, the plan was not carried through to finish. Being open
all the time, the registry is a great candidate for corruption -- see Win 98
for late, late workarounds. Yet to come -- a simple user-obvious format for
saving personal settings to a separate file for transfer or
reload-after-reinstall.
Developers' opinions tend to favor the side opposite that which lately has
burned them the most. Great, thank you, great OS maker in Redmond!
PhR
Mat
> > I am presently having some anomalies, where values from the INI file
> > are picked up only if previously the INI file was written to by
> > Delphi, and changes from the text editor to the INI file are simply
> > ignored. I have double, trepple quatrupple checked that the changes
> > in the ini file are saved and valid. This is very peculiar.
>
Matthias Watermann
De...@lottery.powernet.co.uk wrote on 31.05.99 in article <37525E...@lottery.powernet.co.uk>:
> [...]
> I am presently having some anomalies, where values from the INI file
> are picked up only if previously the INI file was written to by
> Delphi, and changes from the text editor to the INI file are simply
> ignored. I have double, trepple quatrupple checked that the changes
> in the ini file are saved and valid. This is very peculiar.
Doing a "flush" before reading an INI-value should do the trick:
Call the API-function 'Write{Private}ProfileString()' with the
first three parms set to NIL.
--
Matthias
Thomas Bruckner
> are picked up only if previously the INI file was written to by
> Delphi, and changes from the text editor to the INI file are simply
> ignored. I have double, trepple quatrupple checked that the changes
> in the ini file are saved and valid. This is very peculiar.
>
I think your problem is that windows caches the ini files. If you have
Delphi 3+ then I believe the TIniFile class has a FlushIni method which you
can call. In Delphi 2 this should do the job:
WritePrivateProfileString(nil, nil, nil, 'MyIni.ini');
Thomas Bruckner
Michael Mitchell
>
> > Does anyone know what the argument is for abandoning INI files
> > in favour of the Registry. Is it true that INI files are somehow
> > less reliable?
>
> If you ever happen to deploy your application on NT Terminal Server, you're
If you load anything large on that bloated pig you deserve what you get.
I also like my whole system being controlled by a single file that can
be
wiped/corrupted and isn't ascii for easy access in a pinch.
Win95 also has a limit on the registry, and when that limit is reached
you cannot even
LOAD another application. Now there's a brilliant solution.
Duncan McNiven
<col...@jersey.net> wrote:
>Win95 also has a limit on the registry, and when that limit is reached
>you cannot even LOAD another application.
Where do you get that information ?
My only reference on the subject ("Inside the Windows 95 Registry" by
Ron Petrusha, pub. O'Reilly) says the registry "has no practical size
limitation, as long as free disk space is available".
Regards,
Duncan
Loren Pechtel
>be
>wiped/corrupted and isn't ascii for easy access in a pinch.
Yeah, windows damaged my registry some months ago. I finally had
to wipe and reinstall in order to get my screen to recognize anything
other than 640x480. I then had to reinstall several programs when all
they had lost was their registry data.
Mike Orriss (TeamB)
> I then had to reinstall several programs when all
> they had lost was their registry data.
>
I use RegEdit to save all important registry keys in order not to have
to do that.
Jean-Francois Nifenecker
That is...?
Cheers,
--
Jean-Francois Nifenecker, Bordeaux (Europe)
jf...@compuserve.com
Mike Orriss (TeamB)
wrote:
> That is...?
>
Mostly keys under HKLM\Software and HKCU\Software relating to
applications where I don't want the pain of re-installing.
James Boyle
> better for that. At least I can copy an ini file from one machine
> installation to another, how do I copy the relevant section of the
> registry.
Using REGEDIT.EXE select the branch to copy and on the menu choose Registry |
Export Registry File. Type a file name like MYPROG.REG. Copy that file to
the target machine. In RegEdit on that machine choose Registry | Import
Registry File and enter the .REG file name. You can also just double click
the .REG file in explorer to import it.
--
Jim
Jim O'Brien
> > Does anyone know what the argument is for abandoning INI files
> > in favour of the Registry.
> >
>
> 2) More flexible - you can store binary values, not just strings
> 3) Better support for multiple users
>
FYI, I prefer INI files for _many_ (but not all) applications, since:
a) they're editable for quick fixes during development
b) it makes an installation portable to another machine by file-copying
c) [most important] even if I multi-boot Win95, Win98 and WinNT, I still have
my configuration (e.g., with Eudora, which uses an INI file).
Regards, Jim.
--
Tue, 01 Jun 1999 16:45 EDT
Jim O'Brien, UnitOOPS Software unit...@remove-this-prefix.unitoops.com
Check out our OLE Drag and Drop Components at <http://www.unitoops.com/>
Browse examples online at <http://www.unitoops.com/uoole/examples/>
Peter Szymiczek
> less reliable?
There is some merit behind using the registry.
If you ever happen to deploy your application on NT Terminal Server, you're
gonna bless the day when you decided to store the settings in the registry. It's
so much simpler: the application settings go to HKEY_LOCAL_MACHINE where access
can be controlled, and the user settings sit in HKEY_CURRENT_USER. There's
little that can go wrong.
If you use ini files in this setup, the personal settings must be stored in
users' home directories, otherwise your users will be overwriting each others
settings, if not corrupting the configuration altogether - do you care to make a
provision for that?
Some administrators will refuse installing your program if they have to manage
ini files, but none of them is fussy about the registry, maybe because most of
them are from the M$ school.
Hope this sheds some light on the subject.
Peter Szymiczek
Peter Szymiczek
> > There is some merit behind using the registry.
> > If you ever happen to deploy your application on NT Terminal Server, you're
>
>
> be
> wiped/corrupted and isn't ascii for easy access in a pinch.
>
> you cannot even
Michael,
Even if your application doesn't use the registry, your machine is equally
vulnerable - it runs a hundred other programs that do. Whether we like it or
not, registry seems to be the standard these days. This doesn't mean that one
should treat it as a poor man's database, which unfortunately is the reality.
Some developers are exposed to the open market, and for them it may be important
to make an educated decision - by betting on a wrong horse they may miss out on
some sales.
Peter Szymiczek
Christopher Latta
an INI file for the system wide options and variables required for log on,
and once the use has logged on, the options they choose are stored in the
registry of their machine (as I have a number of EXEs in my app, and it
would be a pain to log in for each one), and their options they used last
time they used the app are loaded from the database. This means that:
1. All users see the same log on options, so that you don't have to set
up/change these on each machine.
2. The current machine knows the user's selected log on options.
3. A user can log on from anywhere, and the system remembers their
preferences (from the database) from when they were logged on last.
Christopher Latta
>What's the story with INI files < Registry
>
Mat
>
> > Does anyone know what the argument is for abandoning INI files
> > in favour of the Registry. Is it true that INI files are somehow
> > less reliable?
>
> If you ever happen to deploy your application on NT Terminal Server, you're
> so much simpler: the application settings go to HKEY_LOCAL_MACHINE where access
> can be controlled, and the user settings sit in HKEY_CURRENT_USER. There's
> little that can go wrong.
> If you use ini files in this setup, the personal settings must be stored in
> users' home directories, otherwise your users will be overwriting each others
do make provision for that, each user gets his/her own ini file for
personal settings, and a main ini file for the app, how is the registry
better for that. At least I can copy an ini file from one machine
installation to another, how do I copy the relevant section of the
registry.
> settings, if not corrupting the configuration altogether - do you care to make a
> provision for that?
>
Arthur Hoornweg
> are picked up only if previously the INI file was written to by
> Delphi, and changes from the text editor to the INI file are simply
INI files are CACHED by Windows! This makes them rather fast, but
changes made by a text editor aren't always reflected at once...
--
(To answer me, remove the ".net" from my e-mail address)
Arthur M. Hoornweg
Mike Orriss (TeamB)
> c) [most important] even if I multi-boot Win95, Win98 and WinNT, I still have
> my configuration (e.g., with Eudora, which uses an INI file).
>
In that situation, I store options in a database.
For user GUI options though, I stick to the Registry every time.
David
Is there a good internet source of information on the differences between
HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. My app mainly uses
HKEY_CURRENT_USER to store its settings and I've got a nasty feeling this
will provide some challenging results if I should deploy this to an NT
platform. Win95 on local machine doesn't seem to care much.
Thanks,
David
Wayne Niddery (TeamB)
Any settings you want to apply no matter who is logged on then save them in
HKEY_LOCAL_MACHINE.
Any settings you want to allow for individual user preferences, save them in
HKEY_CURRENT_USER.
You don't have to do anything specific to distinguish users, this is
automatic - just read/write your settings the same way no matter who is
logged on to NT.
--
Wayne Niddery - WinWright Consulting
Delphi, C++Builder, JBuilder, InterDev --
http://home.ican.net/~wniddery/RADBooks.html
"It is not true that the function of law is to regulate our consciences, our
ideas, our wills, our education, our opinions, our work, our trade, our
talents or our pleasures. The function of law is to protect the free
exercise of these rights." - Frederic Bastiat, 1850
Jeremiah Model
> Any settings you want to apply no matter who is logged on then save them in
> HKEY_LOCAL_MACHINE.
>
> Any settings you want to allow for individual user preferences, save them in
> HKEY_CURRENT_USER.
>
> You don't have to do anything specific to distinguish users, this is
> automatic - just read/write your settings the same way no matter who is
> logged on to NT.
I've just stumbled into this old thread and found out more about the registry
than I ever found in the documentation I've read. The usual advice I get is,
"stay away from the registry".
I always use ini files because good explanations of the registry are hard to
find, because the frightful warnings I get about the registry scares me off
trying, but mainly because my apps evolved that way from Win 3.x and the
approach still seems to work fine in Win95.
I've controlled system setting versus user settings (stored in the registry,
according to Wayne, in HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, respectively)
by allowing for two ini files:
- the first is stored in the application directory, and is read first. Users
don't have write-access to this.
- the second is stored in the windows directory (per GetWindowsDirectory)
Both are called AppName.ini. My application reads in both ini files, in
sequence, the second overwriting the settings of the first. I store all the
setting in specialized objects so that I never have to reread the ini files
after the app loads.
This has worked very well for me. But maybe it won't work so well in NT or
maybe evern W2K?
...Jerry
bob mackey
>
> I've controlled system setting versus user settings (stored in the registry,
> according to Wayne, in HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, respectively)
> by allowing for two ini files:
> - the first is stored in the application directory, and is read first. Users
> don't have write-access to this.
Do you do something other than attr = readonly for this?
--
bob
myName = 'bobmackey';
myISP = 'annapolis.net';
myaddress := myName + '@' + myISP;
Peter Below (TeamB)
> This has worked very well for me. But maybe it won't work so well in NT or
> maybe evern W2K?
>
It will not work if more than one user works on the same system, each with
his own account. They would have to share the "user" INI file. Delphi makes
working with the registry very painless with its TRegInifile class.
Peter Below (TeamB) 10011...@compuserve.com)
No e-mail responses, please, unless explicitly requested!
Jeremiah Model
Jeremiah Model
> In article <377C0F6A...@mediaone.net>, Jeremiah Model wrote:
> > This has worked very well for me. But maybe it won't work so well in NT or
> > maybe evern W2K?
> >
>
> It will not work if more than one user works on the same system, each with
> his own account. They would have to share the "user" INI file. Delphi makes
> working with the registry very painless with its TRegInifile class.
That's true. But in the LAN environment I work in, everyone has their own
machine, and there is no need for multiple accounts on the same machine.
Mike Orriss (TeamB)
> It is important that if your program requires new users on the workstation
> to get specific 'default' HKCU registry entries, that you also write these
> entries to the HKEY_USERS\Default section.
>
It is much easier to use the Registry with sensible defaults for all values.
With all my programs you can nuke their HKCU keys in order to get back to
the 'factory supplied' defaults. I never bother with the Default Users.
Mike Orriss (TeamB)
(Unless stated otherwise, my replies relate to Delphi 4.03)
(Unsolicited e-mail replies will most likely be ignored)
David Thomas
> Is there a good internet source of information on the differences between
> HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. My app mainly uses
> HKEY_CURRENT_USER to store its settings and I've got a nasty feeling this
> will provide some challenging results if I should deploy this to an NT
> platform. Win95 on local machine doesn't seem to care much.
It is important to understand the purpose of the different areas of the
registry.
Lots of people talk about Machine settings going into HK_LocalMachine (HKLM)
and user settings going into HK_CurrentUser (HKCU).
There are other reasons why this is necessary.
When a user logs in, NT Selects the appropriate registry (from NTUSER.DAT)
and plugs that into HKCU. The user has Full Control Access to the HKCU key.
NT implements Registry Security (very important) and doesn't allow users to
write to HKLM.
Therefore if you put registry entries in HKLM and expect the user to save
settings in there, you can't.
Also remember the purpose of the .DEFAULT User Keys.
This exists in c:\winnt\profiles\default user\ntuser.dat and this contains
registry settings that new users on the system will receive.
It is important that if your program requires new users on the workstation
to get specific 'default' HKCU registry entries, that you also write these
entries to the HKEY_USERS\Default section.
When a user logs on for the first time, the system gives the user the
Current User registry settings from .DEFAULT.
On advanced NT Networks, administrators run login scripts which modify
entries in the HKCU registry based on the Users Current Location,
Workstation, or Group Membership. You can do this with the Kixtart
utilites.
It is very imporant you never save any user settings in HKLM because a user
logging in cannot write to this registry area, and when they login the login
script runs in the context of the user, not in some 'Administrator' context.
Believe it or not, Intel gets this wrong with their Intel Landesk Manager
product and it forces users to have WRITE access to a specific location in
HKLM. This is a major pain and you have to run scripts to change the
permissions on specific areas of HKLM to allow users to have write access...
Microsoft even gets this wrong by putting some settings in HKLM that
DEFINATELY should be in HKCU, things like security zone settings for Users,
there are definite times when different users on the same machine should
have differenet security zone definitions, but you can't control that
dynamically from the login prompt cuz they got it wrong.
Don't forget the role of .DEFAULT.
Have you ever wondered how you can install Microsoft Office on an NT machine
as Administrator, it creates stacks of registry entries in the Administrator
Current User registry, and then you login as a new user and VIOLA! you have
all these Microsoft Office Current User registry settings? Because
Microsoft Office also installs these HKCU entries in .DEFAULT.
There is stacks you can talk about how to use, manipulate, compress,
optimise, control, restrict, and manage registry entries on small to
extremely large networks, but you have to get their roles right. Take it
from someone who gets mighty annoyed when programmers screw up how HKLM and
HKCU should be used, mainly becuase it makes it harder to screw down the
network.
If you have an application which has heavy Registry useage, you should also
think of creating a Policy and Profile .ADM file to allow Network
Administrators easy access to controlling base Registry Settings for all
users on their network for your application. That is another issue.
Cheers,
David Thomas
da...@supporthq.com