Re: DEP and /NXCOMPAT troubles...

Ira Baxter wrote:
[snip]
Right. So the problem is granularity. There are times when I need
a few hundred bytes, dynamically allocated, to hold generated code.
Setting aside full pages is a complete waste of space.

If you find yourself generating "a few hundred bytes" often without an opportunity to reuse memory, write your own allocator that takes memory from an executable page heap. Or else trust your application completely and mark every range your regular allocators return as executable when you intend to use it for code, but since this will leave executable pages all over the place, it's hardly an elegant solution (and a security risk).

--
J.
.

Relevant Pages

  • Re: Speed quirk: redundant line gives six-fold speedup
    ... >> and comparison of objects depends on the state of the memory ... >> allocator. ... I'm also pretty sure I've caught a bug in his code, ... <snip more 4s from the same object> ...
    (comp.lang.python)
  • Re: Custom allocator sample code for vector
    ... >> in a container, ... >> decorating the standard allocator functions construct() and destroy. ...
    (comp.lang.cpp)
  • Re: void pointers
    ... Ben Bacarisse wrote: ... snip ... ... allocator here and I doubt that is programmable in standard C. ...
    (comp.lang.c)
  • Re: void pointers
    ... CBFalconer wrote: ... snip ... ... allocator here and I doubt that is programmable in standard C. ...
    (comp.lang.c)