The registry. That is what they decided to call it. Kind of neat-sounding, but also revealing nothing about its purpose. It is like Area 51. Who knows what bodies information is stored in there?

The windows registry is fairly mundane, as it happens. No bodies here. It has been around for a while – since windows 3.1. However, it didn’t gain its present use until windows 95. Time for a little history lesson.

Ye Olde Windows

Applications have configuration files. When you change something in an application’s settings, it is stored in a file. For example, when you save a file, it opens to a specific location like My Documents. If you save a file somewhere else, the next time you save a file it opens there instead. Poof, magic. This works by storing the previous file path in the settings.

Around the time of windows 3.0, dinosaurs roamed the earth applications stored their configuration in a file format called INI. The way INI files were used had a number of problems. The list is long and somewhat technical (ahem, much like my accomplishments), but included things like being slow, having no file security, having no Unicode support, and that multiple applications changing settings at the same time could cause file corruption.

The registry was designed to fix these problems. It would be a centralized storage for application settings – both typical third-party applications as well as native windows applications, like file explorer. It was first used for this purpose in windows 95.

Format

The registry consists of keys and values. It is similar to how your files are stored. Keys are like folders – they contain multiple items. Furthermore, keys can contain keys, so there are multiple levels. Key bonanza! Values are like files. They are the actual data contained within the key system. In effect, keys are the filename, and the value is the file.

Values are generally much smaller than files. They are a single item of a certain type, like a number or some text.  For example, there might be a key with name “LastDestination” holding a text value that is used for the file save example I mentioned before.

In the file system, there are drives like C:. These drives provide the file system root – the base of the entire file system which all files and folders are relative to. This root structure is used for the key hierarchy in the registry. The registry has several different roots, among them HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, and others. They each hold a specific category of data. For example, HKEY_CURRENT_USER stores configuration settings for the currently logged-in user, whereas HKEY_LOCAL_MACHINE holds global system and software settings.

The registry is typically accessed in one of two ways. Programs access it using the windows API. Users access it through a GUI editor called regedit which is included with windows. Regedit is, more or less, file explorer for the registry. With it you can, as the name implies, edit the registry. Given the important settings the registry holds, it is recommended that you back it up via regedit before modifying it as certain changes can make the system fail to boot properly, or otherwise function improperly.

The registry is loaded into memory when the system starts, and modifications to it are made in memory. This is more efficient than endlessly loading and unloading it from the disk. However, it does have to be stored to disk eventually so it persists after shutdown. The files that store registry settings are known as hives. Another strange name, isn’t it? Legend has it one of the early windows developers was not so fond of bees. Apparently the developer working on the registry was aware of this fact, and filled the registry with bee references, hence hive.

Many of the root keys are stored in their own hive files, but not all: some root registry keys are actually relative to a key in another root key – basically, they map to a subfolder somewhere for ease of use. The primary system hives are stored in C:\Windows\System32\Config. The user-specific files are stored in a file called ntuser.dat located at C:\Users\Username, which contains the keys and values for HKEY_CURRENT_USER when you log in.

Typical Use

The registry can be used for a number of things. How applications use it is mostly up to them, although there is a common location where application registry keys are stored. Most system configuration options are stored in the registry as well.

One of these options is file associations. That is, what program opens what type of file based on the extension. For example, .html files open in your browser. When you open a file in file explorer, it checks the registry, finds the program associated with that file extension, and runs it. These file associations are stored in HKEY_CLASSES_ROOT.

Many other file explorer options are also stored in the registry, such as the options available on right click (e.g. “create new”). Typically when programs that work with files are installed (such as a compression program), they will add themselves to this list by adding keys in the registry. Unfortunately, some of these programs aren’t as good at removing the relevant keys once they are uninstalled, and as a result their file option is still in the file explorer menu. Given that you know the menu options are stored in the registry, you can manually remove problem entries in the registry yourself to fix the problem.

Another area of interest is startup programs, which are also stored in the registry. This includes not just startup programs, but also tasks and services.

Problems

Unfortunately, the registry has problems as well. In hindsight, it just wasn’t a very good idea – one might say there is a… stinging regret.

The first problem is that it is a binary mess. Many configuration files are stored in a text format like XML. This is not the case with the registry, as it is all binary. Furthermore, the binary is based on what the Microsoft compiler chose to do way back then. Endianess is a mess, as is data size (words). If a key isn’t formatted just right, it is silently ignored like it doesn’t exist at all (I believe you are familiar with that), which can be used to hide information that regedit will not show you.

