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("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. 🙂


A wandering geek. Toys, shiny things, pursuits and distractions.

View all posts by

4 thoughts on “A Peek Under the Covers – Windows XP Registry Keys

  1. I believe several of your complaints might be Java-specific. I’ve not done much programming at all, especially writing to the registry. However, I have been a Windows admin for 12 years, and this is the very first series of registry keys I’ve ever seen with a “preface uppercase with “/”
    Check this screenshot to see what a Microsoft key looks like.
    Rob / Aniar

  2. That’s interesting. I wonder if this pattern is because Registry keys are not case-significant, and something is being done to specifically insure case stabilization.
    Aha. I’ve found an article that specifically states this adaptation is because the windows registry is not case specific:

    You’ll see the result of running the code above under J2SE Beta 1.4 for Windows in Figure 1. Note that WML is encoded as /W/M/L, and PreferredChannel as /Preferred/Channel because Preferences has case-sensitive keys and node-names, while the backing store of choice (in this case Windows Registry) does not.

    I still think this is a poor choice for managing case in the backing store, and I suppose it might be Sun’s choice, but it’s ugly as all git out.
    Regedit is still annoying though 🙂

  3. Oh, I agree, the registry is difficult, unwieldy, and a pain. And since moving to GNU/Linux as my primary OS, I miss case-sensitivity every time I’m back in Windows. Regedit I’m used to by training – I guess that happens with any tool you use long enough, even if it’s not perfect.

Leave a Reply

Your email address will not be published. Required fields are marked *