Archived

This topic is now archived and is closed to further replies.

medovid

Registry or .ini file

Recommended Posts

Where should I store my program data the registrty or a .ini file or is there any other better options. I heard rummers that the registry is an old technoolgy and is slowly becoming obsolete and that it is preferable to write in a .ini file but I would like to confirm this Thanks,

Share this post


Link to post
Share on other sites
I would say absolutely registry. Big thing to think of is multi-user environments. If you use an ini, everyone using that program has the same settings. If one person changes it, it changes for everyone. If you use the registry it will be user independant. I actually ran into an annoying instance of this just yesterday. And where did you hear that the registry is old technology? The registry came after ini''s did, so ini''s are old technology. And if you want to get technical, to be a "Designed for Windows" product, you have to store you information in the registry.

Always remember, you''''re unique. Just like everyone else.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Pleaes god don''t put it in the registry.

If you *really* want to design for multiple users, make inherent profiles in your games or store your configuration files in the "Documents and Settings" folder and make sure to REMOVE IT ON AN UNINSTALL!

There are far too many programs out there that just leave stuff in the registry, making it one of the biggest sources of bloat in the windows OS. At least IMO.

Share this post


Link to post
Share on other sites
ini files all the way. I hate games that add stuff in the registry, particularly settings (I can deal with a CD key, or something of that sort) because when I format my drive with windows on it I lose all my settings.

Share this post


Link to post
Share on other sites
i'll give a few pros and cons for each.

registry:
+ storing settings in hkey_current_user makes them multiuser-safe, as mentioned above. no special effort is required.
+ registry can store binary data.
+ registry supports hierarchical data storage, ini files only linear.
+ is supposed to be faster than ini files.
- generally requires more code (as in more function calls to make). also, registry code should check for errors to prevent access violations while ini code most often does not.
- harder to change settings by hand, especially if they are stored as binary.
- harder to transfer settings from one machine to another. note that nothing prevents you from writing a function to grab all settings from registry and dump them to a .reg file that can be very easily merged with the registry on another computer.

ini files:
+ very easy to hand-edit.
+ generally simpler to use, because you can ignore error returns without crashing your program (potentially), you 'll just lose your settings. this is because you access no handles like registry code does. there are also only three functions to learn. the more lazy programmers prefer ini files.
+ easily copied around.
- supposedly slower because each function call must open ini file, find section, find key, read/update its value, close the file.
- cannot store binary data, unless you convert them to a text representation.

choose yourself. i generally use ini files when i plan on using notepad to edit my settings or when i'm lazy, and registry for the rest.

edit: oops, easy copying of ini files is a plus.

[edited by - niyaw on September 2, 2002 4:50:07 PM]

Share this post


Link to post
Share on other sites
Never ever ever use the registry unless you also include a sepearte utility available somewhere that will clean out what your program put in. Being able to uninstall isnt good enough, because it can fail and then the registry will be left full of needless crap (but uninstall should also clean it out). I'm tired of my registry growing HUGE because the author of every app everywhere thought that adding 50k to my registry and leaving it there was fine.

Also, somebody suggested you can store binary data in the registry and not in an INI. If you need to store binary data in an INI (and dont expect a user to edit it), just use base 64 mime encoding. Really though, if you want to store binary data, you should probably use a custom format.

"The Requested Information Is Unknown Or Classified" -Anonymous

[edited by - Extrarius on September 2, 2002 11:36:23 AM]

Share this post


Link to post
Share on other sites
I''m confused... Everyone keeps saying one of the main reasons not to use the registry is the size of the registry. Are you really worried about 50K of space being used? Also, havn''t you ever heard of regclean? And when you talk about the uninstall not removing it all, what install program are you using that it doesn''t remove the registry key for the app? I use InstallShield or Wise Install Master and I edit the code by hand to make sure it is all removed. Someone also said that they don''t like loosing their settings when they reinstall Windows, your supposed to! When you reinstall Windows any application that gets installed should be reinstalled. That way any files that they put into the system can be removed. If you reinstall Windows and don''t have to reinstall, there is no way to know for sure if you remove all the files. Unless of course it''s a simple zip file install where you simply unzip to a folder.

I niyaw is correct on his points. For big games, I think a combination of ini and registry is the way to go. You need multiuser support in games. Nothing pisses me off more than coming back to Q3 and having to remap all my keys because someone else played. Although I have to disagree with one of his points that it takes more code. If you get a nice Registry wrapper class it''s the same code as an ini. In fact, I''ve seen wrappers that can switch between ini and registry so it''s invisible to the program which your using. That way debuging can be from an ini, release can be registry.

Of course, one of my points still stands. If you ever want to sell your software, and you want to have the "Designed for Windows" logo on the package, you have to use the registry. It''s one of the requirements.

Always remember, you''''re unique. Just like everyone else.

