It was déjà vu, man. Pure déjà vu....

by Michael S. Kaplan, published on 2007/03/24 03:47 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/03/24/1941034.aspx

It happened some time ago. Right after the Community Server update on the blog, in fact.

I was bothered by the way that the links over on the right hand side were displayed in the order they were added, even though in the design interface they were sorted alphabetically.

This drove me nuts since the re-ordering buttons were gone and it was now a huge pain to sort them in the order you wanted given that the interface for adding them would never show the order they were going to be displayed in. I kind of gave up on ordering them, mostly -- too much of a pain in the ass.

But let me tell you, It was like déjà vu for me.

The whole problem -- a user interface for modifying a list being in one order while the actual order it was an interface for being something else? I had definitely been there before....

The first time was a while back.

Long before Vista shipped, in fact.

Mike and I were going over to talk to a man named Dragos.

We were looking for some ideas on the best way to optimize an HKCU registry story that we couldn't get out of just yet, and if anyone could help us figure out how to make things go faster, everyone said it would be Dragos.

It was a great meeting, and one of the reasons that working at a place like Microsoft can be a lot of fun¹.

A bunch of good old fashioned developer geek brainstorming happened in that meeting, as we laid out what we were doing and what we had tried, and he suggested some things for us to try out that just might make things better.

One of the things he suggested had to do with the way registry values (i.e. the ones you would get from RegEnumValue) were stored.

Turns out that the order you see in RegEdit is just a fluffy sort done in the tool, the actual order happens to be a FIFO kind of thing, with them stored in the order they are added. Changing a name keeps the position as it was, but renaming would delete and re-add and the value would be at the end of the list. And when you read values in from a function like RegQueryValueEx or the new RegGetValue (Larry Osterman's "favorite" Win32 API function from last January), the OS scrolls through the values until it reaches the one you wanted (kinda what you'd have to do yourself if you were doing it yourself by calling good old RegEnumValue, which is not a coincidence).

"Would it always be this way?" I wondered later in mail to Dragos, thinking about the comments in this post of Raymond Chen's, where he warned:

There is no guarantee that the order of RegEnumValue will be "in order of creation". The registry code was tweaked for performance in Windows XP and I suspect it will be tweaked for performance in the future. One of these tweaks may change the order of enumeration, since that is unspecified.

and the Platform SDK documentation about the order in RegEnumValue:

dwIndex
The index of the value to be retrieved. This parameter should be zero for the first call to the RegEnumValue function and then be incremented for subsequent calls.

Because values are not ordered, any new value will have an arbitrary index. This means that the function may return values in any order.

I was encouraged not to worry in our case, since

• in the first place the docs here are pretty much just plain wrong. But since there is no UI that shows the actual order, so from a user's point of view, it really is kind of arbitrary, so it is not quite so wrong;
• in the second place even if it did ever change, it would not happen in a service pack -- that would be a pretty big re-architecting;
• in the third place, something like that would obviously be communicated widely to developers working on Windows in a future version.

So as long as we were willing to not cry foul later if we ended up having to rethink our optimization (due to the registry having had its architecture rethought), then there was no reason to worry (note that most people are not willing to do that, which is why Raymond's specific warnings in this case about undocumented behavior are completely true -- the unclear doc story tells people plain as day that they can really only rely on bubkes in the long run!).

I only mention it here because I know the people who read this blog are really smart. Like DNRC smart. Never the kind of people who would only read the first half a paragraph while ignoring the warnings in the second half.

(Plus if somebody wanders in after a Google search who isn't as smart, someone can make them feel plenty foolish for not reading the whole thing, so it all works out!).

Now you may be wondering, if the original incident happened years ago and the one that inspired the deja vu happened a while go too, why I am taking about this now. Especially since neither story has much to do with the internationalization kind of posts I usually do.

The answer is that it is all a kind of a foundation sort of thing, one that I will be using as the basis for my next post.

Plus it makes for a good story, don't it? :-)

1 - It is actually one of the things I like about my new job -- I get to spend time in the same sort of meeting, and even get to be the person who is pointing out the best way to do things!

This post brought to you by Й (U+0419, a.k.a. CYRILLIC CAPITAL LETTER SHORT I)

# Dean Harding on 25 Mar 2007 8:14 PM:

# Michael S. Kaplan on 25 Mar 2007 8:49 PM:

referenced by

go to newer or older post, or back to index or month or day