Overlay objects bleed across profiles

[GoogleCodeExporter]

So currently, defining an object class in one overlay module will allow it to 
be instantiated by any profile, so for example _EPROCESS can be defined in 
xpsp2, but all the methods will still be present in the EPROCESS object create 
for the Win7SP0x86 profile.

This raises problems if two different profiles need different methods on 
identically named objects.  For example, attempting to redefine _EPROCESS will 
result in an "Object _EPROCESS has already been defined <clas 'blah'>" error 
message.

Currently this isn't an issue, but it at least needs documenting.  If it does 
become an issue in the future it will possibly need refining so that objects 
are defined as part of an overlay, rather than simply as global objects.  This 
may well already be doable by pointing the overlay at a callable that spits out 
an object, but this will need some looking into and again documenting somewhere 
(possibly the wiki to begin with).

Ideally we want some form of inheritance (so that things that stay the same, 
don't need redefining) but also some form of override (so that things which 
need to change, can).  I think currently the important code resides in either 
obj.CType.__init__ or obj.Object(), but it's not clear if that needs changing, 
or we can simply use/abuse the overlay mechanism to define objects too (so 
Win7SP0x86_EPROCESS is defined, and then plastered on _EPROCESS in the 
overlay).  Any ideas/thoughts/comments?

Original issue reported on code.google.com by mike.auty@gmail.com on 16 Sep 2010 at 11:04

[GoogleCodeExporter]

This issue was closed by revision r436.

Original comment by mike.auty@gmail.com on 17 Sep 2010 at 12:29

• Changed state: Fixed

[GoogleCodeExporter]

Yep, so thanks to some quick thinking by scudette, there's now an 
object_classes dictionary that can be overridden when defining a profile class. 
 This will be checked first, before falling back to global object definitions, 
and finally just a normal CType if all else fails.

Original comment by mike.auty@gmail.com on 17 Sep 2010 at 12:34

[GoogleCodeExporter]

Sorry for the bugspam, but better to get this right now than later once it's 
more in use.

Original comment by mike.auty@gmail.com on 4 Feb 2011 at 9:34

• Added labels: Milestone-1.4.x
• Removed labels: Milestone-Release1.4