Memory problems: heap allocation

[dedndave]

Code Select Expand

invoke MessageBox, hWin, fileshowmsg, addr InfoCaption, MB_OK

try ths instead...

Code Select Expand

invoke MessageBox, hWin, addr fileshowmsg, addr InfoCaption, MB_OK

btw...
my code takes 4 bytes
when you are done, the value is in ECX where it can be tested for error conditions
after that, the value is of little use
i don't care how you do it, it will take more bytes to accomplish the same by any other means
but, that's not an important issue

[NoCforMe]

I don't like using them because they generate code that I can't see. (Well, I can see it in the listing, but not in the source.)

I want to write assembly language, not a higher-level-looking code.

It's a matter of personal style. I strive to make my code as understandable as possible (to me, at any rate).

Pure assembly language will always be somewhat "spaghetti"-like by virtue of the fact that we HAVE to use "gotos" to get anywhere.

Short answer: I don't like using IF-ELSEIF in my code. I may learn to like it later.

[NoCforMe]

Code Select Expand

invoke MessageBox, hWin, fileshowmsg, addr InfoCaption, MB_OK

try ths instead...

Code Select Expand

invoke MessageBox, hWin, addr fileshowmsg, addr InfoCaption, MB_OK

Doh! Doh! Doh! (Bangs head on keyboard)

Thank you! I owe you one, buddy.

[dedndave]

not only that - it displays the right stuff   :U

[NoCforMe]

OK, to maybe wrap this thread up:

The reason for my posting turned out to be a really STUPID mistake on my part. But to address the topic, I've found that heap allocation works.

However, looking through the MASM32 examples, I see other methods used. For instance, the "dibfile" example uses GlobalAlloc() instead.

The MSDN memory-management explanation of heap functions says "New applications should use the heap functions instead of the global and local functions for this purpose."

I guess I'll use the heap for now. (This is for reasonably small allocations; no 4GB database files.)

[clive]

This is for reasonably small allocations; no 4GB database files.

Any process that has to load an entire file into memory to work doesn't scale well. I might have 16GB in my desktop, my customers almost certainly don't, and a bunch will likely have less than a GB of physical memory.

[dedndave]

also, some functions specifically state which type of memory allocation should be used

For instance, the "dibfile" example uses GlobalAlloc() instead.

not able to see that code, but i know, for example, that the clipboard functions want you to use GlobalAlloc
probably a similar situation for the dibfile example

GlobalAlloc isn't going to go away, as much as ms may like to do so
HeapAlloc is my favorite because it is fast and makes for small code
but GlobalAlloc, LocalAlloc, and VirtualAlloc all have their uses

[clive]

Or Map the file and then it won't take up more physical memory than you touch, and won't consume page file space because it's already pinned/associated with a file. Presuming of course you only want to read the data, and not modify it in-place.

[jj2007]

Dave is really good at spotting such goodies. Which, by the way, become clear only if you see the full code because...

Code Select Expand

fileshowmsgTXT DB "File contents: "
fileshowmsg dd fileshowmsgTXT

... this is a legal option not requiring the ADDR keyword before fileshowmsg.

The headers from .386 to msvcrt.lib can be replaced with a single line:
include \masm32\include\masm32rt.inc
(and certainly, that is a matter of taste)

[dedndave]

that would be ideal
if he were to modify his masm32rt.inc file, we could assemble his programs without changing anything