A Peek Under the Covers – Windows XP Registry Keys

While working on my current Java project, I needed to better understand how the Preferences API stores data. My initial instinct was to dig around in my home directory looking for a .java/Preferences file or something similar. Perhaps under Linux, this would have been the case, but Preferences is platform agnostic, and under Windows, it uses the Windows Registry.

I’ve long since tried to drive out my knee-jerk reaction to the Registry. The initial implementations of it were awful, and prone to easy corruption. Navigating the registry has never been what one would call ‘simple’, but after a while things settled down a bit and stabilized.

In this case, I was using a simple Java command to store some values for a Webstart launched client:

prefs = Preferences.userRoot().node(nodeName);
prefs.put("ExpoLoginName",userField.getText());
prefs.put("ExpoPassword",new String(passwordField.getPassword()));

Pretty straightforward stuff. In general, the code was working as expected, but I was seeing doubling of some of my values. What I needed to be able to do was actually see the registry stored values themselves, without going through the interface, to see if I was actually storing the values properly, or things were going wrong on the way out.

This unfortunately brought me in contact with the Windows native tool ‘REGEDIT’. This tool came out quite a while ago, and is the defacto standard way of editing, browsing, and searching the Windows Registry. Unfortunately, regedit hasn’t seen any interface upgrades in approximately an eon. It is painfully difficult to work in, and while yes, it gets the job done, little interface quirks can flat out destroy productivity. For example. The FIND function (amazingly, bound to ‘^F’), does in fact let you search the registry for a key or value. But, it is a one-way search, from the current position forward. It does not wrap. It also does not RESET when you change to a new search term. So if your first search finds a match, say, at the 5th from the bottom key (by the way, the window does not scroll to show you where your match hit. You have to scroll it manually), and you decide to search for a second term, it will only search the last 5 rows in the registry.

I lost half an hour searching for keys I KNEW were in the registry, because my first search had set the pointer so low. GAARRRHHHH!

What I found most entertaining about this path was it gave me a chance to look under the thin veneer of civility that Windows brings to the operating system experience. Take for example the screen shot above. Note that the keys stored in the registry have been altered from their internal values. Some bright Windows developer back in the dark ages realized they should tell the difference between an upper case letter and a lower case letter. Rather than, say, writing that into the logic of the registry, they cleverly decided simply to preface upper case characters with a forward slash.

Ah, but that brought up a problem! You could now not store a forward slash into the registry! Not to worry, we’ll just change any forward slashes in the registry to backslashes! Sounds like a great plan!

This sort of tortured logic is what you see happening in student built technology experiments, hacked together during all night jolt-driven marathons. It’s not something you’d see in the largest software company in the world. Their programming practices, in theory vastly improved from the early days, wouldn’t allow such awful hacks.

Would they?

Update – it appears, due to notes in the comments, that the registry values hack is due to Java’s interpolation, not Windows. Java needs to specify slashed items because the backing store being used in this instance (Windows Registry) is case insensitive. If a different backing store were being used, that wouldn’t be happening. My apologies to Redmond for assigning blame. On this one thing. 🙂