When - and why - should you store data in the Windows Registry?

Question

As a developer, tools that store configuration/options in the registry are the bane of my life. I can't easily track changes to those options, can't easily port them from machine to machine, and it all makes me really yearn for the good old days of .INI files...

When writing my own applications, what - if anything - should I choose to put in the registry rather than in old-fashioned configuration files, and why?

Norty

I work with a legacy app right now that stores information in the registry (.NET app), and it drives me nuts. – Legg

Answer 1

• Originally (WIN3) configuration was stored in the WIN.INI file in the windows directory.
• Problem: WIN.INI grew too big.
• Solution (Win31): individual INI files in the same directory as the program.
• Problem: That program may be installed on a network and shared by many people.
• Solution(Win311): individual INI files in the user's Window directory.
• Problem: Many people may share a windows folder, and it should be read-only anyway.
• Solution (Win95): Registry with separate sections for each user.
• Problem: Registry grew too big.
• Solution (WinXP): Large blocks of individual data moved to user's own Application Data folder.
• Problem: Good for large amounts of data, but rather complex for small amounts.
• Solution (.NET): small amounts of fixed, read-only data stored in .config (Xml) files in same folder as application, with API to read it. (Read/write or user specific data stays in registry)

Beamends

Unix: config stored in $HOME/.your-app There, solved in one iteration. – Doughty

Unix solution is far from ideal too: $HOME is bloated with dot-files, and you have no idea what most of them do. – Kirbie

@Doughty XDG actually mandates that you should put your config files inside $HOME/.config/your-app/, a solution created to deal with the problem @grep objects to. And, surprise, modern Linux (and anybody on the *BSD's crazy enough to use GNOME) also has a registry in the gconf suite. FOSS breeds choices, that's for sure ;) – Goop

@grep, Re "no idea what most of them do", Why not? Besides, the bloat is hardly comparable with that of Windows. – Tusk

Answer 2

Coming at this both from a user perspective and a programmers perspective I would have to say there really isn't a good exceuse to put something in the registry unless it is something like file associations, or machine specific settings.

I come from the school of thought that says that a program should be runnable from wherever it is installed, that the installation should be completely movable within a machine, or even to another machine and not affect the running of it.

Any configurable options, or required dlls etc, if they are not shared should reside in a subdirectory of the installation directory, so that the whole installation is easily moved.

I use a lot of smaller utility like programs, so if it cant be installed on a usb stick and plugged into another machine and just run, then its not for me.

Salpingotomy

But installation is often done under admin control, while updating settings must be done under user control. Imagine trying to update settings - an app running under the user's identity that wants to write to a directory that is restricted to admin-access only. This is one of the things the registry is intended to address. – Shunt

@Cheeso, The solution is for each user to have a copy of the executable. To save space, not a real copy but just a fake copy (pointer). – Tusk

> "says that a program should be runnable from wherever it is installed, that the installation should be completely movable within a machine, or even to another machine and not affect the running of it." say that to flatpak users :) – Turdine

Answer 3

When - You are forced to due to legacy integration or because your customer's sysadmin says "it shall be so" or because you're developing in an older language that makes it more difficult to use XML.

Why - Primarily because the registry is not as portable as copying a config file that is sitting next to the application (and is called almost the same).

If you're using .Net2+ you've got App.Config and User.Config files and you don't need to register DLL's in the registry so stay away from it.

Config files have their own issues (see below), but these can be coded around and you can alter your architecture.

