Let's have a variable named buff defined like this:
buff rb 64. How can I redefine this variable to point to a structure PAINTSTRUCT for example something like that:

mov esi,buff
assume esi: PTR PAINTSTRUCT
mov [esi.hdc],0

In masm there is assume keyword which do this.

The most clear and readable approach is:


Regards.

And my recommendation always was to use dedicated labels:

my recommendation is to always write [esi + PAINTSTRUCT.member], you always know what you are doing and typing 6 more characters isn't that painful.

But more abstract way with the virtual directive allows you to write more universal code, easier to modify and maintain.

I actually find the use of the virtual directive more confusing. It abstracts a little too far from the code IMO.

Ok thanks for the replies.
The first metod is maybe more clear but when using it you have to know the size of every member in the structure:
mov dword [esi+STRUCT.first],5
mov byte [esi+STRUCT.second],99
exept when using registers
mov [esi+STRUCT.third],eax
Actually I write a program which uses one buffer for many different structutres PAINTSTRUCT, MSG, WNDCLASS and so on. These structures are used only for temporaly storage of data. This saves some more memory and disk size .
Here is an example (this is the Template example in fasm package):

; template for program using standard Win32 headers

format PE GUI 4.0
entry start

include '%fasminc%\win32a.inc'

macro Dim var,struct
{
virtual at TempBuff
var struct
end virtual
}


section '.data' data readable writeable

_title db 'Win32 program template',0
_class db 'FASMWIN32',0
mainhwnd dd ?
hinstance dd ?
TempBuff rb 64 ; Temporaly buffer
Dim msg,MSG
Dim wc,WNDCLASS

section '.code' code readable executable

start:
invoke GetModuleHandle,0
mov [hinstance],eax
invoke LoadIcon,0,IDI_APPLICATION
mov [wc.hIcon],eax
invoke LoadCursor,0,IDC_ARROW
mov [wc.hCursor],eax
mov [wc.style],0
mov [wc.lpfnWndProc],WindowProc
mov [wc.cbClsExtra],0
mov [wc.cbWndExtra],0
mov eax,[hinstance]
mov [wc.hInstance],eax
mov [wc.hbrBackground],COLOR_BTNFACE+1
mov [wc.lpszMenuName],0
mov [wc.lpszClassName],_class
invoke RegisterClass,wc

invoke CreateWindowEx,0,_class,_title,WS_VISIBLE+WS_DLGFRAME+WS_SYSMENU,128,128,192,192,NULL,NULL,[hinstance],NULL
mov [mainhwnd],eax

msg_loop:
invoke GetMessage,msg,NULL,0,0
or eax,eax
jz end_loop
invoke TranslateMessage,msg
invoke DispatchMessage,msg
jmp msg_loop

end_loop:
invoke ExitProcess,[msg.wParam]

proc WindowProc, hwnd,wmsg,wparam,lparam
push ebx esi edi
cmp [wmsg],WM_DESTROY
je .wmdestroy
.defwndproc:
invoke DefWindowProc,[hwnd],[wmsg],[wparam],[lparam]
jmp finish
.wmdestroy:

invoke PostQuitMessage,0
xor eax,eax
finish:
pop edi esi ebx
return
endp

section '.idata' import data readable writeable

library kernel,'KERNEL32.DLL',\
user,'USER32.DLL'

import kernel,\
GetModuleHandle,'GetModuleHandleA',\
ExitProcess,'ExitProcess'

import user,\
RegisterClass,'RegisterClassA',\
CreateWindowEx,'CreateWindowExA',\
DefWindowProc,'DefWindowProcA',\
GetMessage,'GetMessageA',\
TranslateMessage,'TranslateMessage',\
DispatchMessage,'DispatchMessageA',\
LoadCursor,'LoadCursorA',\
LoadIcon,'LoadIconA',\
PostQuitMessage,'PostQuitMessage'

No, it's not true in the case of FASM. The size of data can determined from the label placed anywhere inside the memory operand. This code

will be assembled correctly.

If I don't want to use ps_in_buff any more, how can I undefine it? If it's not possible, how can I prevent the use of ps_in_buff from others parts of the code?

You can do it in the same way as the "locals" directive does it for "proc", it does need a bit complex macros to be used, though.

YEEEEAAAAAAHHHHHH, the problem was I forgot to change "mov [ps_in_buffer.hdc], 0" to "mov [ps_in_buff#.hdc], 0"

This is the code now:

I'm sorry you already told me that the dot is part of the name a few months ago but I am still not accustomed

Thanks Tomasz

This is what I use:



I did this because "virtual" was causing problems with jmp's from one side of the virtual to the other. But after a while, I liked the way it looked, and it made sense to me when I looked at the code.

With the new features of the FASM, maybe I should more properly use equ instead of fix?

farrier

I don't know but if you can't undefine those fixes then you can use those symbols in other places of the code. I think using a macro is very clear because I define the macro in the same place I'm using it an then I purge it immediately.

Thanks for the idea anyway

I found another way, if I put "local ps_in_buff." (with the dot) there is no need of "#"

If you use "local ps_in_buff." you don't make "ps_in_buff" local at all - the "ps_in_buff." is a different name than "ps_in_buff".

You can however use the NASM-like label localization for this purposes, too:

It's very clear that I don't want to understand that yet

Thanks again