Where should a application save settings? [Archive]

unskinnyboy

30th October 2005, 18:39

I prefer an *.ini file in the startup directory where the program is located, because for programs which I use extensively I like to edit the *.ini file and modify settings, rather than from the GUI. Having an ini file is also better than registry keys because in case you have an issue with the application and want to post in a forum asking for help, you can copy-paste the contents of the *.ini file.

Also, uninstallers which comes bundled with most applications don't properly clean up the registry during the uninstall. This could be good or bad depending upon your preference. Sometimes you'd want the settings to be retained in case you are installing a newer build of the application after you uninstall the older one. If you are not doing that, then the uninstaller leaving the registry keys behind is annoying. Here is another case where I'd like an *.ini file. If I am uninstalling, the uninstaller should wipe everything clean. If I want to retain the settings, I can backup the *.ini file.

DGMPGDec would be an example of how I'd like things to be. I voted #2.

Sirber

30th October 2005, 18:44

registry just get bloated and slow.

RealAnime 3.2 uses INI files
RealAnime LE uses XML file.

Moitah

30th October 2005, 18:52

I prefer it in the startup directory. However, Microsoft recommends against this because it may not work for limited user accounts.

Doom9

30th October 2005, 19:03

Microsoft recommends against this because it may not work for limited user accounts.creating a settings directory in the local user context is not such a bad idea. But software using the registry should also use HKCU to store settings. Personally, I like applications that have zero installation and uninstallation.. that way anybody can run them, but that's not always possible. Unfortunately, way too many softwares are using the registry and have insufficient uninstallers.. but that's a fault you can squarely blame on whomever created the software. Microsoft's guidelines are pretty clear on that.. an uninstall function needs to clean up the entire registry.

danpos

30th October 2005, 19:46

I voted #2.

stax76

30th October 2005, 20:15

I prefer an *.ini file in the startup directory where the program is located, because for programs which I use extensively I like to edit the *.ini file and modify settings, rather than from the GUI. Having an ini file is also better than registry keys because in case you have an issue with the application and want to post in a forum asking for help, you can copy-paste the contents of the *.ini file.

ini is very popular for applications coded with Delphi because directly supported by Delphi. With .NET a mechanism called serialization is very popular. Serialization transforms date structures automatically to xml and binary files and back. This is very convenient and powerful. I understand binary serialization is not transparent for the user but it does quite a few things much better then xml serialization.

I prefer it in the startup directory. However, Microsoft recommends against this because it may not work for limited user accounts.

Does that mean a user can install a application in a restricted location but the application self cannot write to that location. I'm pretty clueless about the topic, I'm always admin.

videomixer9

30th October 2005, 20:31

I hate applications that store there data in their directory as they require you to run as administrator or as a user that has write access to the program directory. Here I generally don't work as a user who can write to the program directories without running programs as admin.

Besides, the application modifies settings for all users then most often generally and other users may not want the same settings as someone else.

Storing settings to the program directory is imo bad program design and it's a major point for me to declare a program shit. Any sane application nowadays stores settings based on user context, however many noob programmers still do crappy program design as many idiots still only work as admin under windows. Each user has an Application Data directory nowadays where you can store settings, many games nowadays do that there too, and browsers like opera and firefox do it to. Using the registry is a good go to.

However, even Adobe messed this up for one app ... Audition ... the directories have different names in different national windows versions, the folders are not named "documents & settings" in all windows versions and "application data" is not a fixed name too, e.g. on german windows they are called "dokumente und einstellungen" and "Anwendungsdaten" so get sure if you store settings there to use a windows API to get the names of those directories instead of hardcoding them in english. If you use ini files you can store them there like firefox and opera do instead of the noobish way to store them in the program directory. It keeps you the good things of an ini file while also providing proper multiuser support.

WHOEVER STORES SETTINGS IN THE STARTUP DIRECTORY NEEDS TO BE SHOOT! it's bad program design, it breaks working as limited user and also multiuser support.

ALWAYS WORKING AS ADMIN IS BAD! it's why virii and trojans are so successful under windows, however many bad designed apps make you want to do it ...

