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@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@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.
-----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
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
-
Alexandre Julliard -
Andriy Palamarchuk -
Eric Pouech -
Paul Millar -
Tels