c++.stlsoft - registry key rename?
- Pavel Vozenilek (4/4) Jul 03 2004 It would be nice to have function registry::rename_key().
- Matthew (28/32) Jul 03 2004 Sounds like a mighty potent weapon. ;)
- Pavel Vozenilek (9/11) Jul 04 2004 Copying old tree, item by item, recursively to new location,
- John Lyon-Smith (6/18) Aug 20 2004 As amazing as it sounds, Pavel is correct. That is how RegEdit/RegEdt32
- Matthew (12/37) Aug 21 2004 I was inclined to decry this as not being possibly true, but thought I'd...
- Matthew (2/40) Aug 21 2004 Just finished: 16 minutes!
- Jan Knepper (13/16) Aug 21 2004 Windows caching mechanism is slow and inadequate...
- John Lyon-Smith (12/28) Aug 30 2004 Ah well, suck it may, but we all use it non-the-less. I was kidding abo...
- Matthew (5/41) Aug 30 2004 I suspect you're right.
- Matthew (12/16) Sep 11 2004 I'm now thinking that this'll be provided by an extension library built ...
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
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
"Matthew" wrote:First, we could uncover the mechanism by which regedit *really* does thistask.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
In article <cc8gki$bg2$1 digitaldaemon.com>, Pavel Vozenilek says..."Matthew" wrote: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-SmithFirst, we could uncover the mechanism by which regedit *really* does thistask.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
Aug 20 2004
"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...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" wrote: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.First, we could uncover the mechanism by which regedit *really* does thistask.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
Aug 21 2004
"Matthew" <admin.hat stlsoft.dot.org> "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...Just finished: 16 minutes!In article <cc8gki$bg2$1 digitaldaemon.com>, Pavel Vozenilek says...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" wrote: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.First, we could uncover the mechanism by which regedit *really* does thistask.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
Aug 21 2004
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
In article <cg82ko$282h$1 digitaldaemon.com>, Jan Knepper says...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-SmithYou'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 30 2004
"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...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.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-SmithYou'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 30 2004
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