So my tip is ... store it in an ini file located in a directory made for your application in the application data folder, e.g. "C:\Documents & Settings\UserXY\Application Data\My Application\settings.ini". This directory is hidden by default in Windows so user don't start messing around there, as it is in the users own folders, which he has full access rights under any circumstances, it's the ideal place to store settings etc.

To see for yourself just explore this directory and you'll notice many apps use it.

Developers nowadays testing their apps only as admin are a major problem that leads to crappy applications that suck in multiuser environments and those developers are imo guilty for the whole virii and trojan plague! as admin any program can modify any registry settings e.g. "HKEY_CLASSES_ROOT\exefile" and each time you start a program the trojan is also started! All this thanks to developers that make their apps impossible to use without admin rights!

Moitah

30th October 2005, 21:10

Does that mean a user can install a application in a restricted location but the application self cannot write to that location. I'm pretty clueless about the topic, I'm always admin.
This (http://msdn.microsoft.com/library/en-us/dnlong/html/AccProtVista.asp?frame=true) might help, search the page for "Application Settings". I guess if the user installed the application then they have ownership over the folder, but if it was installed by another user they will not be able to write there. I'm not sure though because I always run as administrator :).

stax76

30th October 2005, 21:23

@moitah

great link, thanks

GrofLuigi

31st October 2005, 01:27

Whoever doesn't know how to gain write rights doesn't deserve the right to be able to customize any application settings. :)

GL

unskinnyboy

31st October 2005, 02:15

Whoever doesn't know how to gain write rights doesn't deserve the right to be able to customize any application settings. :)
Exactly! I don't get it what was the bitching about not being able to run programs which require admin rights by a common user couple of posts above. Maybe they want exactly that. If you don't have Admin rights to a machine, chances are that you are using a workplace PC or school/university PC, so yes, they have every right to disallow you to go in and mess with their application settings or even prohibit you to use it under your user account. Maybe it is their security policy. If it is a financial services company handling customer sensitive information and the software in question is their corporate firewall or something, then it makes perfect sense in not allowing you to switch it off or otherwise modify any setting.

In any case, the application which stax have in mind is possibly a multimedia one and not likely to cause any security concern..I hope.. :)

Nematocyst

31st October 2005, 02:47

...If you don't have Admin rights to a machine, chances are that you are using a workplace PC or school/university PC, so yes, they have every right to disallow you to go in and mess with their application settings or even prohibit you to use it under your user account. Maybe it is their security policy. If it is a financial services company handling customer sensitive information and the software in question is their corporate firewall or something, then it makes perfect sense in not allowing you to switch it off or otherwise modify any setting.

If you are talking about such a sensitive app as a firewall, then yes. But that's an admin only program that usually has conf files associated with them, which are only writable by certain groups.

But I think we're mostly discussing settings for more mundane programs like editors. In this context, we're talking about fonts, window positions, search strings, etc.

And my vote is in the users home directory. The registry has user settings as well, so that would be alright, I suppose. But it's very OS specific, unlike a file in the user's home directory.

In the unix world these issues are handled in several ways. The critical programs usually have config files which are handled by the administrator and don't normally have user settings at all. The user programs typically have a config file in the user's home directory. But they also accept an environment variable which takes precedence (per-user, of course) which helps facilitate scripting of command line programs. This system has been around since the 70's and it still works great. I find it somewhat interesting that microsoft has had ages to come up with something better, and IMO, the registry is comparatively retarted.

Nematocyst

31st October 2005, 04:21

Actually, better answer would be: it depends on the nature of the settings you are storing.

I can think of more than two types of settings, but for simplicity, let's assume we have just two types of settings: user, and non-user.

non-user data would be anything that isn't user data, including defaults

user data would be any preferences that would vary from user to user and they would override any defaults.

Under this scheme, I would put user data in the user's directory and non-user data in the program directory.

And if you encapsulate the data retrival functions with something like:
get_nu_data()/put_nu_data()
get_u_data()/put_u_data()

then your program doesn't even care if it's in the registry or config files or even where in the registry/directory tree the data resides. Just remember that put_nu_data() won't work unless an admin is running your program. In fact, don't even write that function if you can avoid it. (have the installer generate that data if you can)

31st October 2005, 12:19

I only have two points about this:

1. for end user like me, i like it to have it in startup directory. That is because it's only me who is using pc, so I don't have to worry about multi-user compatibility. And when I reinstall, all I need is to just copy the dir, and there it is with all my setup!

2. for admins, and multi-user systems, apps should utilise registry hklm/hkcu and/or all users/current user/application data dirs. so that network admins can manage security normally etc

CirTap

3rd November 2005, 01:30

Your answers were missing the "default" and built-in directory of Windows for exactly that purpose (well sort of): %APPDATA% so I had to vote for "other" :)
and I'd prefer %APPDATA%\YourApp\ - be it an INI or XML, at least some text file one can edit or copy, and I agree with doom9: best and most handy apps are "copy and paste" (or "unzip") installations.
If I install a new PC I can often just copy %APPDATA% to the new box and have my old hand-crafted settings back.
The application folder will not work by design so it's not a true option at all. you must consider restricted user accounts, hence the existance of the %APPDATA% folder.
Unfortunately, all this COM- and ActiveX stuff requires to blow up the registry.

Microsoft's guidelines are pretty clear on that.. an uninstall function needs to clean up the entire registry and they violate their on "rules" since Win95, like placing Office shortcuts in the Startmenu-root rather than a "vendor subentry", and don't believe you can truly uninstall any MS Office once it's on your machine and turn out with a "clean" registry ;-)
I'd say few then 10% of all apps really clean up their crap from the registry on uninstall .. always lack the ability to remove the "runtime options" which go to the registry *after* using the app
And I hate if installers
- don't ask me where inside the Startmenu I want to have shortcuts and IF ANY at all!
- dump shortcuts on my desktop and quick-launch without asking (and even if I explicitely disable it), or even top-level in the Startmenu
- don't honor Windows' localization for the common, well-known folders like "C:\Program Files", which has other names on non-english versions (their true physical paths are all available from the registry)

Be nice, ask you users and use the information, and folders Windows provides for that matter. If you need an installer get a nice free one like NSIS.

Have fun,
CirTap

nigor

3rd November 2005, 07:52

I use Delphi and it is crealy stated that .ini files have limit of 64kb, and are there only for backward compability (with 16 bit OS!). Using XML files in Delphi is much easier and it makes for a more structured and intuitive settings file. Other libraries, like the .NET framework, make working with XML files a breathe. Long story short: dont use .ini unless you are programming for Windows 95 or something.

As for storing the stuff, I use Isolated Storage (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconIsolatedStorage.asp)

stax76

3rd November 2005, 08:01

Thanks everybody, I've learnt something and try to do this right from now on.

@nigor

Great link, never knew about this class.

CirTap

3rd November 2005, 11:23

I use Delphi and it is crealy stated that .ini files have limit of 64kbpartly true: this limit only applies if one uses the corresponding Win-API functions to access them. For "historical" reasons (maybe) this is now an atrificial limit in a 32/64 bit environment, since a 16bit string (Win 3.x) can only hold 65535 bytes == 64k.
They're still text files with a simply "syntax", one can "fopen()" and parse like any other text file or "data stream". Still, 64k is usually enough to store configuration only, isn't it? :)
INIs and alike provide a "2D" structure that does work fairly well for common key-value pairs. XML is maybe overshot for this kind of plain, regular config data, unless it MUST be greatly structured, nested, referenced. The MSXML COM/OLE components have flaws in storing/reading floats across localizations, misinterpreting "," and "." as the thousands and decimal separators.

CirTap

masken

3rd November 2005, 17:23

Microsoft has good guidelines for this. But generally, user-related/shared application data should be stored under the Special Folder "CommonProgramFiles". User-specific/non-shared data should be stored under "AppData" as mentioned. User files/document data should always be stored under the Special Folder "My Documents".

User configurations should be stored in the HKCU-part of the registry.

