flat assembler
Message board for the users of flat assembler.

Index > Windows > assume in fasm

Author
Thread Post new topic Reply to topic
djca



Joined: 14 Jul 2004
Posts: 21
djca
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.
Post 22 Jul 2004, 16:03
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
The most clear and readable approach is:
Code:
 mov eax, [esi+PAINTSTRUCT.hdc]    


Regards.
Post 22 Jul 2004, 16:12
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7734
Location: Kraków, Poland
Tomasz Grysztar
And my recommendation always was to use dedicated labels:
Code:
mov esi,buff

virtual at esi
  ps_in_buff PAINTSTRUCT ; use the name that makes it the most clear for you
end virtual

mov [ps_in_buff.hdc],0    
Post 22 Jul 2004, 16:44
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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.
Post 22 Jul 2004, 19:05
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7734
Location: Kraków, Poland
Tomasz Grysztar
But more abstract way with the virtual directive allows you to write more universal code, easier to modify and maintain.
Post 22 Jul 2004, 19:14
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
I actually find the use of the virtual directive more confusing. It abstracts a little too far from the code IMO.
Post 23 Jul 2004, 00:52
View user's profile Send private message Visit poster's website Reply with quote
djca



Joined: 14 Jul 2004
Posts: 21
djca
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 Wink.
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'
Post 23 Jul 2004, 07:52
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7734
Location: Kraków, Poland
Tomasz Grysztar
Quote:
The first metod is maybe more clear but when using it you have to know the size of every member in the structure:

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
Code:
mov [esi+PAINTSTRUCT.hdc],0    

will be assembled correctly.
Post 23 Jul 2004, 08:03
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Code:
mov esi,buff 

virtual at esi 
  ps_in_buff PAINTSTRUCT ; use the name that makes it the most clear for you 
end virtual 

mov [ps_in_buff.hdc],0    


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?
Post 29 Jul 2005, 19:44
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7734
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 29 Jul 2005, 20:52
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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:
Code:
macro m{
  local ps_in_buff
  mov esi,buff 

  virtual at esi
    ps_in_buff PAINTSTRUCT ; use the name that makes it the most clear for you
  end virtual

  mov [ps_in_buff#.hdc],0
}m
purge m     


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


Last edited by LocoDelAssembly on 29 Jul 2005, 21:44; edited 1 time in total
Post 29 Jul 2005, 21:33
View user's profile Send private message Reply with quote
farrier



Joined: 26 Aug 2004
Posts: 274
Location: North Central Mississippi
farrier
This is what I use:

Code:
NMHDR.hwndFrom  fix dword [EBX+0]
NMHDR.idFrom    fix dword [EBX+4]
NMHDR.code      fix dword [EBX+8]


wmnotify:
        mov     ebx,            [lparam]
        .if     NMHDR.code,     e, TTN_NEEDTEXT
                invoke          LoadString, [hinstance], NMHDR.idFrom, szBuff, szBuff.size
                mov             TOOLTIPTEXT.lpszText, szBuff
                xor             eax, eax
        .else
                mov             eax, NMHDR.hwndFrom
                .if     eax, e, [hList]
                        .if     NMHDR.code, e, LVN_COLUMNCLICK
                                .if     NM_LISTVIEW.iSubItem, e, 1
;sort listview here
                                .endif
...
    


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

_________________
Some Assembly Required
It's a good day to code!
U.S.Constitution; Bill of Rights; Amendment 1:
... the right of the people peaceably to assemble, ...
The code is dark, and full of errors!
Post 29 Jul 2005, 21:35
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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
Post 29 Jul 2005, 21:55
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
I found another way, if I put "local ps_in_buff." (with the dot) there is no need of "#"
Post 30 Jul 2005, 00:23
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7734
Location: Kraków, Poland
Tomasz Grysztar
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:
Code:
some_global_label:
  mov esi,buff 

  virtual at esi
    .ps_in_buff PAINTSTRUCT
  end virtual

  mov [.ps_in_buff.hdc],0    
Post 30 Jul 2005, 06:22
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:
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

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

Thanks again
Post 30 Jul 2005, 14:10
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.