flat assembler
> Windows > Iczelion's Tutorial #2b Win64 fasm formatGoto page 1, 2 Next |
| Author |
|
|
Code: format PE64 GUI 5.0 entry start include 'win64a.inc' section '.text' code readable executable start: push rbp mov rbp,rsp sub rsp,30h invoke GetModuleHandle,NULL mov [x1],rax invoke LoadIcon,NULL,IDI_APPLICATION mov [x2],rax invoke LoadCursor,NULL,IDC_ARROW mov [x3],rax mov rax,x1 mov [rsp+20h],eax lea ecx,[buffer] lea edx,[fmt] mov r8,x3 mov r9,x2 call [wsprintf] invoke MessageBox,NULL,buffer,MsgCaption,MB_OK invoke ExitProcess,NULL section '.data' data readable writeable MsgCaption db "Iczelion's Tutorial #2b",0 fmt db "hCursor = %08Xh",0Ah,"hIcon = %08Xh",0Ah,"hInstance =%08Xh",0 n = $ - fmt + 12 buffer db n dup(?) x1 dq ? x2 dq ? x3 dq ? section '.idata' import data readable writeable library kernel32,'KERNEL32.DLL',\ user32,'USER32.DLL' include 'api\kernel32.inc' include 'api\user32.inc' |
|||
04 Jan 2018, 05:50 |
|
|
Hi, yeohhs!
do you translate Examples for Win64 Iczelion tutorial from masm dialect to fasm dialect? I can help you  |
|||
|
09 Jan 2018, 07:26 |
|
|
Mikl___ wrote: Hi, yeohhs! Hi Mikl___, So far, I've done only examples 2, 2a, and 2b. I'm beginning to learn Win64. And I don't know much about masm. If you can help, yes, that would be awesome! 
Thanks! _________________ “It’s not that we have a short time to live, but that we waste a lot of it.” -Lucius Annaeus Seneca |
|||
|
09 Jan 2018, 09:16 |
|
|
Hi, yeohhs!
then a few questions to you... writing a program in assembler is almost the same as collecting a yacht (expensive car) for a specific customer. Do you know what the program "Iczelion's Tutorial #2b" is for? To find the constants that return functions GetModuleHandle, LoadIcon, LoadCursor. These constants will be different for different versions of Windows, but for your computer until you change the version of Windows these constants will always be the same. But you do not need to call at the beginning of each program functions GetModuleHandle, LoadIcon, LoadCursor. Attach the image that the program "Iczelion's Tutorial #2b" shows on the screen |
|||
|
10 Jan 2018, 01:48 |
|
|
Yes, I see. That's very interesting. _________________ “It’s not that we have a short time to live, but that we waste a lot of it.” -Lucius Annaeus Seneca |
|||
|
10 Jan 2018, 08:55 |
|
|
Hi, yeohhs!
I see the topic has ceased to be interesting for you, since I asked to attach a picture that the program "Iczelion's Tutorial #2b" shows on the screen, but you ignored my request Saya dapati topik itu tidak lagi menarik minat anda, kerana saya meminta untuk melampirkan gambar yang ditunjukkan oleh program "Iczelion's Tutorial # 2b", tetapi anda tidak mengendahkan permintaan saya |
|||
|
13 Jan 2018, 15:43 |
|
|
Mikl___ wrote: Saya dapati topik itu tidak lagi menarik minat anda, kerana saya meminta untuk melampirkan gambar yang ditunjukkan oleh program "Iczelion's Tutorial # 2b", tetapi anda tidak mengendahkan permintaan saya Some high-quality translations you have there. I re-wrote yeoh's interpretation of Tutorial #2b, but this time I use a minimalist approach, FASM-style, 64-bit - flat and fastcall. Code: format PE64 GUI 5.0 include 'win64a.inc' sub rsp,8 fastcall [GetModuleHandle],NULL mov rbx,rax fastcall [LoadIcon],NULL,IDI_APPLICATION mov rdi,rax fastcall [LoadCursor],NULL,IDC_ARROW mov rsi,rax fastcall [wsprintf],buffer,fmt,rsi,rdi,rbx fastcall [MessageBox],NULL,buffer,MsgCaption,MB_OK fastcall [ExitProcess],NULL MsgCaption db "Iczelion's Tutorial #2b",0 fmt db "hCursor = 0x%p",0Ah,"hIcon = 0x%p",0Ah,"hInstance = 0x%p",0 n = $ - fmt buffer db n dup(?) data import library kernel32,'KERNEL32.DLL',\ user32,'USER32.DLL' include 'api\kernel32.inc' include 'api\user32.inc' end data Output hcursor = 0x0000000000010003 hIcon = 0x000000000001002B hInstance = 0x0000000000400000 Is the output acceptable? My proposition: Do you have any intention to fully translate all your work to FASM 64-bit instead of MASM64? As you can see here, FASM is extremely flexible and in many cases, better than MASM. Btw, keep up the good work. We could use a person of your technical knowledge for Win64 development on this board. |
|||
|
13 Jan 2018, 22:07 |
|
|
Mikl___ wrote: Hi, yeohhs! Hi Mikl___, I must confess I lost interest after reading more MASM code. It feels like I'm reading Java. As for ignoring your request, I apologize. Due to my severely retarded social skills, I usually cannot respond appropriately. Sincerely, yeohhs _________________ “It’s not that we have a short time to live, but that we waste a lot of it.” -Lucius Annaeus Seneca |
|||
|
13 Jan 2018, 23:50 |
|
|
fasmnewbie wrote:
Terima kasih!  _________________ “It’s not that we have a short time to live, but that we waste a lot of it.” -Lucius Annaeus Seneca |
|||
|
13 Jan 2018, 23:54 |
|
|
Hi, yeohhs and fasmnewbie!
There is Iczelion's Tutorial #3 with fasmnewbie constant. I repeat these constants will be different for different versions of Windows Code: format PE64 GUI 5.0 entry WinMain include 'd:\fasm\include\win64a.inc' section '.text' code readable writeable executable ;---------------------------------------------------------------------- proc WinMain local msg:MSG frame xor ebx,ebx mov esi,400000h ;hInstance mov edi,ClassName mov eax,1002Bh ;hIcon push rax ;hIconSm push rdi ;lpszClassName push rbx ;lpszMenuName push COLOR_WINDOWTEXT;hbrBackground push 10003h ;hCursor push rax ;hIcon push rsi ;hInstance push rbx ;cbClsExtra & cbWndExtra db 68h dd WndProc ;lpfnWndProc push sizeof.WNDCLASSEX;cbSize & style invoke RegisterClassEx,esp ;addr WNDCLASSEX push rbx push rsi ;rsi=400000h shl esi,9 ;rsi=CW_USEDEFAULT push rbx push rbx push rsi push rsi push rsi push rsi sub esp,20h mov r9d,WS_OVERLAPPEDWINDOW or WS_VISIBLE xor ecx,ecx invoke CreateWindowEx,,edi,edi lea edi,[msg] @@: xor edx,edx xor r8d,r8d xor r9d,r9d invoke GetMessage,edi invoke DispatchMessage,edi jmp @b WndProc:cmp edx,WM_DESTROY je wmDESTROY jmp [NtdllDefWindowProc] wmDESTROY:xor ecx,ecx invoke RtlExitUserProcess endf endp ;----------------------------------- ClassName db "Iczelion's Tutorial #3",0 ;------------------------------------------------------------------------ section '.idata' import data readable writeable library ntdll,'ntdll.DLL',\ user,'USER32.DLL' import ntdll,\ RtlExitUserProcess,'RtlExitUserProcess',\ NtdllDefWindowProc,'NtdllDefWindowProc_A' import user,\ RegisterClassEx,'RegisterClassExA',\ CreateWindowEx,'CreateWindowExA',\ GetMessage,'GetMessageA',\ DispatchMessage,'DispatchMessageA'
|
||||||||||
|
14 Jan 2018, 00:24 |
|
|||||||||
|
@Mikl
I don't quite understand your point. My point was that it is easier to do Windows things in FASM if compared to MASM in many ways. What is it with MASM people and their obsessions of PROC and invoke? Does MASM64 support invoke anymore? AFAIK, MASM64 even dropped .if / .endif altogether along with INVOKE, PROTO and other high-level stuff. That should at least tell you something about the direction MASM64 is taking. And the good news is, those high-level stuff are still available in FASM 64-bit. I can see you're using them a lot, although I don't quite understand why would you use invoke on 64-bit WinAPI. I could be wrong since I am not good at WinAPI programming though. But still why not use FASM instead? Why deny yourself a good opportunity of using an excellent assembler? |
|||
|
14 Jan 2018, 01:20 |
|
|
hi, fasmnewbie!
one dialect (masm) of the language of assembler is not at all worse than another dialect (fasm) and what is not provided by the compiler (ml64.exe) may be added using macros (invoke, .if, .while, .for etc.) Last edited by Mikl___ on 14 Jan 2018, 04:23; edited 1 time in total |
|||
|
14 Jan 2018, 03:57 |
|
|
@Mikl
I am not even talking about third-party macros. I was referring to how MASM is bad to the core. Here's your equivalent example for #2b in MASM 'dialect' Code: OPTION DOTNAME option casemap:none include temphls.inc include win64.inc include kernel32.inc include user32.inc includelib kernel32.lib includelib user32.lib OPTION PROLOGUE:rbpFramePrologue .code WinMain proc push rbp mov rbp,rsp sub rsp,30h invoke GetModuleHandle,NULL mov x1,rax invoke LoadIcon,NULL,IDI_APPLICATION mov x2,rax invoke LoadCursor,NULL,IDC_ARROW mov x3,rax mov rax,x1 mov [rsp+20h],eax lea ecx,buffer lea edx,fmt mov r8,x3 mov r9,x2 call wsprintf invoke MessageBox,NULL,&buffer,&MsgCaption,MB_OK invoke ExitProcess,NULL WinMain endp MsgCaption db "Iczelion's tutorial #2b",0 fmt db "hCursor = %08Xh",0Ah,"hIcon = %08Xh",0Ah,"hInstance =%08Xh",0 n = $ - fmt + 12 buffer db n dup(?) x1 dq ? x2 dq ? x3 dq ? end Here's one problem: push rbp mov rbp,rsp This is basically a standard call prologue, on top of a fastcall entry point! What's the purpose of a fastcall if everybody is going back to using a standard call prologue and epilogue? It beats the whole purpose and design philosophy of 64-bit fastcall. As if you're not enough, you even preceded it with OPTION PROLOGUE:rbpFramePrologue So altogether, plus the PROC hidden code, you're doing 3 stack setup redundancy. Here's 2nd problem with ML64 core features; OPTION DOTNAME This is what exactly? This shows that ML/ML64 PROC cannot contain the behavior of its own local labels / variables? This is not a problem for a small code, but for a large codes, you'll find yourself using lots of @@ and "lblxx", with a very slim chance of a self-documenting source, not to mention ugly-looking source code. I know you're good at WinAPI. I am not denying that. Only that your choice of assembler is incorrect, IMO. Many people will appreciate your efforts more if you switched to FASM |
|||
|
14 Jan 2018, 04:22 |
|
|
Quote: I was referring to how MASM is bad to the core 
push rbp/mov rbp,rsp/sub rsp,XX == enter XX,0 I usually use this construction OPTION PROLOGUE:rbpFramePrologue /OPTION DOTNAME I usually hide everything that is superfluous in included file win64a.inc I know quite a few superficially several dialects NASM, TASM, FASM, MASM, GoAsm and each has its own advantages Large programs are written in C/C++/С#, and assembler is used as inserts for critical sections of the program |
|||
|
14 Jan 2018, 04:41 |
|
|
Mikl___ wrote:
That's a standard call prologue. For 64-bit WinAPI which is ironically designed by MS, those are really not necessary. The purpose of FASTCALL is to avoid heavy stack frame setup in the first place in order to increase performance and less dependency on microcodes of stack programming. SUB RSP,40 is the basic fastcall stack setup, which is again, ironically recommended by MS. SUB is not a stack instruction, a PUSH is. While they both move the stack, one involves only simple arithmethic (SUB), while the other one (PUSH) involves stack programming microcodes. Seems like you been spending most of your time on the wrong forum board. You need to ditch your current membership of the other board, and spend your time exclusively with us ;D |
|||
|
14 Jan 2018, 04:59 |
|
|
I think most forum members here will agree with me that you should stick to FASM-only tutorials.
Too bad this board don't have "agree" or "like" button, or else you know what I am talking about. Who's with me? ;D |
|||
|
14 Jan 2018, 05:12 |
|
|
Quote: you should stick to FASM-ONLY tutorials fasmnewbie, you are too categorical in your judgments - only black or only white. And besides black and white there are a million shades of gray  |
|||
|
14 Jan 2018, 05:37 |
|
|
There is Iczelion's Tutorial #4 with fasmnewbie constant.
Code: format PE64 GUI 5.0 entry WinMain include 'd:\fasm\include\win64a.inc' section '.text' code readable writeable executable ;---------------------------------------------------------------------- proc WinMain local msg:MSG frame xor ebx,ebx mov esi,400000h mov edi,ClassName mov eax,1002Bh ;hIcon push rax ;hIconSm push rdi ;lpszClassName push rbx ;lpszMenuName push COLOR_WINDOW;hbrBackground push 10003h ;hCursor push rax ;hIcon push rsi ;hInstance push rbx ;cbClsExtra & cbWndExtra db 68h dd WndProc ;lpfnWndProc mov rax,((CS_HREDRAW or CS_VREDRAW)shl 32)+sizeof.WNDCLASSEX push rax;cbSize & style invoke RegisterClassEx,esp ;addr WNDCLASSEX push rbx push rsi ;rsi=400000h shl esi,9 ;rsi=CW_USEDEFAULT push rbx push rbx push rsi push rsi push rsi push rsi sub esp,20h mov r9d,WS_OVERLAPPEDWINDOW or WS_VISIBLE xor ecx,ecx invoke CreateWindowEx,,edi,edi lea edi,[msg] @@: xor edx,edx xor r8d,r8d xor r9d,r9d invoke GetMessage,edi invoke DispatchMessage,edi jmp @b ;---------------------------- WndProc: hWnd equ rbp+10h ps equ rbp-sizeof.PAINTSTRUCT expRect equ ps-sizeof.RECT enter sizeof.PAINTSTRUCT+sizeof.RECT+28h,0 mov [hWnd],rcx cmp edx,WM_DESTROY je wmDESTROY cmp edx,WM_SIZE je wmSIZE cmp edx,WM_PAINT je wmPAINT leave jmp [NtdllDefWindowProc] wmDESTROY:xor ecx,ecx invoke RtlExitUserProcess wmSIZE: mov r8d,TRUE xor edx,edx invoke InvalidateRect;send WM_PAINT if size changes jmp wmBYE wmPAINT:lea edx,[ps] invoke BeginPaint lea edx,[expRect] invoke GetClientRect,qword[hWnd] mov edx,expTxt lea r9d,[expRect] or r8,-1 invoke DrawText,qword[ps+PAINTSTRUCT.hdc],,,,DT_SINGLELINE or DT_CENTER or DT_VCENTER lea edx,[ps] invoke EndPaint,qword[hWnd] wmBYE: ret endf endp ;----------------------------------- ClassName db "Iczelion's Tutorial #4 Painting with Text",0 expTxt db 'Win64 assembly with FASM is great and easy',0 ;------------------------------------------------------------------------ section '.idata' import data readable writeable library ntdll,'ntdll.DLL',\ user,'USER32.DLL' import ntdll,\ RtlExitUserProcess,'RtlExitUserProcess',\ NtdllDefWindowProc,'NtdllDefWindowProc_A' import user,\ RegisterClassEx,'RegisterClassExA',\ CreateWindowEx, 'CreateWindowExA',\ GetMessage, 'GetMessageA',\ BeginPaint, 'BeginPaint',\ GetClientRect, 'GetClientRect',\ DrawText, 'DrawTextA',\ EndPaint, 'EndPaint',\ InvalidateRect, 'InvalidateRect',\ DispatchMessage,'DispatchMessageA'
|
||||||||||
|
14 Jan 2018, 06:20 |
|
|||||||||
|
Quote: FASM is extremely flexible and in many cases, better than MASM fasmnewbie, if I use invoke or fastcall in FASM I get the procedure framed "sub rsp,20h" and "add rsp,20h" even where I do not need it, when several procedures are called sequentially for example Code: invoke MessageBox,NULL,buffer,MsgCaption,MB_OK invoke ExitProcess,NULL Code: add rsp,20h mov r9,0 lea r8,[MsgCaption] lea rdx,[buffer] mov rcx,0 call MessageBox add rsp,20h sub rsp,20h mov rcx,0 call ExitProcess add rsp,20h To avoid unnecessary additions and subtractions from the register, I use the construction frame/endf but in begin of procedure I get Code: push rbp mov rbp,rsp sub rsp,30h <-- local msg:MSG sub rsp,20h <-- frame  |
|||
|
14 Jan 2018, 09:25 |
|
|
Quote: if I use invoke or fastcall in FASM I get the procedure framed "sub rsp,20h" and "add rsp,20h" even where I do not need it, when several procedures are called sequentially for example Then don't use them. FASM has been enjoying the freedom to NOT use any high-level statements. MASM are not so lucky and flexible. Like your recent example of stacking up PROC + LOCAL and then FRAME...ENDF! Why would you even do that? Do you have a problem with aligning the stack and shadow space? Stacking up PROC with FRAME...ENDF? Where's your common sense? What are you trying to achieve with that? Now there's your problem right there -- you're trying to convince people that you're writing FASM code but you're doing it with MASM high-level approach. That will be misleading to the unsuspecting audience. You're even confused yourself! ;D |
|||
|
14 Jan 2018, 11:01 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|