The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

The Windows Registry and I

After discovering that the Java preferences API uses the Windows registry (on Win platforms) I bleated out a monologue to all who would listen about the problems:  I enclose it here because no one was listening...

In my opinion and important property of storing configuration data is that is should be able to be easily examined and yes-I-mean-this *edited* by *humans* (and maybe cats) without the application running.

Hence the annoyance with storing config stuff in the Windows registry.  I don't like having to browse through the registry.  Even worse if I want to instruct a user to do so or instruct them on exporting the relevant keys to a registry file so I can view/edit it myself.  I prefer using files and Java comes with an API for it's properties files format which is very simple to edit in any text editor and just as easy as XML to parse.

While it's possibly handy that the registry can somewhat typesafe config data (String, binary, etc), I've never found it to be of any use in this context since it doesn't fix spelling mistakes.

At this time, feel free to agree with me so we may be a force for good....
Paul Norrie Send private email
Tuesday, December 06, 2005
I loathe the windows registry, mainly because its not secure or portable.  At the other end of the spectrum, individual INI files are more secure, but still not very portable.

I think the general idea everyone was hoping for is that you can make a backup of your application(s), configuration files and all.  If you loose the system afterwards, you can simply reinstall the operating system, and then simply copy all of your applications and data over - presto, you're back up and running. No need to retype in any identifying information or preferences.

The downside of the individual INI files is that you can never make sure you've got them all unless you copy the entire hard drive en masse.

