You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
Original issue reported on code.google.com by
mike.auty@gmail.com
on 16 Sep 2010 at 11:04The text was updated successfully, but these errors were encountered: