News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

coding problem

Started by shankle, June 23, 2014, 11:51:53 AM

Previous topic - Next topic

shankle

    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.

dedndave

hi Jack

try using JAE instead of JGE
    jae >>.n24

in masm, this would be an unsigned compare unless you specify SDWORD PTR
    .While esi < MemoryFileSize

qWord

The call to GlobalLock is useless.
MREAL macros - when you need floating point arithmetic while assembling!

shankle

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.

qWord

Quote from: shankle on June 24, 2014, 05:37:36 AMLooks 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.
MREAL macros - when you need floating point arithmetic while assembling!

jj2007

Quote from: shankle on June 24, 2014, 05:37:36 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.

nidud

#6
deleted

jj2007

Quote from: nidud on June 24, 2014, 08:06:27 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)

nidud

#8
deleted