Share this post


Link to post
Share on other sites
Greven: No, 50k isnt a problem, but I don''t only install one application. Since I only reformat when my computer gets unstable, it doesnt happen very often. I install and uninstall demos, examples, utilities, etc all the time, and the ones that don''t clean up after themselves end up taking up KB, then MB, and then GB and wasted space isnt a good thing. Programs like regclean can only clean out a very, very small portion of the registry. Cleaning up entries for COM objects that no longer exist etc is a good thing, but it doesnt fix the problem.

You must be one of the few developers that does that, because even most professional apps leave their registry entries in software settings and I have to manually delete them all the time after uninstallation. I think they do that to allow you to keep your settings after an uninstall and reinstall of the app, but they should at least provide a checkbos on uninstall. Most of the time, the programs will delete keys like "InstalledFrom" "InstallDrive" and things like that, but not the 50-100 settings for small things like the bcakground color of a window, the location windows should start in, the toolbars visible, etc.

"The Requested Information Is Unknown Or Classified" -Anonymous

Share this post


Link to post
Share on other sites
Microsoft is shifting focus away from the Windows Registry with the introduction of .NET. Applications are now expected to use XML configuration files. They aren''t as neat looking as .ini files but they are self-checking (errors/mistypes etc.)

These configuration files allow applications to be installed by simply copying the files from installation media to the target machine. Very simple and just like INI files.

Now, as for storing per-user data in the registry there is a new and better way, in my opinion. It is called Isolated Storage. Basically, Isolated Storage allows you to store whatever you want in a per-user-specific location.

Regards.

Share this post


Link to post
Share on other sites
Ever installed the sims? Then formatted the drive and
wanted to add a new addon... Very funny because you have
to reinstall everything from scratch, because it can''t
find the game-path... For god''s sake it could just use
the directory I started the app from.

In general I dislike games which store stuff in the registry.
I have a seperate hdd with games and when windows starts to
be unclean I want to reinstall it and prefer it if all my
games are still working - I''m smart enough to delete the
directories myself.

but that''s MHO

Regards
/Roger

Share this post


Link to post
Share on other sites
quote:
Original post by Greven
I''m confused... Everyone keeps saying one of the main reasons not to use the registry is the size of the registry. Are you really worried about 50K of space being used? Also, havn''t you ever heard of regclean?

The registry consumes megabytes of space and Windows keeps it in the page cache (usually RAM) ALL THE TIME.
Everytime anything writes to the registry it''s as though it reduces the amount memory you physically have in the machine.

Share this post


Link to post
Share on other sites
yeah the registry is a really bad idea in my opinion, it always seems to break itself. i remember the good old days (pre 95) where each program was nicely contained in its own directory. i''d go for storing the configuration files in the game directory. if you''re worried about storing binary data like some dude suggested then you can just use binary file access, no biggy. of course then you wouldn''t be able to modify the settings by hand so maybe a combination of standard ini files and some custom binary files as well if needed. also if you''re ever worried about cross platform compatibility you don''t want to be using the registry but you might not really care, especially if using DX anyway. and who really cares about a "designed for microsoft windows" badge, it doesn''t really prove anything, it''s hardly a mark of quality, something to be proud of etc.

Share this post


Link to post
Share on other sites
Thanks for your opinions apparently most people agree with me that .ini is the way to go (generally) and I do not need to write binary so that is what I will have to use THNAKS again

Share this post


