On 13.03.2010 14:22, Adrian Buehlmann wrote:
>> 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)
I'd rather be pessimistic here than to have problems like e.g., the
'normal' overlay not showing up:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2417776
>> 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).
I also have the English version of Win7 x64 installed. But I also have
the German version installed on another computer.
> (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 got mine in 1997 :)
>> 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.
Yes, the order doesn't change. But I made a lot of tests with XP, and
there (German version) the load order has nothing to do with the
registry key names but the order in which they were created.
The only way to change that order was to remove other handlers, then
create them again. That way, they were loaded *after* the TSVN handlers
because they were created later.
> 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.
We have to make sure that our 'important' handlers are loaded.
Lets assume that the handlers are loaded in a random order.
Lets also assume that there is one handler more registered than 15.
Now, if TSVN lets load all its handlers without blocking the
'unimportant' ones from getting initialized, it could very well be that
Windows first loads all handlers but the 'normal' or 'modified' handler
last. But since all slots are already filled, that handler (normal or
modified) won't get loaded anymore.
Now, if however windows loads the handlers in alphabetical order, then
of course we could just not play nice and try to have Windows load all
of our handlers. But: we can't guarantee the load order, and from my
testing it definitely isn't guaranteed to be alphabetically.
>> 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?
you forgot to take into account that 'baby brother' *must* have his cake
or he will refuse to go to sleep.
Now if none of the bothers know which one will get a cake, some of them
have to decline their cake to make sure that 'baby brother' will get one.
Or do you really want to risk that the 'modified' overlay won't get
shown? I'd rather have the 'unversioned' overlay not showing up.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2459301
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-13 23:30:38 CET