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

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
>
>

"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

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

"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

"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!

> 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

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

"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.

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
>
>