registry vs. INI files
Author
I have an app that stores some variables (such as resolution) in an INI file using Get/WritePrivateProfileString. It works fine. But the Win32 SDK says of these functions: "This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry."
Now, I'm all for Doing Things Correctly, but I'm leery of messing with the Registry, because I'm not at all familiar with it. I'm willing to jump in if it's really a good idea, but I don't know if it's a good idea. Can I get some thoughts on the issue?
Thanks.
I don't know anything about the windows registry, but if you are concerned about portability stick with the .ini file.
I am currious what storing data in the windows registry entails.
I am currious what storing data in the windows registry entails.
Quote:Original post by yckx
I have an app that stores some variables (such as resolution) in an INI file using Get/WritePrivateProfileString. It works fine. But the Win32 SDK says of these functions: "This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry."
Now, I'm all for Doing Things Correctly, but I'm leery of messing with the Registry, because I'm not at all familiar with it. I'm willing to jump in if it's really a good idea, but I don't know if it's a good idea. Can I get some thoughts on the issue?
Thanks.
You can do either.
Placing them in the registry isn't that hard, it's explained in MSDN.
The biggest benefits of using the registry over INI files are security and administration. It is easier for administrators to manage or restrict access to changing configurations. The user might not have permission to edit in the INI file's directory, but probably has access to their Current User registry tree.
Some benefits for INI files over the registry are that it is easier to back up, delete, or move between machines.
INI files aren't supported by the .NET framework (they might be in 2.0). There are a bunch of classes that do manual INI file processing and p/invoke INI file processing. Use google to help pick one that meets your needs. If you want to roll your own, you can p/invoke the older functions.
frob.
Use an INI file over the regestry.
-I like backing up my files for a game before uninstalling it. This includes saves, but it is nice if I can save my keybindings and other settings.
Some sort of settings file makes this easy.
-You can't use a regestry in Linux that I know of. So if you ever port the game...
-Info in the regestry is lost if you reinstall windows. But reinstalling windows should not mean that you must reinstall the game. If all the files are still on your computer, then why be forced to delete them and reinstall the game?
*just my 2 cents.
-I like backing up my files for a game before uninstalling it. This includes saves, but it is nice if I can save my keybindings and other settings.
Some sort of settings file makes this easy.
-You can't use a regestry in Linux that I know of. So if you ever port the game...
-Info in the regestry is lost if you reinstall windows. But reinstalling windows should not mean that you must reinstall the game. If all the files are still on your computer, then why be forced to delete them and reinstall the game?
*just my 2 cents.
But please put your ini-files in the users home directory (so everybody can have different settings).
Author
Quote:Original post by TrueTom
But please put your ini-files in the users home directory (so everybody can have different settings).
Ah, good call. I hadn't thought of that. I think I'll keep the INI file, and make the change to place it in the user's home directory.
One should also note that MS themselves are now advising against the use of the registry in favour of XML-based configuration files in .NET.
Registry, I hardly knew ye.
Registry, I hardly knew ye.
Quote:Original post by Arild Fines
One should also note that MS themselves are now advising against the use of the registry in favour of XML-based configuration files in .NET.
Registry, I hardly knew ye.
Both methods are rather trivial tasks, however, in .NET with classes included to do the work. Also note that in the new Microsoft Command Shell you can browse the registry just like any other filesystem 'cd hkcu:' f.e. changes you to the root of HKEY_CURRENT_USER.
I hate the registry. Avoid cluttering it if you possibly can. That way, the rest of us won't have to reinstall Windows every week to keep the bloat down to a manageable level. And if something goes wrong, it's a hell of a lot easier to delete a .ini file, than to trawl through the registry just to find those couple of keys left behind by your program.
I don't care what MS recommends, but I prefer programs to avoid using the registry more than neccesary.
I don't care what MS recommends, but I prefer programs to avoid using the registry more than neccesary.
It's your program. Store your config stuff how you like, but try not to break the rules too much. Storing configuration settings in the right part of the registry, or in the *correct* place in the filesystem (which is often in the user's home directory somewhere), is fine.
As far as I'm aware, ini files are largely deprecated, probably because they can't usefully store unicode text data.
Or rather, they can't store unicode text data if you use the windows functions to read/write them. You could of course make your own ini file format which is exactly like a classic .ini file except in UTF-8.
Mark
As far as I'm aware, ini files are largely deprecated, probably because they can't usefully store unicode text data.
Or rather, they can't store unicode text data if you use the windows functions to read/write them. You could of course make your own ini file format which is exactly like a classic .ini file except in UTF-8.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
