On 12.03.2010 16:11, Adrian Buehlmann wrote:
>> Autsch. Now I remember. That's why 1.6.5 had problems with the overlays!
>> Forget version 1.0.15 - I'll remove that once I get home.
>> Go back to version 1.0.14.
> I looked at the change in the code you did and I do think it is an
But there's an overlay not accounted for.
According to Raymond Chen, there are more overlays not listed in the
As you can see, he lists the following overlays:
* A small arrow. This is still the shortcut overlay.
* A padlock. This means that you have a private item in a
non-private directory. (See below.)
* A downward-pointing blue arrow. This is still the "to be written
to CD" overlay.
* A pair of green swirly arrows. This means that the item is
available offline. This used to be a pair of blue swirly arrows.
Apparently, green is the new blue. (See below for more discussion.)
* A gray X. This means that the file has been archived to tape and
will take a very long time to access. (Formerly, a black clock.)
From this list, I only have the "private item", "to be written to CD"
and "Offline" overlay listed in the registry.
The shell link and the "archived" overlay aren't listed there.
And Raymond forgot the UAC overlay.
So: there are three overlays not listed in the registry, not two as we
assumed. So I have to reduce the limit to 13 again instead of 14 as now.
Or do you see that overlay listed in the registry?
>>> (1) The ordering of the entries in
>>> is relevant
>> Nope. At least not on XP and Vista.
>> There, the order in which the RegEnumKeys() returns the keys is
>> relevant, and that API returns there the keys in the order in which
>> they were created. Renaming them won't do anything.
>>> (2) The entries are loaded in alphabetic order
>> No again.
> Very very strange. That much lucky unrelated coincidence on my side?
Well, it's not documented, so MS can change the load order any time they
From what I've discovered, the load order depends on OS version and
some language setting I haven't really found out which one exactly.
And it also depends on the service pack installed (on XP at least, from
what I found in my tests).
That means we can't assume anything about the load order. It might be
alphabetically for you now, but it can change.
> I just tried the renaming trick on Vista Ultimate x64 SP2 as well.
> After doing the renaming, the unversioned overlay starts appearing.
> If I rename the entries back, the unversioned overlay is gone again.
> The trick works repeatably.
> Plus I've never seen a problem with the unversioned handler on x86
> (which uses the different naming scheme as I explained it).
> Everything pure luck?
You're using an English OS?
I'd say it is pure luck.
>>> (3) Entries that exceed a limit of entries (whatever that is) are ignored
>> Now that's true.
>>> On Windows 7 x86 the unversioned overlay -- as installed by
>>> TortoiseOverlays x86 version 1.0.15 -- works fine, since it installs its
>>> keys under
>>> using the following
>>> names (complete listing of the entries found below that registry key):
>>> Offline Files
>>> So there, it seems we have an ordering that happens to be favorable for us.
>>> Is there any specific reason for using different names in
>>> TortoiseOverlays x64 (compared to the ones used in TortoiseOverlays x86) ?
>> I'll check.
> Thanks a lot.
> But if *your* claim is correct, then the name of the entries don't
> matter (which I have very strong doubts about).
I've changed the wix file so that the x64 version now uses the same
registry keys as the win32 version.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-12 20:49:00 CET