www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - registry key rename?

reply "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
It would be nice to have function registry::rename_key().

No library I looked so far provides it (there's no native API
for it, it must be done via copying every item).

/Pavel
Jul 03 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Sounds like a mighty potent weapon. ;)

I see two approaches.

First, we could uncover the mechanism by which regedit *really* does this task.
That'd be the better way, but I've never found it.

Second, I could provide rename functionality in the form of key_copy and
key_delete(bRecursive), themselves built up of other. I've got most of this
implementation in other code, so I can cobble this together for 1.8, which I
want
to do in the next couple of months.

I don't think I'd want to actually provide a function rename_key(), since that
would then imply that some kind of transaction handling (i.e. deletion of the
new
key if the old cannot be deleted) which would be best left to the client code,
IMO.

Feel free to remind me in 4-5 weeks if I've not released a patch here containing
an implementation. :-)

Cheers


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

-----------------------------------------------------



"Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> wrote in message
news:cc6sqm$14pv$1 digitaldaemon.com...
 It would be nice to have function registry::rename_key().

 No library I looked so far provides it (there's no native API
 for it, it must be done via copying every item).

 /Pavel
Jul 03 2004
parent reply "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
"Matthew" wrote:

 First, we could uncover the mechanism by which regedit *really* does this
task.
 That'd be the better way, but I've never found it.
Copying old tree, item by item, recursively to new location, deleting old one afterwards It can be verified by Regmon tool. Some simple code snippets can be found on news-groups (usually written in VB). One may also fiddle with privileges, deal with remote registry, registry data timestamps, automatic mapping between hives, etc. /Pavel
Jul 04 2004
parent reply John Lyon-Smith <John_member pathlink.com> writes:
In article <cc8gki$bg2$1 digitaldaemon.com>, Pavel Vozenilek says...
"Matthew" wrote:

 First, we could uncover the mechanism by which regedit *really* does this
task.
 That'd be the better way, but I've never found it.
Copying old tree, item by item, recursively to new location, deleting old one afterwards It can be verified by Regmon tool. Some simple code snippets can be found on news-groups (usually written in VB). One may also fiddle with privileges, deal with remote registry, registry data timestamps, automatic mapping between hives, etc. /Pavel
As amazing as it sounds, Pavel is correct. That is how RegEdit/RegEdt32 effectively do a rename of a registry key. You'd think it would be a slow operation, but it surprisingly fast. Quite a credit to the Windows O/S file caching mechanism. Ha ha. John Lyon-Smith
Aug 20 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"John Lyon-Smith" <John_member pathlink.com> wrote in message
news:cg5g26$jnh$1 digitaldaemon.com...
 In article <cc8gki$bg2$1 digitaldaemon.com>, Pavel Vozenilek says...
"Matthew" wrote:

 First, we could uncover the mechanism by which regedit *really* does this
task.
 That'd be the better way, but I've never found it.
Copying old tree, item by item, recursively to new location, deleting old one afterwards It can be verified by Regmon tool. Some simple code snippets can be found on news-groups (usually written in VB). One may also fiddle with privileges, deal with remote registry, registry data timestamps, automatic mapping between hives, etc. /Pavel
As amazing as it sounds, Pavel is correct. That is how RegEdit/RegEdt32 effectively do a rename of a registry key. You'd think it would be a slow operation, but it surprisingly fast. Quite a credit to the Windows O/S file caching mechanism. Ha ha.
I was inclined to decry this as not being possibly true, but thought I'd test it out before putting my big foot in my mouth. I saved the contents of HKEY_CLASSES_ROOT to text file, changed the prefix to an unimportant key under HKEY_CURRENT_USER, and loaded it. Both save and load took 14 seconds. Then I renamed the name of the new key (under HKCU), and timed it. That was 10 minutes ago. It's still going. Windows truly does suck. WinSTL will be emulating this sucky facility sometime soon. Sigh ... Matthew
Aug 21 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg6vnn$1hk9$1 digitaldaemon.com...
 "John Lyon-Smith" <John_member pathlink.com> wrote in message
news:cg5g26$jnh$1 digitaldaemon.com...
 In article <cc8gki$bg2$1 digitaldaemon.com>, Pavel Vozenilek says...
"Matthew" wrote:

 First, we could uncover the mechanism by which regedit *really* does this
task.
 That'd be the better way, but I've never found it.