It is also rather disorganized conceptually. In many cases, there are keys that are duplicated in other places. It is also often hard to find where specific values are, as they can be in a number of different places. In addition to this, the registry is massive. Like, Jumbo the elephant took a look and ran away in terror. Terror, I tell you! Seriously though, there are so many keys in there it is hard to navigate.

Another problem is that the registry is a single point of failure. You are quite familiar with failure, I assume. The registry holds all those super-important system settings right next to the application settings. Every time you use a registry editor there is a warning about not screwing up your system because of that. But you should be able to change an application’s configuration without worrying about system settings.

The worst flaw with the registry, in my opinion, is that the file system is not reconciled with the registry. They aren’t connected at any level. As a user, I want to copy my program files, move them to another computer, and have them work. But if the program stores settings in the registry it will not work, because those weren’t transferred. Want to transfer the registry settings as well? Good luck finding where it put them. The same applies when you get rid of a program. If you just delete the program files, the registry values are left behind. Even if you uninstall it “properly” by running the uninstaller, it may fail or neglect to remove all the registry values, leaving you with a bunch of junk scattered throughout the registry. This is not very user-friendly.

But why, you say. Why did they make the registry when it has all these problems? Oh, the huge manatee! Hah, made you look. Anyway, it is like they say: hindsight is 15/20.

Solution

This is the part of the article where I tell you how they fixed the registry.

Oh wait… they didn’t.

That’s right. The registry is still with us today, which is probably why you are reading this article in the first place. It still has all the same problems. The primary reason for that is backwards compatibility. If they change how the registry works now, all the programs that use it will break. As it turns out, people don’t like broken programs, so Microsoft is stuck with supporting the registry for a long, long time. That being said, it is no longer recommended to use the registry due to the problems I mentioned.

If the registry is no longer recommended, what is? The new method is to store settings in a folder called AppData. This folder is stored inside your user folder, but it is hidden so you don’t normally see it. Inside AppData are three more folders: Roaming, Local and LocalLow.

Roaming stores settings that will roam with the user. Kind of like a cow roaming in grass, but completely different. Roaming, in the context of windows, refers to roaming profiles. The idea behind this primarily applies to a work environment where users log into a windows domain. For typical home users, if you want to use a computer, you have to use one of the local accounts on that computer. In a windows domain, you can log on with the same account on any computer within the domain. In the domain, you can have a roaming profile; this means things like application settings “follow” you around as you log in on different computers by transferring the files stored in the Roaming folder.

The Roaming folder isn’t only used for computers linked to a windows domain. Instead, it is used for settings that could roam, even on home computers. Effectively, the question is whether it would make sense for the files to be shared, regardless of whether they will be or not. It stores files such as browser bookmarks that are somewhat lightweight and things that are not specific to the computer they are stored on.

Local, on the other hand, stores things that are specific to the computer they are stored on, or things that shouldn’t be in Roaming. This may be settings that are specific to some software/hardware configuration you have where it doesn’t make sense to move them because they are specifically for their particular environment. There may also be files that, while they technically could roam, it doesn’t make much sense to do so. The biggest reason for this is file size. The primary thing stored in Local is file caches – your browser’s file cache, for example. These are rather large and temporary in nature to begin with, so they don’t belong in Roaming.

LocalLow is basically the same as Local and is intended to be used for security and sandboxing purposes. It is used the same way Local is.

Inside each of these folders are application folders that contains the actual files. For example, google chrome stores its file cache in C:\Users\Username\AppData\Local\Google\Chrome.

Note that the AppData folder is stored under a specific user. This means it only contains user-specific settings. This allows programs to use the same structure to store multiple users’ settings simultaneously.

The nice part about using AppData instead of the registry is that everything is stored in the file system. Earlier I stated the biggest problem (for me) with the registry is that the registry is not reconciled with the file system. With AppData, things are reconciled. If you delete an application’s files in AppData, they are gone. There is also a decent chance you can retain programs’ settings when moving programs to another computer by copying their AppData folders.

Despite AppData being the recommended way to store program data, there are programs that still use the registry. Additionally, windows still uses the registry for all of its core settings. Thus, the registry is still being used, and it isn’t going to go away anytime soon.