Ie, no data should EVER require privileged rights to be stored after an installation, and the application should not EVER require privileged registry permissions after the installation, or privileged system rights (like registering system DLL's etc).

that means that INI-files (which btw is an old 16-bit way of doing things and really shouldn't be used anymore) or other user-related data should NOT be stored under %ProgramFiles%\theApplication\, since a normal user doesn't have write permission under %ProgramFiles%. If there are such requirements, the application should during the installations phase set the correct NTFS-permission for the file/folder, but this is really not good practice as there are dedicated folder structures for this.

I had a link to a good article about this.. but cannot seem to find it atm.

Also remember that from Windows Vista+, MS is finally thinking security and will apply the "domain structure" also on new local accounts. Normal User accounts won't be created with administrative privileges anymore, but as... yes that's right - normal Users like the OS was intended to be used since NT 3.5x :)

So I'm sorry to say that most ppl here have voted on the wrong location, user data and configuration data should not be stored in the applications installation folder since the default NTFS permissions isn't designed for this. Never has been actually.

stax76

3rd November 2005, 17:54

So I'm sorry to say that most ppl here have voted on the wrong location, user data and configuration data should not be stored in the applications installation folder since the default NTFS permissions isn't designed for this.

The thing is probably most people who voted prefer applications without installer and they don't put it in the programs dir. I have a separate partition for instance dedicated for personal data where my xcopy compatible applications reside. Also most are probably admin. I don't know about others but I'm pretty sure having a restricted account wouldn't work very well for me.

Nematocyst

3rd November 2005, 19:42

So I'm sorry to say that most ppl here have voted on the wrong location, user data and configuration data should not be stored in the applications installation folder since the default NTFS permissions isn't designed for this. Never has been actually.
Not that I disagree, but apps storing their data in the installation directory is fine as long as the user installs/unzips it into his personal space, ie. under his home directory.

Tuesday

4th November 2005, 04:17

I vote for storing all of a programs files in one place, the place where you installed the program that way you always know where all it's stuff is.

I realise this causes problems with multi-user and user-permissions, but then i'm the only one on my machine and run as admin for sheer convienence so thats not a problem. :)

EDIT: in fact i vote for not "installing" programs at all, just un-packing a .zip to a folder and run the tool as and when. To "uninstall" - delete the folder...

masken

4th November 2005, 14:29

@stax, have you tried? :) Most of the times, all that's required to get badly written Windows-applications to work is to add a Change-permission on the installation folder for the Users group.

@Nematocyst, sure, but apps shouldn't really be installed under a personal space ;) But if it's an app that doesn't require installation, then it's another issue.

stax76

4th November 2005, 15:13

@stax, have you tried? :) Most of the times, all that's required to get badly written Windows-applications to work is to add a Change-permission on the installation folder for the Users group.

No but at least I'm now more interested in the topic what possibly could lead to that I'm trying it at some time as I get more educated on the topic.

CirTap

4th November 2005, 16:13

Copy-and-paste or "unzip" installations are generally nice and work fine if you're Admin of some kind.
I also have dedicated some "X:\Tools" and "X:\Utilities" folders to host such drop-copy tools, most CLI or "simple" GUI apps that usually don't come with an installer -- like the majority of tools one can find here.
As soon as you're using OLE/COM/.NET technology you're often required to register their (additional) components in the Registry, typically in the HKLM tree only Admin's have write access to. Thus "runtime registration of components" is (theoretically) not possible unless you are Admin, letting such apps fail to run for unpriviledged accounts.
masken has perfectly outlined this issue, and stating "most ppl here have voted on the wrong location" is sad but true.
If one's in the situation to let the kids (or spouse <g>) use the same machine (some must for the lack of alternatives), you certainly won't give them Admin rights, however they may not be the target audience for the app you're planning so it's probably a weak argument, but still.
I'm sure most of the people here run their windozes with an Admin account for convenience, but keep in mind that otheres are more "paranoid" and use a normal account for "security reasons", with all the bad things that happen to your box if you type "www..." in MSIE :-)

No matter if the app goes into %ProgramFiles% or "F:\name-goes-here\", it's runtime settings, configs "must" go either to HKCU, %AppData%, "Local AppData" or "Local Settings" (system folders hidden by default), all of them available from
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