Link to post
Share on other sites
About those XML files Digitalfiend mentioned, is there a new API call for them I can use from C++? I''ve seen and used calls for reading INI files and registry keys in MSDN, but nothing about XML. Is it part of the .NET framework or something? They sound like a better method than the registry, but I''m not going to make my users download a 30 meg library just for that feature .

Share this post


Link to post
Share on other sites
i''ve found that writing your own format is the best way to go. For user data and stuff, you can save it all to one binary file and be done with it, then load it easily when you need it.

___________________
-Nicholas Anton
-www.geocities.com/nickanton7/

REFUSE TO BUY WINDOWS XP! STAY WITH 98se!! MICROSOFT CUTTING SUPPORT FOR OLDER PROGRAMS IS A VERY BAD THING.

Share this post


Link to post
Share on other sites
quote:
Original post by Anthracks
About those XML files Digitalfiend mentioned, is there a new API call for them I can use from C++? I''ve seen and used calls for reading INI files and registry keys in MSDN, but nothing about XML. Is it part of the .NET framework or something? They sound like a better method than the registry, but I''m not going to make my users download a 30 meg library just for that feature .


If these files refered to are the same as XML "manifests", there are two ways these files are used. One is to embed them in the resources for the application. The other is to include them as separate files in the same directory as the application. The technology is XP only. The exe loader takes care of handling the manifest. Afaik, there is no API for it. If you don''t have VS7 you can use PE Explorer to embed one in an existing file. Also, I might be totally off on this, as I seem to recall these manifests interoperate with the XP version of comctrl32.dll - which I would think wouldn''t have much place in a game.

Share this post


Link to post
Share on other sites
Even though .ini seems to have come out as the chosen format, let me just say one more thing in support of the ini files.

Basically, they are easy to port to non-Window operating systems. If you are planning on releasing your game in more than one platform, ini seems to work best.

Of course, writing your own special format is good, even though spending time coming up with such a solution might not be worth it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
DO NOT use the registry. This will mean that each user will have to manually configure the game settings when the game should be handling different users itself. It also means that systems with multiple operating systems will have to install the game twice (once for each registry).

The worst of it all is when you re-install windows or restore your registry and your game is effectively wiped (Black and White anyone?)

Share this post


Link to post
Share on other sites
XML all the way. Also, there''s numerous ways of encoding binary data that would ease editing of the data by hand.

Share this post


Link to post
Share on other sites
quote:
Original post by LessBread

"About those XML files Digitalfiend mentioned, is there a new API call for them I can use from C++? I've seen and used calls for reading INI files and registry keys in MSDN, but nothing about XML. Is it part of the .NET framework or something? They sound like a better method than the registry, but I'm not going to make my users download a 30 meg library just for that feature ."

If these files refered to are the same as XML "manifests", there are two ways these files are used. One is to embed them in the resources for the application. The other is to include them as separate files in the same directory as the application. The technology is XP only. The exe loader takes care of handling the manifest. Afaik, there is no API for it. If you don't have VS7 you can use PE Explorer to embed one in an existing file. Also, I might be totally off on this, as I seem to recall these manifests interoperate with the XP version of comctrl32.dll - which I would think wouldn't have much place in a game.




No no. An assembly manifest is something different and has nothing to do with application configuration. .NET uses configuration files based on XML. You can use any XML parser to get at the nodes or, if you are using .NET, you can use the .NET Framework to do it.

Example:


<configuration>
<appSettings>
<add key="Application Name" value="MyApplication" />
</appSettings>
</configuration>


You'd save this file as .config. So, if your applications executable was called client.exe, you'd name your configuration file client.exe.config.

When you fired up your client.exe file, written for .NET, the .NET Framework would automatically load and parse the file. You can then access your custom settings by using the appSettings property:

string AppName = appSettings["Application Name"];

etc.

[edited by - Digitalfiend on September 7, 2002 3:20:40 PM]

[edited by - Digitalfiend on September 7, 2002 3:23:43 PM]

Share this post


Link to post
Share on other sites
Dr. Pizza,

Microsoft *is* moving away from the Registry for applications. Why do you think the GAC and related information is stored on disk instead of in the Registry?

The .NET Framework supports multi-user environments just as easily as the Windows Registry.

Share this post


Link to post
Share on other sites