• Problem: Applications needed configurable settings.
• Solution: Store settings in a file (WIN.INI) in the Windows folder - use section headings to group data (Win3.0).
• Problem: WIN.INI file grew too big (and got messy).
• Solution: Store settings in INI files in the same folder as the application (Win3.1).
• Problem: Need user-specific settings.
• Solution: Store user-settings in user-specific INI files in the user's Window directory (Win3.11) or user-specific sections in the application INI file.
• Problem: Security - some application settings need to be read-only.
• Solution: Registry with security as well as user-specific and machine-wide sections (Win95).
• Problem: Registry grew too big.
• Solution: User-specific registry moved to user.dat in the user's own "Application Data" folder and only loaded at login (WinNT).
• Problem: In large corporate environments you log onto multiple machines and have to set EACH ONE up.
• Solution: Differentiate between local (Local Settings) and roaming (Application Data) profiles (WinXP).
• Problem: Cannot xcopy deploy or move applications like the rest of .Net.
• Solution: APP.CONFIG XML file in same folder as application - , easy to read, easy to manipluate, easy to move, can track if changed (.Net1).
• Problem: Still need to store user-specific data in a similar (i.e. xcopy deploy) manner.
• Solution: USER.CONFIG XML file in user's local or roaming folder and strongly-typed (.Net2).
• Problem: CONFIG files are case-sensitive (not intuitive to humans), require very specific open/close "tags", connection strings cannot be set at run-time, setup projects cannot write settings (as easily as registry), cannot easily determine user.config file and user settings are blown with each new revision installed.
• Solution: Use the ITEM member to set connection strings at runtime, write code in an Installer class to change the App.Config during install and use the application settings as defaults if a user setting is not found.

Mond

This is far more complete answer than the approved one. Thanks @AndrewD. – Ping

Answer 4

Microsoft policy:

• Before windows 95, we used ini files for application data.
• In the windows 95 - XP era, we used the registry.
• From windows Vista, we use ini files although they are now xml based.

The registry is machine dependent. I have never liked it because its getting to slow and it is almost imposible to find the thing you need. That's why I like simple ini or other setting files. You know where they are (application folder or a user folder) so they are easy portable, and human readable.

Rayleigh

Can you provide an original link to the doc that states this policy of microsoft? And when you say policy, do you mean, this is what Microsoft does, or do you mean this is what Microsoft recommends to devs who build apps for Windows? – Shunt

ps: raymond Chen of Microsoft has stated that INI files are deprecated in favor of the Registry, and explains why. blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx He also states that XML files have many of the same drawbacks as ini files. – Shunt

XML settings files = INI files that are harder to parse – Elector

@Fraser if you think parsing XML is difficult, you are in the wrong business. – Surber

@SnakeDoc, Harder does not mean more difficult. It simply means slower parsing and lag. – Tusk

@Tusk What? Parsing XML can be very fast indeed (as fast as your disk will read the file). – Surber

@SnakeDoc, XML parsing is one of the slowest ever. Ini files and simple format files are magnitudes faster. – Tusk

@Tusk That sounds like an unsubstantiated, baseless claim. It will depend on scenario, and how big the files are expected to be, and of course your disk speed. Even Microsoft seems to recommend System.Configuration namespace these days, which is based on XML. – Surber

Answer 5

Is the world going to end if you store a few window positions and a list of most recently used items in the Windows registry? It's worked okay for me so far.

HKEY-CURRENT-USER is a great place to store trivial user data in small quantities. That's what it's for. It seems silly not to use for its intended purpose just because others have abused it.

Calabrese

Answer 6

Registry reads and writes are threadsafe but files are not. So it depends on whether or not your program is single threaded.

Rizzo

Answer 7

Settings that you want to have available in a user's roaming profile should probably go in the registry, unless you actually want to go to the effort of looking for the user's Application Data folder by hand. :-)

Obadiah

Answer 8

If you are developing a new app and you care about portability you should NEVER store data in windows registry since other OS don't have a (windows) registry (duh note - this may be obvious but gets often overlooked).

