registryapi plugin

[GoogleCodeExporter]

I'd like to include the registyapi "plugin" in the next release if possible.  
It provides a wrapper around various registry functions to make it easier to 
process several different keys across hives.  I'm sure there will be several 
changes that will need to take place, but I'm including the first round here.

Original issue reported on code.google.com by jamie.l...@gmail.com on 4 Apr 2012 at 4:37

• Blocking: #241, #250, #241

Attachments:

• registryapi.py

[GoogleCodeExporter]

Oops, forgot to populate the offsets during initialization.  

Original comment by jamie.l...@gmail.com on 4 Apr 2012 at 4:41

Attachments:

• registryapi.py

[GoogleCodeExporter]

Hmmm, that'll probably show up as a RegistryApi plugin.  If you're just making 
use of the hivescanner, you might want to instantiate it internally and then 
just hang onto that, rather than becoming a subclass of it?  If you are going 
to inherit it then there's a few hl.HiveScan calls that should be changed to 
self...

Original comment by mike.auty@gmail.com on 6 Apr 2012 at 8:34

[GoogleCodeExporter]

Good point, ikelos!  I'll fix it up and repost it a bit later :-)

Original comment by jamie.l...@gmail.com on 7 Apr 2012 at 11:52

[GoogleCodeExporter]

updated plugin

Original comment by jamie.l...@gmail.com on 22 Apr 2012 at 10:38

Attachments:

• registryapi.py

[GoogleCodeExporter]

Looking good.  I'm still debating whether multiple inheritance would be better 
than defining it as a plugin or not?  You might want to have:

class RegistryAPI(object):

and then for the plugins that need it:

class SomeRegPlugin(commands.Command, RegistryAPI):
  def __init__(self, *args, **kwargs):
    RegistryAPI.__init__(self)
    commands.Command(self, *args, **kwargs)

You should still be able to call self.reg_get_currentcontrolset() for instance, 
but it'll avoid having the registryapi object show up as a plugin in the plugin 
list...

Original comment by mike.auty@gmail.com on 22 Apr 2012 at 10:55

[GoogleCodeExporter]

Cool, I can dig it.  Actually, I agree that this is a better way to do it :-)  
I've attached a new copy 

Original comment by jamie.l...@gmail.com on 22 Apr 2012 at 11:36

Attachments:

• registryapi.py

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 6 May 2012 at 1:04

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 6 May 2012 at 1:06

[GoogleCodeExporter]

Looks good, let's get this in the tree...  5;)

Original comment by mike.auty@gmail.com on 6 May 2012 at 1:14

[GoogleCodeExporter]

Awesome!  Let me know if you want to commit it or if I should :-)  Thanks for 
giving it a look, Mike!

Original comment by jamie.l...@gmail.com on 6 May 2012 at 6:44

[GoogleCodeExporter]

Ok, this has been committed, but with a few changes:

* The constructor requires a config object (because we were relying on 
self._config before, but we want to use this as an object, not a required 
inheritance).

* We keep a local addr_space, rather than repeatedly determining a new one for 
each of the different function calls.  Since the config won't change, the 
address space won't need to either.  This could save us several dtb searches 
depending on how much the functions are called, so seems worthwhile.

Hope that's all ok?  Do gimme a shout if there's anything you'd prefer another 
way...  5:)

Original comment by mike.auty@gmail.com on 6 May 2012 at 11:26

• Changed state: Fixed

[GoogleCodeExporter]

Sounds good to me!  Thanks again, Mike! :-)

Original comment by jamie.l...@gmail.com on 7 May 2012 at 12:31

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 28 Jun 2012 at 7:04

• Now blocking: #241, #250, #241