The assembler hangs when I include, in .DATA?, the line:
fmemt DB 100000 DUP (?) ;File MEMory Temp - 1 meg
although
fmemt DB 10000 DUP (?) ;File MEMory Temp - 64k
works OK.
I assemble and link using a batch file:
c:\aw.bat for debug at g:\lfw
g:
cd lfw
g:\masm32\bin\ml /c /coff /Cp /Fl /W2 /Zi g:\lfw\lfw.asm >errs
g:\masm32\bin\link /SUBSYSTEM:WINDOWS /LIBPATH:g:\masm32\lib /DEBUG /DEBUGTYPE:CV lfw.obj >>errs
cd\
c:
I suspect that I need to add something to the link options, but so far I cannot find documentation for what.
Can anyone suggest how to get around the limit or where I might look for the answer?
Thanks.
Hi,
It does not hang... it is just assembling very very very slow.
This is "well known" bug in MASM: it slows down a lot when assembling huge non-initialized data blocks.
The solution is to allocate the data buffer at runtime using VirtualAlloc or GlobalAlloc etc.
Doing so is anyway a much better programming practice for such buffers. At least at runtime you can check for an error (not enough memory for example)
Quote from: BogdanOntanu on August 05, 2007, 03:48:15 AM
Hi,
It does not hang... it is just assembling very very very slow.
This is "well known" bug in MASM: it slows down a lot when assembling huge non-initialized data blocks.
The solution is to allocate the data buffer at runtime using VirtualAlloc or GlobalAlloc etc.
Doing so is anyway a much better programming practice for such buffers. At least at runtime you can check for an error (not enough memory for example)
OK. Thanks.
It looks then as if what I need, to replace the "fmemt DD 100000" is [in the initialization part of my winmain procedure]:
invoke VirtualAlloc, 0, 100000, MEM_COMMIT, PAGE_READWRITE
mov [fmemt], eax
Then instead of "mov esi, OFFSET fmemt", it is "mov esi, [fmemt]" and I have *virtually* the same thing.
It does seem a waste to initialize to zeros, since it (or all of it that matters) will be overwritten.
Thanks again.
GlobalAlloc may suit you better :wink
And BTW do not forget to release the allocated memory at the end of the application :D
Assembling modules with large uninitialized data blocks can be done by omitting the /coff switch. OMF object modules are created more easily.
Quote from: Tedd on August 05, 2007, 12:10:54 PM
GlobalAlloc may suit you better :wink
I believe you are right. I was put off by the SDK statement:
Note The global functions are slower than other memory management functions and do not provide as many features. Therefore, new applications should use
the heap functions
But until I need the extra features, I'll try GlobalAlloc.
Thanks.