On 12.03.2010 20:48, Stefan Küng wrote:
> 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
>> improvement.
>
> But there's an overlay not accounted for.
> According to Raymond Chen, there are more overlays not listed in the
> registry:
> http://blogs.msdn.com/oldnewthing/archive/2009/12/09/9934348.aspx
>
> 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.
Why? Aren't you overly pessimistic here, possibly in favor of alien
handlers? (see some more reasoning further down)
> Or do you see that overlay listed in the registry?
>
>
>>>> (1) The ordering of the entries in
>>>> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers
>>>> 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
> want.
> 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?
Yes. But I really fail to see in what ways that should matter here. I
can test a German version from our CodePlex sponsored MSDN Premium
subscription assigned to me, if that's needed (I'm very grateful for
that resource. It's really nice to have that many different Windows
installs in VM's at your fingertips and being able to snapshot them).
(BTW, just a personal note: I just noticed the we are both living in
Switzerland - I'm in Aarau - and we both have a "Dipl. El.-Ing. ETH"
degree from ETH Zurich. I got mine in 1991. Small world :-)
> I'd say it is pure luck.
At least the observed behavior for a specific install is stable, i.e.
the registry keys are enumerated in the same order on every run.
It is unlikely to assume that this would change from one run to the
next. Even though Microsoft doesn't guarantee that as an API contract.
And sure the oreder might change again as soon as the user installs or
uninstalls anything else on his system, including but not limited to
service packs and of course other shell extensions.
I fail to see why you want to be so overly pessimistic here and even in
favor of alien handlers.
Sure, there is no guarantee that the handlers will be initialized in
*any* order.
But why should we cripple ourselves here? If the OS initializes a
handler, can't we just use it? Why throw the GetOverlayInfo call away be
deliberately returning S_FALSE and give up, possibly in favor of some
other alien handler?
I don't get it.
>>>> (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
>>>> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers
>>>> using the following
>>>> names (complete listing of the entries found below that registry key):
>>>>
>>>> 1TortoiseNormal
>>>> 2TortoiseModified
>>>> 3TortoiseConflict
>>>> 4TortoiseLocked
>>>> 5TortoiseReadOnly
>>>> 6TortoiseDeleted
>>>> 7TortoiseAdded
>>>> 8TortoiseIgnored
>>>> 9TortoiseUnversioned
>>>> EnhancedStorageShell
>>>> Offline Files
>>>> SharingPrivate
>>>>
>>>> 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.
That's favorable.
This will have the (admittedly undocumented and not promised) effect
that our TortoiseHandlers are initialized before the MS preinstalled
handlers.
So, if the OS ignores handlers, it will happen to ignore some of the MS
ones (surely there is no guarantee for this in any document by MS).
It would be nice if I could convince you to *not* throw away the
GetOverlayInfo call we get from the OS for the unversioned handler in
this case.
Or can you explain to me why we must throw away the GetOverlayInfo call
for the unversioned handler in that case (by returning S_FALSE)?
If there are too many handlers registered, it is at the OS' discretion
to ignore whatever handler it likes. But if we give up GetOverlayInfo
calls because we think there are too many handlers installed, what
guarantee do we have that the given up GetOverlayInfo call is coming
back to one of our other handlers? We might as well just take what we
get and use it. Aren't we trying to be too clever here with that
algorithm in GetOverlayInfo, needlessly shooting in our own foot in the
"too many handlers registered" case?
Think of the following hypothetical game: assume there are 5 kids but
only 3 pieces of cake. Two of the kids are brothers and brother A
happens to get a piece, due to a unknown process that enumerates the
kids in random order. Now A decides to give up his piece of cake in
favor of his brother B, which didn't get a piece yet. But A is not
allowed to give his piece to B directly. All he can do is accept the
piece or give it back, so it will be reassigned to some other (unknown
which exactly!) kid in the next enumeration step. Isn't A's decision a
bit stupid? There is no guarantee that B will get any cake at all.
But here, it is even worse: the unversioned handler is the last brother
of our family getting a piece of cake! All other brothers already got
their piece of cake! Why should that unversioned handler brother give
away his cake, in favor of another kid from another family?
Where is the bug in my thinking?
Sorry for the long post and for possibly repeating myself a couple of times.
And thanks a lot for your help, Stefan.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2459154
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-13 14:35:30 CET