Copying old tree, item by item, recursively to new location, deleting old one afterwards It can be verified by Regmon tool. Some simple code snippets can be found on news-groups (usually written in VB). One may also fiddle with privileges, deal with remote registry, registry data timestamps, automatic mapping between hives, etc. /Pavel
As amazing as it sounds, Pavel is correct. That is how RegEdit/RegEdt32 effectively do a rename of a registry key. You'd think it would be a slow operation, but it surprisingly fast. Quite a credit to the Windows O/S file caching mechanism. Ha ha.
I was inclined to decry this as not being possibly true, but thought I'd test it out before putting my big foot in my mouth. I saved the contents of HKEY_CLASSES_ROOT to text file, changed the prefix to an unimportant key under HKEY_CURRENT_USER, and loaded it. Both save and load took 14 seconds. Then I renamed the name of the new key (under HKCU), and timed it. That was 10 minutes ago. It's still going. Windows truly does suck. WinSTL will be emulating this sucky facility sometime soon. Sigh ... Matthew
Just finished: 16 minutes!
Aug 21 2004
prev sibling parent reply Jan Knepper <jan smartsoft.us> writes:
 You'd think it would be a slow
 operation, but it surprisingly fast.   Quite a credit to the Windows O/S file
 caching mechanism.   Ha ha.
Windows caching mechanism is slow and inadequate... Registry is relatively little data and since the Registry is probably partially loaded (cached) in memory it might look fast... Try to load a 1E6+ record database on Windows with 10+ indexes and you will change your thoughts about the windows caching mechanism. Try to deal with 25,000 events / second that have to be written to disk and have to be able to be looked-up and reviewed at several indexes... You'll soon learn what Windows is really about... -- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org
Aug 21 2004
parent reply John Lyon-Smith <John_member pathlink.com> writes:
In article <cg82ko$282h$1 digitaldaemon.com>, Jan Knepper says...
 You'd think it would be a slow
 operation, but it surprisingly fast.   Quite a credit to the Windows O/S file
 caching mechanism.   Ha ha.
Windows caching mechanism is slow and inadequate... Registry is relatively little data and since the Registry is probably partially loaded (cached) in memory it might look fast... Try to load a 1E6+ record database on Windows with 10+ indexes and you will change your thoughts about the windows caching mechanism. Try to deal with 25,000 events / second that have to be written to disk and have to be able to be looked-up and reviewed at several indexes... You'll soon learn what Windows is really about... -- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org
Ah well, suck it may, but we all use it non-the-less. I was kidding about the file caching being great. But it sounds like what you need to solve your problem is large amounts of RAM and some RAID 0 10,000 RPM disk drives! Anyway, on the subject of the registry key rename, and Matthews 16 minute test. I get about half that on my machine, but still pretty lousy. Good job I don't spend a lot of time renaming registry keys! I'm trying to think of a reason why the registry designers did this. The best that I an come up with is that the internal storage of the registry is not actually hierachical! Using some kind of a hashing mechanism might make for fast registry key look-ups, at the expense of add/rename/delete operations. John Lyon-Smith
Aug 30 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"John Lyon-Smith" <John_member pathlink.com> wrote in message
news:cgvs1g$2pq0$1 digitaldaemon.com...
 In article <cg82ko$282h$1 digitaldaemon.com>, Jan Knepper says...
 You'd think it would be a slow
 operation, but it surprisingly fast.   Quite a credit to the Windows O/S file
 caching mechanism.   Ha ha.
Windows caching mechanism is slow and inadequate... Registry is relatively little data and since the Registry is probably partially loaded (cached) in memory it might look fast... Try to load a 1E6+ record database on Windows with 10+ indexes and you will change your thoughts about the windows caching mechanism. Try to deal with 25,000 events / second that have to be written to disk and have to be able to be looked-up and reviewed at several indexes... You'll soon learn what Windows is really about... -- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org
Ah well, suck it may, but we all use it non-the-less. I was kidding about the file caching being great. But it sounds like what you need to solve your problem is large amounts of RAM and some RAID 0 10,000 RPM disk drives! Anyway, on the subject of the registry key rename, and Matthews 16 minute test. I get about half that on my machine, but still pretty lousy. Good job I don't spend a lot of time renaming registry keys! I'm trying to think of a reason why the registry designers did this. The best that I an come up with is that the internal storage of the registry is not actually hierachical! Using some kind of a hashing mechanism might make for fast registry key look-ups, at the expense of add/rename/delete operations. John Lyon-Smith
I suspect you're right. In terms of a reg_rename() function in STLSoft, I think I'm inclining against it. I think a copy function would be ok, and also a separate recursive delete, but I don't want to put them together in a single function that I provide, precisely because of its performance and security ramifications.
Aug 30 2004
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I'm now thinking that this'll be provided by an extension library built on top
of a version of recls that enumerates the
registry. I can't say that will be the next version of the library, but it is
getting more imminent. The dependencies
would look like:

- a custom, free, library, built on top of recls/Registry, providing the
copying and deletion
    - recls Registry API, providing the recursive enumeration
        - WinSTL components for enumerating a single reg-key
    - possibly some WinSTL components that do the (non-recursive) copying

It's not a trivial task, but not an especially complex one. I expect I'll do
this sometime in the next couple of months,
and it'd be available before it was documented in the CUJ column.

Cheers

Matthew


"Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> wrote in message
news:cc6sqm$14pv$1 digitaldaemon.com...
 It would be nice to have function registry::rename_key().

 No library I looked so far provides it (there's no native API
 for it, it must be done via copying every item).

 /Pavel
Sep 11 2004