News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

GetSystemTime \ HeapRealloc \ Bitmap size

Started by TNick, November 10, 2006, 06:00:45 PM

Previous topic - Next topic

TNick

Hi all!

I would like to know if there is a way of getting the BIOS time in Windows, because GetSystemTime and GetLocalTime return the time selected by user in <Date and Time Properties>. I need this to track some events.

Second, just want to be shure that, if a call to HeapRealloc fail, the pointer passed to it is still valid. Do you know something about this?

And, finally: if I select a bitmap in a memory DC, can I resize it, or I must select another bitmap, resize my bitmap and reselect it in DC?

Thanks for help in advance!
Nick

Manos

About HeapRealloc,I think that in WinXP it fails some times,
mainly if you call this repeatedly.
I don't know why,but I have bad experience using this.

About bitmap,you must select another bitmap in the DC.

Manos.

TNick

No, on my system works ok. Just want to know if that pointer that I get using a HeapAlloc is still valid

Manos


TNick

Oh,I understand now. Not very good behavior. So, if it fails, you can't free that block of memory.
Thanks for your answer!

Nick

Relvinian

TNick,

This is from the SDK for HeapReAlloc:

If HeapReAlloc succeeds, it allocates at least the amount of memory requested. To determine the actual size of the reallocated block, use the HeapSize function.

If HeapReAlloc fails, the original memory is not freed, and the original handle and pointer are still valid.

Relvinian

Manos


TNick

Manos,

I see this is a real problem. Anyway, even if I'm not shure, I don't think the way proposed in that topic is a safe one. You can't be shure that the new allocated portion will be right there. I guess that I'll have to change all my HeapRealloc to HeapAlloc - copy - HeapFree.

Thanks for bitmap related info.

What about time. Is there a way to find the BIOS time?

Regards,
Nick

ToutEnMasm


I use heapalloc and then Heaprealloc in an intensive maner,in XP and have never seen one problem.
     ToutEnMasm

Manos

Quote from: TNick on November 11, 2006, 04:10:39 PM
I guess that I'll have to change all my HeapRealloc to HeapAlloc - copy - HeapFree.

Yes.
The same I have done in my projects.You can implement your own HeapReAlloc.
Inside your HeapReAlloc,you can check the returned pointer from the new HeapAlloc
and if this is 0,you can preserve the old pointer.

Manos.


TNick

Hello, ToutEnMasm!

I used HeapRealloc a lot, too, and had no problems! This question had pop up when thinking about where to test a failure of HeapRealloc:

INVOKE  HeapRealloc,hHeap,0,pMem,NewSize
or eax, eax
jz ErrorLabel
mov  pMem, eax


or

mov  pMem, eax
or eax, eax
jz ErrorLabel


Anyway, reading that topic that Manos said, seem like some people had serious problems with it. I will look at that code a little more, but if I can't find another cause, I would say that safest thing to do is <HeapAlloc - copy - HeapFree.>. Even if there can be a speed decrease...

Regards,
Nick




TNick

Ok, reading is done. In that post, if I understand correctly, they said that, eventually, HeapRealloc will fail. This is OK. I just want to know if the pointer used in this function will still be valid, and my bytes intact. There is no reference about this in that post.
Let's think it over.

IF requested size aviable in place
        just increase the allowed size
        mov  eax, OldPointer
ELSE
        find a place with enough space
        IF There_is_a_place
            xor ecx, ecx
            .WHILE ecx<oldsize
               .
               .    ;copy old content
               .
            .ENDW
            mov  eax, NewPointer
        ELSE
          xor eax, eax
        .ENDIF
.ENDIF

Well, if this is correct, there is no place where our pointer or content may be affected....

Am I missing something here?

Manos, a snippet, maybe?


Nick

Manos


Tedd

testing seems to show that the old pointer is valid if re-alloc fails..
(though obviously this only calls once -- calling repeatedly could - but shouldn't! - have other side effects.)


.586
.model flat, stdcall
option casemap:none
include windows.inc
include kernel32.inc
includelib kernel32.lib
include user32.inc
includelib user32.lib

.data
before      db "before",0
succs       db "succeeded",0
failed      db "failed",0
strung      db "this is a debugging string",0
sizer       db "%lu bytes",0

.data?
hHeap       HANDLE  ?
numbuff     db 128 dup (?)

.code
start:
    push esi
    invoke GetProcessHeap
    mov hHeap,eax

    invoke HeapAlloc, hHeap,NULL,64     ;allocate a small block - 64 bytes
    mov esi,eax
    invoke lstrcpy, esi,ADDR strung     ;store some data into it
    invoke MessageBox, NULL,esi,ADDR before,MB_OK   ;show the data is there

    invoke HeapReAlloc, hHeap,NULL,esi,07fffffffh    ;request a huge chunk - it should fail ;)
    .IF (eax)
        ;***succeeded -- we get a new pointer to the new memory
        mov esi,eax
        invoke HeapSize, hHeap,NULL,esi
        invoke wsprintf, ADDR numbuff,ADDR sizer,eax
        invoke MessageBox, NULL,esi,ADDR numbuff,MB_OK
    .ELSE
        ;***failed -- the 'old' pointer is still valid
        invoke HeapSize, hHeap,NULL,esi
        invoke wsprintf, ADDR numbuff,ADDR sizer,eax
        invoke MessageBox, NULL,esi,ADDR numbuff,MB_OK
    .ENDIF
    invoke HeapFree, hHeap,NULL,esi
    pop esi
    invoke ExitProcess, NULL
end start
No snowflake in an avalanche feels responsible.