Question: HeapAlloc() and bitmaps??

[OceanJeff32]

Ok, when I allocate memory for a bitmap with HeapAlloc(), and then I copy the returned value, like this:

invoke HeapAlloc(), etc.
mov bitmap1, eax

, then later in code to manipulate the individual pixels, I load the bitmap1 pointer into an index register (or I am told I could use any register).

mov edi, bitmap1

Why does that work fine in later calls that I make to manipulate the bitmap pixels, but when I use this:

lea edi, bitmap1

the whole program crashes?

What is the difference?

I'm confused,

Jeff C
:U

[Tedd]

mov edi,bitmap1 means: "get the value stored in the variable named bitmap1 in edi"

lea edi,bitmap1 means: "get the address of bitmap1 in edi"
(essentially the same as "mov edi,OFFSET bitmap1" ....assuming bitmap1 is a global variable)


For local variables, using lea is better since they're usually referenced as "ebp+??" - so you use lea to get the direct address (in other words it calculates ebp+?? and puts the result in edi)
Using lea to get the address of globals is a bit pointless though :wink

[sluggy]

Why does that work fine in later calls that I make to manipulate the bitmap pixels, but when I use this:

lea edi, bitmap1

the whole program crashes?

The program won't crash then, it will crash when you try to actually use the value, because you have ended up with a pointer to a pointer (load the address of the variable that points to the buffer).

[OceanJeff32]

Ok, sorry, I just got it!

making this call to HeapAlloc() , and then

mov bitmap1, eax

store the ADDRESS OF or POINTER TO, in bitmap1, a common variable.

That's actually what i want later, so all i need to do is:

mov eax, bitmap1
or
mov edi, bitmap1

lea eax, bitmap1  (will put the ADDRESS OF bitmap1, which is just a variable, NOT the actual location in memory for the allocated bitmap)

<what's the expression for a light bulb just went on!>

that may be it...

later,

jeff c
::)

[AeroASM]

<what's the expression for a light bulb just went on!>

Ding!!  :U :bg

[gabor]

Hello!


Tedd, why is it pointless to use lea for global variables? You prefer mov reg,offset var instead?


I thougth Jeff won't mind if I'd post a question too about HeapAlloc and other memory allocation functions.

1. Am I right in this: GlobalAlloc and LocalAlloc are not really different in win32.
2. I was told better to use HeapAlloc. Is this right? If yes, why is it so?
3. When I use HeapAlloc, how can I get a memory handle? AFAIK HeapAlloc delivers always an address.

The 3rd question I bumped into when I wanted to assign my buffer to an EditControl item via the EM_SETHANDLE message. This, I could not get to work when I used a memory address got before by HeapAlloc. With LocalAlloc's return value (used GPTR parameter, that gives a handle) it worked well.
I am sure I messed up something... Does anyone have a working code for this? Of course I don't need source, just give me some hints!

Thanks!


Greets, Gábor

[hutch--]

gabor,

> 1. Am I right in this: GlobalAlloc and LocalAlloc are not really different in win32.

GlobalAlloc() is still viable in current 32 bit using the fixed memory flag. It also has a few specialised uses like DDE.

> 2. I was told better to use HeapAlloc. Is this right? If yes, why is it so?

HeapAlloc() is faster with a large count of small allocations.

> 3. When I use HeapAlloc, how can I get a memory handle? AFAIK HeapAlloc delivers always an address.

The address is effectively the memory handle in most instances. The address is what you have to deallocate when you are finished so it tends to work that way.

[Tedd]

Tedd, why is it pointless to use lea for global variables? You prefer mov reg,offset var instead?

lea is a 'complex' instruction (it does more than one thing) so it can be slow (it causes latencies for other instructions.)
Unless you need it specifically, I would use "mov reg,offset" instead - just because the instruction is 'simpler'



I don't know how the edit control will treat the memory 'handle' if you give a pointer. I assume it would try to lock it and use the returned address as its pointer. Whether or not this will fail is down to how global/locallock treat it - the system should be able to distinguish handles and pointers, so it may work (if you're lucky.)

[gabor]

Hutch, Ted!

Thanks for the quick answers. I'll be sure to remember this infos...