I ever disliked HKCU's existance since its advent in Win3.0, since it's a pretty unconvenient place to backup and restore an apps settings easily if one moves to a new machine. I don't know of any app that allows a user to backup its current settings from the registry in order to move them to a new installation. That'd be something very useful! and I'm sure everyone utterly hates to set up a new machine since you always have to start from scratch configuring any damn app you use; and the new "User Settings what-ever Wizard" that came with XP is a nice idea but no big help for that matter as basically nobody supports it.
... INI-files (which btw is an old 16-bit way of doing things and really shouldn't be used anymore)if it comes to INI files stored in windows\ like in the Win3x era I agree, since that woudn't work for the same reasons that apply to store stuff at runtime under %ProgramFiles%.
*.ini files are as "modern", reliable and handy as *.res files found on Unixes or *.properties file used by basically any Java application. You woudn't store .xml files in any of the forementioned restricted places either just because they are "modern" and an overhyped, state-of-the-art data storage format.
So it's not the "file format" to blame but their location only -- which this poll is all about, right?

Havve fun,
CirTap

stax76

4th November 2005, 16:53

I don't know of any app that allows a user to backup its current settings from the registry in order to move them to a new installation. That'd be something very useful!

Mp3Tag for instance (imho best tagger), regedit has a command line switch to export a tree. The export feature of regedit is seriously crippled however, for instance it cannot export strings that contain line breaks. I made a xml based registry backup application because of this just like I made normal backup application based on robocopy. Just too often I end up to hack a application because nothing else works well for me. I can post source code and binaries if anybody is intersted.

CirTap

4th November 2005, 17:13

regedit has a command line switch to export a tree yes, but you still need to know where *all* settings are stored. I didn't say it's impossible but just tedious. I use reg.exe (from Win RK I think) for that matter.
backup application based on robocopyCopyRite XP? is that yours?
I can post source code and binaries if anybody is intersted.I am :-) binaries basically as I'm a plain dumb n00b if it comes to compiling :scared:

stax76

4th November 2005, 18:41

CopyRite XP? is that yours?

No, I didn't release this yet like so many other apps I made. This one is really small as I use always the same robocopy switches for all of my backup tasks so I hadn't to expose much options.

I am :-) binaries basically as I'm a plain dumb n00b if it comes to compiling

I might have to add some documentation so I'll upload both applications later.

CirTap

4th November 2005, 18:56

cool!
"add some documentation", hum? -- sorry for that inconvenience :blush:

robocopy's switches are horrible unless one uses /MIR :-) hence CopyRite is packed with all of them as well but it's well done.
since you have robocopy, you should also have reg.exe (think it's part of XP as well, but the latest RK release has an updated/bug-fixed version) Since it writes *.hiv files (binary) as well as regular *.reg there's no prob with linefeeds, and the compare switch is pretty handy

CirTap

stax76

4th November 2005, 19:12

CopyRite is packed with all of them as well but it's well done.

Too bad it's not free, does it support more than just one source dir (task)?

since you have robocopy, you should also have reg.exe (think it's part of XP as well, but the latest RK release has an updated/bug-fixed version) Since it writes *.hiv files (binary) as well as regular *.reg there's no prob with linefeeds, and the compare switch is pretty handy

Can this tool save and restore a entire tree, if so I wouldn't have to bother to write my application. It's not that I didn't look for tools that can save a tree, I just couldn't find one.

GrofLuigi

5th November 2005, 04:30

Sorry for offtopic, but I could not resist...

As soon as you're using OLE/COM/.NET technology you're often required to register their (additional) components in the Registry...

Has anyone found any ACTUAL use of this s**t except for bloating the registry (And saving lazy users a few mouse clicks here and there)?

I'm not a programmer, but I actively use computers for 20+ years. I see it like this: I use the O/S to load my programs. I work in them and save the result of my work in a concrete file with a concrete format. If I want to touch that up, I load another program and work in it. Programs are no living beings and have no need to communicate among each other! But how else would big companies sell "modern" versions of the same programs that do the some thing?

/end rant

I could not find big enough smiley to indicate that I'm joking, but I often feel this way. Ask any user faced with (un)installation/maintenance problems...

And yes, I will switch to *nix someday (honest!)... :D

GL

stax76

5th November 2005, 09:30

Sorry for offtopic, but I could not resist...

Has anyone found any ACTUAL use of this s**t except for bloating the registry (And saving lazy users a few mouse clicks here and there)?

I'm not a programmer, but I actively use computers for 20+ years. I see it like this: I use the O/S to load my programs. I work in them and save the result of my work in a concrete file with a concrete format. If I want to touch that up, I load another program and work in it. Programs are no living beings and have no need to communicate among each other! But how else would big companies sell "modern" versions of the same programs that do the some thing?

/end rant

I could not find big enough smiley to indicate that I'm joking, but I often feel this way. Ask any user faced with (un)installation/maintenance problems...

And yes, I will switch to *nix someday (honest!)... :D

GL

The programing API of Windows is called Win32 API and almost everything new in there since the last ten years is COM+ based. A COM+ component has to be registered in the registry, a DirectShow filter for instance is nothing then a COM+ component ;). .NET is a superior and directly inherited from COM+ and Java and many other technologies. It does *not* rely on the registry!

CirTap

6th November 2005, 16:52

It does *not* rely on the registry!it does not? then how comes that zillions of System.foo.bar.you.name.it-alike CLSIDs show up there? Or is this just yet another compat layer on a compat layer to be compatible with whatever layer? Like to possibly instatiate .NET components in "16bit OLE applications" as well? :-)
Honestly, I must confess I know nothing about .NET programming except as it's supposed to be "tha-thing" and tried to resist installing it as long as I could since all I can see is that it shoves more megabytes on my drive and into the registry.

Since this is your thread, I think talking about "reg.exe" is not considered to be OT :D Can this tool save and restore a entire tree, if so I wouldn't have to bother to write my application. yes; key, value, and tree-wise r/w access, modifcation, im-/export, even to remote computers if the services (remote registry) are running and grants are given.
As I said, it should be present in XP (home and pro) by default since it was part of XP-SP2, too. Product Name : Betriebssystem Microsoft® Windows®
File Description : Konsolenregistrierungsprogramm
File Version : 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
Product Version : 5.1.2600.2180
Company Name : Microsoft Corporation
Internal Name : reg.exe
Legal Copyright : © Microsoft Corporation. Alle Rechte vorbehalten.
Original FileName : reg.exe Despite the "5.1.xxxx.yyyy" in the version tab, it reports "Version 3.0" at the command prompt. (KB articles (http://support.microsoft.com/search/default.aspx?query=reg.exe) about various versions and issues)
From RK-Hompage (http://www.microsoft.com/windows/reskits/default.asp) you'll find their downloads and updates.

REG.EXE is handy to install/configure a new machine to compare values with an existing (old) one. If that's done I shut down all the remote-stuff-services.
As of your "config-tool", I was just curious of your procedure. I do have a bunhc of batches to do the "core" app configs, but there could be something more pleasing :-)

Have fun,
CirTap

stax76

6th November 2005, 17:52

it does not? then how comes that zillions of System.foo.bar.you.name.it-alike CLSIDs show up there? Or is this just yet another compat layer on a compat layer to be compatible with whatever layer? Like to possibly instatiate .NET components in "16bit OLE applications" as well? :-)

The CLR (the .NET runtime) is a COM+ server self, you probably noticed quite a few COM+ servers in the registry, for 10 years OLE/COM+ was "the thing", now it's .NET. When you see a CLSID you see nothing but a registration of a COM+ server. A COM+ server can be done in any reasonable language, language interop is a key feature of COM+ and with .NET that feature has greatly improved. Don't asks me what all this servers installed by .NET do, probably a variety of different things ranging from integral core stuff to interop. When you do a .NET application, the ideal case is you do not expose or consume any COM+ server or deal with any other native or legacy stuff directly in your application. In this case the application self has nothing to do with the registry and is of course 100% xcopy compatible. In the real world even with now > 5000 .NET classes you still have to do interop. For instance DirectShow is a pure COM+ API and Microsoft didn't yet provide a wrapper like they did for DirectX.

I'll write a little help for my backup tools and upload it. If I knew about reg.exe I probably didn't have to write my parsing code and used reg.exe instead though it wasn't that hard.

stax76

6th November 2005, 19:05

Here (http://www.planetdvb.net/misc/StaxRegistryBackup.zip) is my little tool to backup registry keys. I still have .NET 2.0 beta 2 so you have to build it your own using .NET 2.0 final. There is a file build.bat that should do just that.

feedback

6th November 2005, 22:56

Definitely Not the Registry! No,No! SOoooo SLOooow. :eek: I am bloated.

Put it in an .ini

Regards,:)

masken

9th November 2005, 22:29

@CirTap, yes the poll were about where to store things :)

The downside of *.ini files is as pointed out that for normal applications, the developer generally just drops the *.ini in the installation folder. There's error #1 because of the default NTFS permissions as described.

The other, for this poll more irrelevant issue with *.ini's is that they're only "1-dimensional" (array comparison). Ie, you've got one level of storage. For simpler applications, an *.ini stored in the correct folder does it's job just perfectly. But when there's a need to store more complicated configurations, a tree-like structure or multi-dimensional array-like structure (like the registry) is much more convenient. I agree with you that there's lack of a generic/standard way of handling this. There really hasn't been a good replacement standard for the good old *.ini's. The way to do this today is simply dumping the applications registry hive manually, which is far from good procedure as there's no way to know that all of the applications registry entries are stored under the same hive, or that all of the configuration is even stored in the registry. XML could do the trick I guess... if there was a standard available.

foxyshadis

10th November 2005, 05:25

There are a lot of xml standards, that's the whole problem. ;) The most common solution is either .Net/Java XML serialization, or replicating the registry structure.

Something that a lot of developers also miss is the Local Settings folder, where throwaway files go (caches, temp files, etc), because they don't get replicated when you log on in a domain. Misuse of App Data to store Local Settings files is the primary cause of slow logons and logoffs and contributes to network congestion.

CirTap

10th November 2005, 15:38

@masken: I woudn't call it 1-diminsional, since [ sections ] allow categorization, but you're right: INIs are somewhat limited unless one "codes" logic into the key-pairs. Decades ago I had to write some VBA-like scripts for a VMS terminal emulation (Reflection) and had to "invent" some sophisticated way to save hierachical data; INI (via WinAPI-Calls) was the best and easiest way to go, and one colleague called the module I wrote an "INI++" parser ;)

After all, and I agree here, too: the storage format (also) depends on the type of data being stored. In case of hierarchical data I'd also prefer an XML file (or a bunch of them) over Registry for "transportability" sake.

We all know the inconvenience of registry-only configuration if it comes to recreate/reconstruct application settings on a newly installed PC (since Windoze will probably never ever be able to keep itself "clean"), or even to keep them in sync (PC/Laptop): it suxx badly.

But: some apps store sensitive, user specific data! How 'bout that? The Registry would certainly protect such data "by design" (NT and up), I'm not so sure about the user files and folder.
I agree with you that there's lack of a generic/standard way of handling this.MS tried with the "File & State Transfer Wizard (http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/usermigr.mspx)" (FSTW), afa FAST, aka "User State Migration Tools" (USMT), which comes free with XP. But there's basically no support from any 3rd party software provider, and the provided defaults are outdated. So meanwhile in practice it's limited to "migrate" a bunch of Windows settings only, despite it's pretty easy to extend and script new "application and file rules" -- with INI/INF style files ;-)

@foxyshadies: very interesting point! Didn't though of "networking", since I haven't worked myself in a true Win-based roaming-user environment for at least 10 years (NT 4 network).
Still, %temp% (and %tmp%) typically point to "Local Settings\Temp" and any programmer NOT using that variable is to blame anyway, like many "lazy" coders just dump logfile and alike to C:\ <argh>. That's as stupid as assuming the CD-drive is alway bound to drive D:\ and ignoring any of the "User Folders" given in the registry :devil:

CirTap

stax76

12th November 2005, 00:40

I just released my application which was the reason for this poll. It let's the user select the directory to save the settings. By default it will use the startup directory as most users prefer it. The location of the directory is saved in the registry in the user context. It's only one value my application saves in the registry. Not that I like the registry but it is faster than using a file for this. If the user changes the directory and closes the application the settings go still to the old location, the new location is used on the next start. If the user want to continue with the settings of the old location he has to copy it by hand from the old to the new location.