Hi,
I've following dialog proc:



I don't understand why, in wmclose message, local "result" var contains garbage...

Thank you.

And what you expect to contain? The local variables are defined on stack.
In your procedure "mov [result], 0" happens on different call of the procedure than "movzx eax, [result]" between these different calls the stack pointer might be changed and the stack content as well.

Local variables do not provide persistence between calls because other code can use the same piece of stack memory and trash anything you were trying to put there.

You have no option but to create a global label to give you the persistence you want.

In the first post in this thread: http://board.flatassembler.net/topic.php?t=10518 (near the end of post) you can find the window_prologue/window_epilogue macros that extend "proc" directive in such a way that it defines window procedure that stores its local variables in a memory block allocated upon window creation. This allows to have variables local with respect to window and not just to a single procedure call.

Just to add a little more, the variables defined by proc are not of this kind: http://en.wikipedia.org/wiki/Local_variable#Static_local_variables

Perhaps local/locals could be extended to provide static local variables and let .end allocate the space with a separate R/W section? (and optionally expose a macro to give the opportunity to deploy the variables on an existing section)

This should be done with customized prologue/epilogue, just like the example I provided. Also see section 3.1.5 of FASM.PDF, which is the same as section 1.5 of online "Windows programming headers" documentation.

Tomasz, I meant as part of the official package code base. Still, I think that doing what section 1.5 says is not enough, as I didn't mean ALL locals to be declared as static, but only those tagged as such (i.e. at least two localbase@proc are needed here.) Or is still possible by just using what is documented there?

Loco: remember that FASM can't combine sections itself. How exactly do you expect the ".end" macro to place these variables into data section? Or do you think it is okay for official macro to create extra section for these variables?

vid, yes, extra section, I've called it "separate R/W section" earlier. I think it is an acceptable inefficiency for the extended headers that are meant to make programming easier. But still, letting override the placement of the variables would be a welcomed feature.

FASM already has enough problems with non-standard executable layout (and thus false virus alarms, incompatibility with poorly written tools, etc.). Extra section would only make this worse. And being able to conveniently limit scope of global variable to high-level procedure is little payoff for assembly. Once you decide to write in assembly, quality of your product should be in focus, not ease of development. For that, use HLL.

Thank you all for answers.
I've another silly question...local variables are initialized to zero ?
I've not found this kind of info into manual.

Thanks.

No they are not (of course). The local variables are simply part of the stack, allocated for use from some part of the program.
This memory is filled with information, pushed there from other parts of the program on previous call/push instructions.

Of course, one can write macro to zero this memory on the input of the procedure, but IMHO, this would be not good idea, because of 2 reasons:
1. you don't need all your variables to be 0 - so, you still need to initialize them with the proper values - why to make it twice?
2. Assembly language programming relies on the clearness. It is not good practice to process data in hidden manner - through macros.

The proper solution (if you like such things) would be macro "clear" that you can use to clear the local variables explicitly.
But "mov [var], 0" is not longer to type, but is more readable - besides the action it demonstrates also how it is done.

no. if you wish to initialize them you have to do it with your code.

Thank you all for answers.
I've another silly question...local variables are initialized to zero ?
I've not found this kind of info into manual.

Thanks.

goto 128048