Before I begin, I will disclaim two things. First, I am not a developer. Second, I was not at Microsoft during the formative years of Windows, nor was I there for the creation of Windows 95 or NT 3.1 – I was there during the development of Windows XP and the first 2/3rds of Longhorn’s gestation into Vista.

Depending on who you ask, the Windows Registry is either a necessary evil, or just plain evil. The registry was never intended to hurt anyone or make life difficult – quite the contrary. The registry was intended to right many of the wrongs that the .ini file format used by Windows prior to 95/NT to some extent caused, and couldn’t be resolved without a redesigned approach.

My understanding is that the Windows Registry was originally intended to be a central repository of COM-related information. It grew and blossomed to the point Windows uses it pervasively (.ini files are largely relegated to “portable” applications or applications where the developer has gone out of their way to not use the registry. The registry today is used by Windows beginning at boot, through the entire boot process, and is constantly being queried or written to by applications (run Process Monitor and take a look – Windows apps never shut up when it comes to the registry). It is used for the storage of state information (configuration). User state, application state,  and operating system. Therein lies one of the biggest problems the registry has – it’s a dumping ground – but we’ll get back to that.

Depending on who you ask, .ini files can also have a pretty bad reputation. But they did their job pretty well. .ini files, like the registry, held configuration information. The file structure of .ini files was a section header followed by name/value pairs that could, but didn’t need, quotes.

[fox]
speed=quick 
color=brown 
action="jumps over the lazy dog"

Easy enough, right? Name/value pairs should get you all the configuration state you could want… Or not.

What was wrong with .ini files?

.ini files had several drawbacks. In particular they suffered in that there was:

1. No uniform storage location.
2. No central management.
3. No centralized backup mechanism.
4. No security infrastructure.
5. No Unicode, no binary values, no strongly typed values, no arrays (all ASCII text-based).
6. Little protection against corruption
7. Slow performance
8. No central editing capability
9. No user-friendly tool to edit them

The “single entry point” of the registry through either regedit.exe/regedt32.exe and .reg files used for import/export of information surely got rid of the problem: “I have no idea where the settings for this application live on the file system”. But instead they also introduced a new problem, “I have no idea where the settings for this application lives in the registry”. You also couldn’t ever be certain if changes you made would be fatal to the application or OS. The fact that Microsoft never provided a broad “undo” feature in the registry even in the event of failed boots really lent credence to their often heard “Abandon hope all ye who enter here” mantra first heard terrifying consumers during the beta of Windows 95 (nee Chicago).

To export and import registry files, the entries (which can be Unicode, and are binary) have to be serialized out. Amusingly if you ever look at a .reg file exported from the registry, entries that are just text are exported in a format effectively identical to .ini files. Data that can’t be represented in that manner (multi-string arrays, for example) get exported in a binary format within the .ini format – effectively a hybrid .ini file.

The Windows registry consists of multiple files stored under C:\Windows\System32\config, which each represent different hives of the registry. So rather than a bunch of files all over your system, a finite number of files store all of the settings used by almost all of Windows and all applications, but it is not mandated where these settings must live. Sure, there are best practices, but no steadfast rules as to where, or how, settings should be stored, and when they should be queried. As a result, we can see those applications polling the snot out of the registry… WHY?!?!?! Because the registry had no barrier between operating system state, application state, and user state, Windows lost, then slowly regained features such as network boot of the operating system (Hibernate Once, Read Many, or HORM, in Windows Embedded), network-based, one-click application deployment (App-V) which works using filesystem and registry tricks. In fact, if you look closely at a lot of the features in Windows 2000’s IntelliMirror featureset, the need for many of them can really be traced back directly to the registry. Even Windows Group Policy, which applies templates of settings against the registry, would arguably have been easier to implement with .ini files. Intriguingly, template files for Group Policy are now XML-based. Windows XP also began a herculean effort to separate Windows user interface strings (like “Control Panel”) from the registry that should have either been in a standalone configuration file or DLL to begin with. This wasn’t really completed until Longhorn. The “Multilingual User Interface” (MUI) packs in Windows XP will often expose this. For example, one area of the OS will say “Control Panel” and others will say “Panello di Controllo” when running Windows XP Italian MUI.

Had proper state separation between the OS/apps/user been maintained, and not in a monolithic per-system datastore, Windows might be significantly easier to deploy, manage, and secure today (though it would surely have other foibles as a result).

Microsoft has bought whole companies to try and undo some of the mayhem caused by the registry – but most of them are duct-tape bandaging over the problem, not fixing it (Softricity, Apptimum). Even many of the tools we made at Winternals were necessary to try and repair a system because of the registry.

Personally I’ve always been frustrated at how long Windows takes both to install the OS (something we tried to rectify with Longhorn by putting down an image of the OS instead of hand-stitching the registry at deployment time – one of the aspects of Windows setup that took the longest prior to Vista. But what about applications? Applications are simply a bundle of files and registry settings, and their installers exist solely to bind the collection of files to the operating system. So why did Windows installer ever become such a slow, cumbersome means of installing applications? Why couldn’t Windows applications, like many Mac applications, simply be click to install? The complexity introduced by the registry made the installation of the OS, and applications, take far longer than it ever should have. Simply recall running Office from a network share on Windows 3.1. It didn’t have to be this complicated.

I often felt that at Microsoft, sometimes the cool solution won out rather than the simple solution. Sure, the registry had some promise to fix problems inherent to the .ini file format. But I have to wonder if it didn’t create more problems than it solved, and if the creators (or Microsoft management) understood the problems created by it if they would have ever gone the registry route, or tried to advance the .ini file format.

What does everybody else do?

The configuration files used for Linux and for NeXTSTEP are/were also text-based. Prior to OS X 10.0 shipping, NeXT systems used a “pref” file format that looked, to me, similar in some ways to JSON data, but served the same purpose as a .ini file. Apple, for better or worse, drank the XML Kool-Aid and switched these over to XML – but not XML as you know it. It was an XML format that only a mother could love (see related reading at the end of this post).

Apple later switched to a binary pref file format. All three pref file formats can be found within OS X today. I don’t believe that there is a central editing facility for pref files across OS X, but there is a built-in editor that can be used by consumers, though I’d hardly call it user-friendly.

So why did OS X switch? The most likely culprit is performance, though there is some marginal claim that it was done for space reasons. I can tell you when we built the WIM imaging format for Windows Longhorn, we started with an XML file manifest of all the files we were storing (leading to haxors having a field day with the image we handed out at PDC 2003). When we switched not long after PDC to a binary format for the file manifest, it did indeed result in a significantly smaller file, but more importantly, it improved performance quite dramatically. The haxors who had earlier tinkered with the WIM format accused us of changing to binary to foil them. Couldn’t have been further from the truth.  So I think Apple likely changed primarily for performance, regardless of what was said.

So what would be better for Windows in the future?

Simply put? Binary .ini files. I don’t believe any version of Windows we’ll see for the foreseeable future will throw out the registry for any new format, so making wishes is likely a wasted exercise. Designing this new format with proper state separation between settings for the OS, applications, and the user are all separated would be key. Realistically, it should be a melding of .ini files and the registry – but in many ways would more likely be a cloning of the pref file infrastructure from OS X. Amusingly, as we look towards Windows 8 and Windows Phone 8, the registry very much lives on, and is not dead – though a user’s day to day activities are less reliant upon it. Applications in the new WinRT realm may not know about it directly, but will wind up having some state stored there on their behalf by the operating system. Other application and user state for WinRT apps? Well, it’ll likely live in XML manifest and other configuration files stored with the application itself or in the user’s profile. The new old thing.

Related Reading

1. A Forensic Analysis Of The Windows Registry
2. Comparing the Mac OS X Property List to the Windows Registry
3.  INI file (Wikipedia)
4. Apple’s Property List XML Is Pointless