If you're only developing for Win platforms ... try to avoid it as much as possible. Config files (possibly encrypted) are a way better solution. There's no gain in storing data into the registry - (isolated storage is a much better solution for example if you're using .NET).

Oarlock

This is partially true. Mono has implemented the Microsoft.win32 namespace for registries - except it stores it in a file in ~/.mono/Registry in an xml file, and it's handled transparently. Now if you could turn the xml handling on for any app, regardless of platform... – Runyon

Note: only available you if you're writing a .NET/Mono app. – Runyon

The registry does afford a gain: the data is more easily accessible in a multi-threaded application. More importantly, it allows you to separate configuration data that is machine specific vs. user specific. Your application does not have to be aware of who is logged in when it accesses HKEY_CURRENT_USER. You're right about the portability, though. – Persse

Answer 9

Slightly off-topic, but since I see people concerned about portability, the best approach I've ever used is Qt's QSettings class. It abstracts the storage of the settings (registry on Windows, XML preference file on Mac OS and Ini files on Unix). As a client of the class, I don't have to spend a brain cycle wondering about the registry or anything else, it Just Works (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

Octopus

It appears the url is not working anymore. An update reference should be qt-project.org/doc/qt-5/QSettings.html#details – Tetrabasic

Answer 10

Personally I have used the registry to store install paths for use by the (un)install scripts. I'm not sure if this is the only possible option, but seemed like a sensible solution. This was for an app that was solely in use on Windows of course.

Gilding

Answer 11

In .NET there really is NOT ever a need.

Here are 2 examples that show how to use Project proerties to do the this.

These examples do this by Windows User Project Properties, but the same could/can be done by Application as well.

More here:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

Emelyemelyne

Answer 12

Usually, if you don't put settings in registry, you use it mostly to get current Windows settings, change file associations, etc.
Now, if you need to detect if your software is already installed, you can make a minimal entry in registry, that's a location you can find back in any config. Or search a folder of given name in Application Data.

If I look at my Document and Settings folder, I see lot of softwares using the Unix dot notation for setting folders: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (etc.)

and in Application Data, various folders with editor names or software names. Looks like being the current trend, at least among portable applications...
WinMerge uses a slightly different approach, storing data in registry, but offering Import and Export of options in the config dialog.

Schmaltz

The Unix dot notation that you see is probably because all of those examples are of ported open-source projects, not because it is a best practice for Windows development. – Persse

Indeed, I didn't said it was "best practice", but common practice... :) The folders in application data /are/ best practice, particularly for big data, but also because they are easier to back up. – Schmaltz

Answer 13

I believe that Windows Registry was a good idea, but because of great abuse from application developers and standard policies not encouraged/mandated by Microsoft grew into an unmanageable beast. I hate using it for the reasons you've mentioned, there are however some occasions that it makes sense using it:

• Leaving a trace of your application after your application has been uninstalled (e.g. remember user's preferences in case the application is installed again)
• Share configuration settings between different applications - components

Stir

I disagree with you regarding your first point, "[l]eaving a trace of your application after your application has been uninstalled". I'd rather that if I say "remove yourself from my system" that your app comply completely. I suppose it'd be different if you were asking the user if it's ok to leave something behind, but even then I'd probably want it to be a saved config file. Licensing, etc. notwithstanding, if you're selling your computer and buying a new one, wouldn't you rather have a settings file you can load on the fresh install rather than something tied to the computer you're selling? – Cariotta

Many applications do this and you're right to say that it isn't a very good thing, especially if they do it without user's permission. However it is often the functionality users expect from an application (the majority of the user's don't know what the registry is). The users just expect to find their settings auto-magically back again, when they uninstall and install again. – Stir

I think we found us a malware author here. Don't ever leave crap from your program on someone's system if they asked you to uninstall. At least ask them if they want to remember settings, etc. Don't ever just do it. What if you store a license key and I sell my computer? What if your program was causing problems on my computer, and I tried to uninstall to fix it? Well, your registry leftovers could cause me a lot of problems. Just don't do it. Just don't. – Surber

Answer 14

(late to the discussion but) Short Answer: Group Policy.

If your customer's IT department wants to enforce settings related to Windows or the component(s) you're writing or bundling in, such as a link speed, or a custom error message, or a database server to connect to, this is still typically done via Group Policy, which makes its ultimate manifestation as settings stored in the registry. Such policies are enforced from the time Windows starts up or the user logs in.

There are tools to create custom ADMX templates that can map your components' settings to registry locations, and give the administrator a common interface to enforce policies (s)he needs to enforce while showing them only those settings that are meaningful to enforce this way.

Commissure