Re: Using other heaps for memory...if I run out?

userforgroups@xxxxxxxxxxx wrote: 
Thanks for the info Logan.  Here's basically my problem.  My dynamic
heap usage is fairly small, somewhere around 50k or so.  The real issue
is the creation of my two window buffers.  Of course on a hi-res device
(320x320) each is 204k, so there goes a huge heap of heap :)

The reason I do this, is that there is a complex background that I like
to keep in a "clean" state at all times, thus one of the buffers.  Then
I draw what I need when I need it to the second buffer.  When something
drastic changes and I need to redraw the whole thing, I just transfer
the buffer from the first "clean" image to the other buffer, then add
my other "dynamic" elements.  Now I could just keep the other as a
bitmap resource and do a regular windrawbitmap to the one buffer, but I
have a second requirement.

I might only be updating or clearing a small area at a time during
normal operation. Small areas, maybe 20x20 pixels, and in order to
clear them I basically do a wincopyrectangle from the orginal "clean"
image, to the area I need to clear.  So this is why I needed the second
buffer.


It seems like you could solve this problem without having a background
buffer.

You should be able to take a bitmap that is in a resource, lock the
resource, and use WinCreateBitmapWindow() to make a window wrapper
around it.  Then you should be able to use WinCopyRectangle() to copy
parts of it to your buffer that you use to update all or part of the
screen.

There are probably some gotchas with this approach.  One is that you
don't want to make the bitmap resource compressed, because that will
slow down copying.  Another is that resources cannot be bigger than
64K, so you will have to break the original into tiles (or bands),
which makes copying it to your screen update buffer more complicated.
The last is that you really want your bitmap to have the same depth
as the screen, so that could be a little tricky.  But, it should be
possible, with care, to overcome all these problems.

A different approach is to just allocate some memory in the storage
heap.  This memory can't be written to in the normal manner, and
you must use DmWrite() to write to it, but you can read from it just
like any other memory (it is addressable).  So, you could do some
sequence like this:

(1)  Start your app.
(2)  Allocate one big buffer in dynamic heap.
(3)  Build your background in that buffer.
(4)  Allocate memory from the storage heap using a feature pointer
     (FtrPtrNew()).
(5)  Copy the background into the feature memory with DmWrite().
(6)  Re-purpose your big buffer (in dynamic heap) as a display-update
     buffer.

Just how much memory is available in the storage heap depends on
what the user has installed (since PRCs and PDBs go there), but
on a blank device, there is always more space in the storage heap
than the dynamic heap.

And, by the way, I agree that these limitations are kinda crazy.  But,
considering that the original device had only 128K, they're not that
surprising...

  - Logan
.

Relevant Pages

  • RE: Defeating Microsoft Windows XP SP2 Heap protection
    ... Fact is XP SP2 is still far less likely to be vulnerable to buffer overflow ... > than the memory buffer allocated to hold it. ... > the operating system is now more careful to reduce both stack and heap ... > Execution Protection ...
    (microsoft.public.windowsxp.general)
  • [EXPL] Smail preparse_address_1() Heap Overflow
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... There is a heap buffer overflow, ... ssize_t Send(int s, const void *buf, size_t len, int flags) ...
    (Securiteam)
  • malloc realloc and pointers
    ... When we perform malloc(), the memory allocated dynamically comes from ... the heap area of the process in concern. ... perticular position in a buffer then on performing a ...
    (comp.lang.c)
  • smail remote and local root holes
    ... I've been trying to send an email to greg woods, the maintainer of smail, to 3 ... There is a heap buffer overflow, and a signal handling related vulnerability. ...
    (Bugtraq)
  • Re: Using other heaps for memory...if I run out?
    ... Thanks for the info Logan. ... heap usage is fairly small, ... I draw what I need when I need it to the second buffer. ... >> few of my memptrnew's were returning Null, so of course no more memory. ...
    (codewarrior.palm)