I think ultimately my argument will become moot. Hard drives are getting so big and so cheap that in a few years from now, you might as well just back up the entire system.  At this point, it simply becomes a question of whether the vendor wants you to be able to directly edit the configuration files for his application.
Anonymous Coward
Thursday, December 08, 2005
On UNIX platforms, and Linux (I'm not sure), the default data store is an XML file.

I believe there are export and import methods, so you can export the preferences from the default data store to an XML file, change them, then import them. I also think there's a way to change the default data store to something of your choosing, such as an XML file or database, but I've never done that.
Former COBOL Programmer
Thursday, December 08, 2005
On a Unix system and Linux the configuration file is stored in a text file, usaully in the /etc directory sometimes somewhere else.  I have never seen an application that stores it configuration file as XML.

Thursday, December 08, 2005
Try VB 2005.  My.Settings saves per-user config files instead of mucking about with the registry.  Just one of many things I like about this new version.
Kyralessa Send private email
Thursday, December 08, 2005
If you dare store machine specific configuration data in anything but the registry in the local_machine hive, I'll chop off your fingers. User config must go in either the current_user hive, 'Application Data' or 'Local Settings\Application Data'. I'm kidding ofcourse. Instead of assaulting you, I'll uninstall your software faster than you can blink your eyelids. I'll badmouth it to whomever I can. (WinAMP *explicitive*. It should really take a look at how jedit handles settings & plugins.)

I am silently but surely escaping from the morass that is the ini file combined with its improper location. And come heaven or hell, I'm taking you all with me.
Friday, December 09, 2005
How can you say the Registry is not secure? It's no more or less secure than INI files. You can set permissions on keys, just as you can set permissions on directories.
John Topley Send private email
Friday, December 09, 2005
Mocrosoft explicitly discourages the use of the Registry on their website for the past ten years. The only reason to use it is when a company has to read/write settings by other producs (their own or not).

Amazing how this dogma of using the Registry for ANYTHING still persists even though Microsoft said: "It was a mistake, DON'T use the registry any more!"..
Frank de Groot Send private email
Friday, December 09, 2005
I always got the impression that MS was RECOMMENDING that we DO use the Registry. (I never did for the reasons listed above). And for backward compatibility with my vb3 apps.
Mr. Analogy {Shrinkwrap µISV} Send private email
Friday, December 09, 2005
As I said, Microsoft, for the past ten years, vehemently discourages the use of the Registry.
Frank de Groot Send private email
Friday, December 09, 2005
This is just typical Microsoft. They've been screaming not to touch the registry for years, yet their actions show otherwise.

Just about every product out there thrashes the registry to some extent. Personally I find .INI files much easier to deal with, but that's my opinion having been on both sides of the fence.
QADude Send private email
Friday, December 09, 2005
If you are going to use ini files, fine. But be sure that guest users who only have write permission in their profile directory can still completely use your application.

I still see to many apps with a win95 mindset running around. Luckily it's mostely the bad apps that make these mistakes. And who needs bad apps? Did I mention already how jedit is a dream to work with even if you have minimal user permissions? Look at it if you want a example.
Friday, December 09, 2005
Funny.  Win 3.1 used INI files for everything.  This led to INI file hell, where all these INI files resided in the SYSTEM directory for their applications to find them.

Their solution?  Registry Hell.  This has all the drawbacks of INI hell, except that it is mostly invisible to casual users.  And makes backing up and restoring your root drive problematic.

OK, so we're not supposed to use the Registry any more?  What do we use, individual INI files again?  Though, personally I like an INI file in an application's root directory from time to time.
Friday, December 09, 2005
Ideally, I think the INI files should be stored in...  well, the "documents and settings" folder, and each application gets its own sub-folder. However, I will be the first to admit there are flaws with that idea.

The reason I considered INI files more secure is that you cannot simultaneously corrupt all of the INI files in your system as easily as you can corrupt the registry.  Security as in decentralized targets, not access priviledges.

I don't think this problem will ever be solved until Windows enforces access permissions on a per user and a per application basis, regardless of whether we code it into the application or not.  In other words, if I write Foo, give it to someone, Foo should only be able to access the stuff in Foo's folder, plus Foo's INI file or registry key, regardless of who's actually using it.
Anonymous Coward
Friday, December 09, 2005
About MS discouraging use of the registry for the past 10 years:

You do realize that the registry as a general purpose database of application (and system) settings has only been around for 10 years (Windows 95) don't you? Before that it was only a registry of OLE objects.

It makes that assertion rather ridiculous IMHO.

They HAVE been discouraging the use of the registry for applications in the past FEW years, mostly in the context of xcopy deployed WinForms apps or ClickOnce.
Chris Altmann
Friday, December 09, 2005
I totaly agree with the top poster.

I usually make .INI files and store them in the applications home directory.  Being a big java fan I can then take the whole directory for the app and know I have gotten it all.

Secure items (usually a name a password) are user entered at runtime.  Storing them to the registry just invites hacking (boot linux, copy off the registry, put it on a virgin box where you have permissions)

I deal with salesmen at times, so far I have had good luck with the "use notepad" method of field changes.  Having them edit the registry to make a quick fix/change is scary.

Portability hasn't been an issue for me (so far)
Friday, December 09, 2005
Why is it that so amny applications want to send peices of themselves all over the file system?  Shoving things in the registry may not create a new file for accessing but still puts peices of itself(configuration info) into a different location from the rest of itself.

I am just confused as to why all but the true data files for an application can't reside below its root directory?
Friday, December 09, 2005
A good place to put config files in Windows is in:

  C:\Documents and Settings\USER\Application Data\PROGRAM

You can store preferences for individual users this way. This is where I put most program settings. You can get at the user's path with the USERPROFILE environment variable.

I only use the registry to associate the app with an extension (.foo -> MyProg.exe), to have the proper icon show up, and to have the right things happen in the Windows Explorer context menu (right-click on a .foo program, and it pops up the right options).
EKB Send private email
Friday, December 09, 2005
"Microsoft explicitly discourages the use of the Registry on their website for the past ten years."

I would be interested in seeing a link for this.
Kyralessa Send private email
Saturday, December 10, 2005
Douglas... have you ever tried using your system on a day to day basis logged in as a guest? Applications that want plugins/settings in their programs files\app folder are a royal pain to deal with. Don't take my word for it. Take the test. Create a second user with ohm... normal user permissions. Now, for the next week, do not use your administrator password. Try it. You will instantly discover applications/games that should never have been released to a winnt platform.
Sunday, December 11, 2005
"A good place to put config files in Windows is in:

C:\Documents and Settings\USER\Application Data\PROGRAM

You can store preferences for individual users this way. This is where I put most program settings. You can get at the user's path with the USERPROFILE environment variable."

That's a pretty good idea for most applications, but maybe not for DLLs or COM objects that you want usable from both applications and NT Services. In the latter case, there is probably no user account available as most services run under local system. There may be a way around it if you look deeper.
MBJ Send private email
Monday, December 12, 2005

Since all you want to support is YOUR program, it would be easier to have config files under your program folder, I guess...

Too bad for the desktop support guy who supports 20 programs, all with their own special ini files, stored in 20 seperate folders...

The registry, if used properly, can be a great tool for centralizing configuration information.

Why is it so hard to use?

I'm a Windows guy who has been learning Linux for the last year or so, and I cannot believe how many config files that OS and its basic programs have... spread all over the file system...

Pretty much no central repository at all... Appears to be a huge mess to me.

(Still, I'm glad to hear you programmers actually USE editable configuration files. Nothing sadder than a program with everything hard-coded - Do you know that Symantec Anti-virus has the location of their log files hard-coded? Log-files that sometimes go wild and fill up a hard drive...)
Monday, December 12, 2005
MBJ - Agreed! Using the "Application Data" folder isn't a good solution for shared components.

RR - My experience with Unix/Linux is that after the initial shock of seeing all those config files, I realized that there are characteristic places to look for them: ~user/.*, /etc, and so on. (A lot like getting used to where things can appear in the registry.) And I really really like plain text files. Overall, I ended up preferring *nix config files to the registry.
EKB Send private email
Tuesday, December 13, 2005
If you have writable, shared data on a per-component basis, then the accepted place for this stuff is the Application Data folder under the "All Users" profile.

This will require admin privs to set up, and you'll need to give whatever user is running the shared component appropriate ACLs, but it's not too onerous.

The reason not to put this stuff under Program Files/your application root is that Program Files should be read-only, and is for everyone except Admin under W2k3.
Chris Tavares Send private email
Tuesday, December 13, 2005
It should be noted that in Linux/Unix the config files are mostly designed to be human editable -- that's how you configure the application.  In Windows, the registry is just a storage location and most configuration is done within the application itself (or using an external config application).

If you want to look at an example of bad unix configuration look no further than sendmail! -- it's 100 times more horrible than the Windows registry as a whole.
Almost H. Anonymous Send private email
Tuesday, December 13, 2005
Both approaches have pros and cons.
I bend to registry but is a personal choice.
But there is one thing that should not be done with ini files, that is, using them to start an application with different modes changing simply the .ini file. You are never sure of what the correct one is.
In addition, editable files are much more prone to syntax errors, letting you scratch your head and wondering why the dns that you have just created is not found by your application
Sevenoaks Send private email
Wednesday, December 14, 2005
"Too bad for the desktop support guy who supports 20 programs, all with their own special ini files, stored in 20 seperate folders..."

When all support files are in the application directory it makes it much easier maintain  You copy the directory tree and you are done.  You have settings complete, mark the directory read-only. 

I understand the read/only desire.  Don't necessarily disagree either.

It's just that using the users document directory smacks of bad planning to me.
Wednesday, December 14, 2005
If you want a great way to edit your preferences, try prefEdit at You'll never have to look at the registry again!
Pete Send private email
Thursday, December 15, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz