Memory objects & GlobalLock/Unlock

[Semen Matusovski]

Looking some code on codeguru.com, I encounted following interesting comment "Use GlobalLock and GlobalUnlock instead of simply assuming the memory handle to be a pointer".
As I understand, it's about hBmp.
In another place, I saw GlobalLock for the handle of a clipboard object.
I'm confused a little, first of all, because all operations are executing inside processing single message and can't imagine, why memory could be moved or discarded.

Is it really necessary to execute GlobalLock/Unlock in such situations ?

[Florent Heyworth]

Hi Semen

calling GlobalLock has the same effect as calling GlobalAlloc(%GMEM_FIXED, lSize ) - a pointer to memory is returned instead of a handle to a pointer and the memory is flagged as non-discardable and non-moveable - you might use it for a clipboard object is you were allocating memory for structures on the fly and wanted to guarantee the mem could not be relocated by OS.

I usually never use GlobalAlloc, GlobalLock to allocate dynamic memory, they are really Win16 calls that are mapped to native Win32 calls like HeapXXX functions. I use the Heap functions for smaller blocks and the Virtual Memory calls for larger blocks.

I'm not sure I understood your question properly - is that what you were asking?

Cheers

Florent

------------------

[Semen Matusovski]

Florent --
I understand situations, when I allocate memory by myself, using GlobalAlloc.
I am interesting about handles, returned by functions similar CreateDIBBitmap or GetClipboardData.

From Win32.Hlp:
The GlobalLock function locks a global memory object and returns a pointer to the first byte of the object’s memory block. The memory block associated with a locked memory object cannot be moved or discarded.

I can't understand comment on www.codeguru.com, because I hope, that OS allocates memory for hBmp, hIcon and so on with a flag GMEM_FIXED.
From another side, mentioned comment belongs to a forum leader, codeguru is enough serious site and simply to ignore such warning looks incorrect.

[This message has been edited by Semen Matusovski (edited May 26, 2000).]

[Florent Heyworth]

Hi Semen

I think I understand now - I guess the article you read recommended using GlobalLock on bitmap handles and such to get a direct pointer instead of using the handle along.

I can't imagine that would be of much use unless you wanted to specifically alter/read the object you received a handle to - but for that you'd need inside knowledge on the structure of the object actally pointed to.

[ADDED]
The reason you receive handles from different functions instead of pointers is so that the OS can move the mem around if necessary and the handle to the pointer remains valid no matter what. It also has the added advantange that the caller can ignore the underlying structure.

------------------


[This message has been edited by Florent Heyworth (edited May 26, 2000).]

[Semen Matusovski]

Florent --
It seems to me that I began to understand something ...
For example, in posted programs there are approx. following

      hTmpBmp = CreateDIBSection(hTmp1DC, bmi, %DIB_RGB_COLORS, 0, 0, 0)
      SelectObject hTmp1DC, hTmpBmp
      GetObject hTmpBmp, SizeOf(bm), bm
      BitBlt hTmp1DC, 0, 0, pWidth, pHeight, hTmp2DC, 0, 0, %SRCCOPY

Then is used a field bm.bmBits for direct access to bitmap bits.

Codeguru' comment means that to avoid troubles with possible moving memory is necessary to GlobalLock hTmpBmp ?

------------------

[Florent Heyworth]

Hi Semen

in the case of GetObject to get the BITMAP info I'd think that getting the pointer would be useless since GetObject expects a handle to a pointer instead (like most accessor functions).

I think the Codeguru warning applies to C (and other) programmers who might try to attempt typecasting (type coercion) on a handle like hBmHeader = (PBITMAPV4HEADER)hBmp instead of using the GetDIBits() accessor function.

This would only be necessary IMO if you are typecasting instead of using accessor functions. In the case of typecasting then it would make sense to call GlobalLock since this increases the lock count for an object declared with the GMEM_MOVEABLE flag, ensuring that the pointer would remain valid until explicitly discarded.

Cheers

Florent


------------------

[Semen Matusovski]

Florent --
it was general comment about group of programs, but technique of direct access is enough similar.
If to look closely, in such fragment is assumed that bm.bmBits, which was valid after CreateDIBSection remains after following three operations. It's question, if internals of DIBSection were allocated without a flag GMEM_FIXED (Microsoft only knows is it true or not).
So, what do you think - there are reasons to GlobalLock hTmpBmp ?




------------------

[Florent Heyworth]

Yes and no

if you are accessing your structures via the API accessor functions then I'd say using GlobalLock is useless.

If however you are using typecasting to coerce and then directly refer to an API allocated structure then using GlobalLock() is necessary.



------------------

[Semen Matusovski]

Florent --
Thanks. This trick is used to avoid GetDIBits.
So - unless I didn't saw troubles -- I will lock.


------------------