The MASM Forum

Projects => Rarely Used Projects => GoAsm => Topic started by: shankle on June 23, 2014, 11:51:53 AM

Title: coding problem
Post by: shankle on June 23, 2014, 11:51:53 AM
    06-23-2014
   Masm32 code works but the example in GoAsm doesn't

hMemory          dd  0
MemoryFileSize   dd  0     ' bytes of a file in memory
PtrMem           dd  0


MASM32 CODE
    invoke GlobalAlloc, GPTR,MemoryFileSize
    mov hMemory,eax
    invoke GlobalLock, hMemory
    mov PtrMem,eax
    mov ecx,[PtrMem]
    xor esi,esi               ; clear memory block
    .While esi < MemoryFileSize
      mov dword ptr[ecx+esi], 020202020h    ; 4 bytes at time
      add esi, 4
    .ENDW


GOASM CODE
; MemoryFileSize has been loaded with the number of bytes in a file
    invoke GlobalAlloc, GPTR,[MemoryFileSize]
    mov D[hMemory],eax
    invoke GlobalLock, [hMemory]
    mov D[PtrMem],eax
    mov ecx,D[PtrMem]
    xor esi,esi        ; clear memory block
.n22
;changed from 4 bytes to 1 byte in GoAsm
    cmp esi,D[MemoryFileSize]
    jge >>.n24
    mov B[ecx+esi],020h    ; I suspect this one is causing the problem
    inc esi
     jmp <.n22
.n24
Thanks for any help.
Title: Re: coding problem
Post by: dedndave on June 23, 2014, 12:52:58 PM
hi Jack

try using JAE instead of JGE
Code: [Select]
    jae >>.n24
in masm, this would be an unsigned compare unless you specify SDWORD PTR
Code: [Select]
    .While esi < MemoryFileSize
Title: Re: coding problem
Post by: qWord on June 23, 2014, 06:45:24 PM
The call to GlobalLock is useless.
Title: Re: coding problem
Post by: shankle on June 24, 2014, 05:37:36 AM
Took out Globallock and left jge. That made the program work.
Looks like Globallock in a 64-bit program is a NONO. Possibly also a 32-bit
program. JGE versus JAE made no difference but it probably wouldn't
hurt to use JAE.
Thanks guys for your time and responses.
Title: Re: coding problem
Post by: qWord on June 24, 2014, 06:35:55 AM
Looks like Globallock in a 64-bit program is a NONO. Possibly also a 32-bit
program.
You can still used it, but Microsoft recommend to use the Heap functions instead.
Title: Re: coding problem
Post by: jj2007 on June 24, 2014, 07:19:31 AM
Looks like Globallock in a 64-bit program is a NONO. Possibly also a 32-bit
program.

Can't speak for 64-bit here but in 32-bit the GlobalLock just returns the handle that you gave it... harmless and useless, as qWord rightly wrote.
Title: Re: coding problem
Post by: nidud on June 24, 2014, 08:06:27 AM
deleted
Title: Re: coding problem
Post by: jj2007 on June 24, 2014, 10:02:33 AM
However, HeapAlloc cant allocate movable memory, so you still have to use GlobalAlloc for this I guess.

The only real use of "movable" memory is with the clipboard.
If you mean changing the size of allocated memory, use HeapReAlloc (and don't forget to adjust your pointer ;))

The terminology is lousy. In reality,
- "movable" means the handle can be passed, via the clipboard, to another process.
- non-"movable" will move if you resize it, and the new bigger size doesn't fit in the old slot.
Go figure 8)
Title: Re: coding problem
Post by: nidud on June 24, 2014, 10:43:14 AM
deleted