Re: Removed sorting of registry key values
Andriy Palamarchuk a écrit :
Working on regedit replacement I noticed that Windows regedit does not sort registry key values, while Wine does. I tested this on NT 4.0, SP2. You can check this by importing a registry file with not alphabetic values order and exporting it again.
I fail to see the benefits of the patch: - key are sorted to allow O(log(n)) searching (registry is loaded only once, and then searched lots of time) so using enhanced searching techniques (<< O(n)) is really needed - saying that NT doesn't export the keys in an alphabetical order doesn't mean the keys are not sorted. So far, you can only tell that they are not sorted, in the export mechanism, by an alphabetical order. They could be sorted, for example, by a hash code value (look at misc/registry.c for some more details on registry internals) A+
--- Eric Pouech <eric.pouech(a)wanadoo.fr> wrote:
I fail to see the benefits of the patch: - key are sorted to allow O(log(n)) searching (registry is loaded only once, and then searched lots of time) so using enhanced searching techniques (<< O(n)) is really needed - saying that NT doesn't export the keys in an alphabetical order doesn't mean the keys are not sorted. So far, you can only tell that they are not sorted, in the export mechanism, by an alphabetical order. They could be sorted, for example, by a hash code value (look at misc/registry.c for some more details on registry internals)
The tests show that values are exported in the same order in which they are created. This means the values are stored not in any particular order. Sure, Windows internallty can use map of keys for faster search but I doubt it. A program can expect to retrieve values in the order they were created. In particular, the problem can be if the app creates names like Item1, ..., Item10. After sorting Item10 will be after Item1, not after Item9. I don't have any doubts that existing code is faster. The point of the patch is compatibility with Windows behaviour. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Andriy Palamarchuk <apa3a(a)yahoo.com> writes:
I don't have any doubts that existing code is faster. The point of the patch is compatibility with Windows behaviour.
Unless we find a real-life application that depends on that, there isn't much point in being compatible here. -- Alexandre Julliard julliard(a)winehq.com
-----BEGIN PGP SIGNED MESSAGE----- Moin, On 03-Apr-02 Andriy Palamarchuk carved into stone:
A program can expect to retrieve values in the order they were created. In particular, the problem can be if the app creates names like Item1, ..., Item10. After sorting Item10 will be after Item1, not after Item9.
But is this documented? Are there programs which will relly rely on this? And is this guarantied no to change, for instance in other windows versions? I would say: Don't fix things that are not broken.;) Cheers, Tels - -- "Why do you go so slowly? Do you think this is some kind of game?" PGP key available on http://bloodgate.com/tels.asc or via email. perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"' authoritatively disintermediate prospective materials -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPKtOtncLPEOTuEwVAQEfwAf+Nj8XZoVB84RoFcTbdvQ6qKBMh23cQ5EO d7c17jkVbGENWvEHR5NjToYDd3evEfM8emOe86ywxw6MrHdJZ+3RlSukcfprV33k EZoi2dgIzz7u+I3q//iaGkGrkGoW962XO2DiFXF3C33Es5DbORl8PMPq96+PJsz0 yCTgrzapD47+VvJLXBDgUHsPpyyFIjLP1+7/WhAB/qOEUae1a1lNSAAsbmY/zpT9 jL01/6bH28BDOGSmDI1j02hy8A9VZG/ErcLuhVOmBWEuYVq5+85t3PILCNJr5idP 597pu8baDfFYxjdaMO5E9zPiRib8jMGfWS+M5HRWSEiUEy66eEMKZQ== =ueqX -----END PGP SIGNATURE-----
On Wed, 3 Apr 2002, Andriy Palamarchuk wrote: [snip - Eric's info on why the registry has to be sorted]
The tests show that values are exported in the same order in which they are created. This means the values are stored not in any particular order.
That doesn't necessarily follow ... The export function(s) could map the sorted registry back into its original order. At the cost of sizeof( void *) bytes per registry entry (perhaps less, I haven't looked too closely at the registry code), you could have the registry keys sorted (for fast access) and export back into the original order in O(n) Is it worth the memory for that level of compatibility? ---- Paul Millar
Paul Millar wrote:
On Wed, 3 Apr 2002, Andriy Palamarchuk wrote:
The tests show that values are exported in the same order in which they are created. This means the values are stored not in any particular order.
That doesn't necessarily follow ...
The export function(s) could map the sorted registry back into its original order. At the cost of sizeof( void *) bytes per registry entry (perhaps less, I haven't looked too closely at the registry code), you could have the registry keys sorted (for fast access) and export back into the original order in O(n)
Is it worth the memory for that level of compatibility?
All of you guys, thank you for the feedback. I had a doubt before submitting the patch. Andriy Palamarchuk
participants (5)
-
Alexandre Julliard -
Andriy Palamarchuk -
Eric Pouech -
Paul Millar -
Tels