The MASM Forum

For generic.asm I have the following small notes of his good explanations.
It is not explained in generic.asm what the following macros also do:

1. Invoke
2. ptr$(WndProc)
3. rv(LoadCursor,NULL,IDC_ARROW)
4. .if, .elseif, .endif
5. .if wParam == 1000
6. Why the second .asm file using macros is better than the first one not using macros?

The MACROS explanation needs to be changed to tell the truth.

MACROS is a deprecated method for expanding text during assembly in MASM32. Using them becomes difficult and wastes valuable time for the novice MASM64 programmer. He needs to learn in detail an obsolete high-level language (macros) and then learn MASM64.
MS MASM64 API  does not use macros and allows to programmer clean and convenient way to use COMMON blocks of code with capacity to use DIFFERENT parameters in each block starting with service word "proc" and ending with "endp".

Some forum members mistakenly put an equal sign between Newcomer and Newbie. They wasting Newbie's time with outdated Win32+Macros training without caring about Newbie's  present and future.

The third file is written in a language I do not understand and cannot comment on. Sorry! :nie:

Thank you Zedd151.

ognil, I think you need to understand macros a bit better, they're not just "a deprecated method for expanding text during assembly".

There is no such thing as "MS MASM64 API" but there are two different things called "MS API" and "MASM64"

The whole point of MASM64 is to let people ignore the peculiarities of the Win64 ABI and just code.

Don't forget what the first "M" in "MASM" stands for  :biggrin:

And realize that like one's choice of editor, the use of macros is what they call a religious issue, meaning that some folks have strong opinions one way or the other regarding them, and there are sometimes raging arguments over them. (I come down on the "few to no macros for me, thank you very much" side, while others, like JJ, use them frequently and make them an integral part of their code.)

Like they say, different strokes for different folks ...

Hi sinsi,

Quoteognil, I think you need to understand macros a bit better...

Interesting thought! I'm Newcomer but not a Newbie and prefer not to waste my time with some pseudo high level language that won't bring me anything in the future. I use this time to improve my C++.

Thanks for opening my eyes to what MS is, but you didn't say what you think the definition of a macro is and why it must be used in assembly programs.

I would appreciate your comment on my macro-free code here:

https://masm32.com/board/index.php?action=dlattach;attach=17529 (https://masm32.com/board/index.php?action=dlattach;attach=17529)
and here:

https://masm32.com/board/index.php?action=dlattach;attach=17511 (https://masm32.com/board/index.php?action=dlattach;attach=17511)

Thank you. :azn:

Quote from: sinsi on September 25, 2024, 02:01:33 PMI think you need to understand macros

I will mark this date in my diary, sinsi ❤️

Quote from: ognil on September 26, 2024, 12:08:54 AMbut you didn't say what you think the definition of a macro is

That's for you to discover

Quote from: ognil on September 26, 2024, 12:08:54 AMand why it must be used in assembly programs

Where did I say that they must be used?

Quote from: ognil on September 26, 2024, 12:08:54 AMI would appreciate your comment on my macro-free code here

Macro-free? include  \masm32\include64\masm64rt.inc

Quote from: ognil on September 26, 2024, 12:08:54 AM[I] prefer not to waste my time with some pseudo high level language that won't bring me anything in the future. I use this time to improve my C++

I'm in agreement here, surprisingly.
Seeing the way some people code with macros here and produce source that looks just like C, with indented if/else blocks and all, I wonder, why are they even bothering with assembly language? Why not just use C? For most purposes it's not going to be noticeably slower or anything ...

Thanks sinsi,

QuoteMacro-free? include  \masm32\include64\masm64rt.inc

Because it frames and keeps the stack aligned.
Otherwise, for each program I have to write something like:

extern __imp_MessageBoxA:qword
MessageBoxA equ <__imp_MessageBoxA>
.data
caption db "'Macbeth', specifically Act 5, Scene 5",0
text db 'Life is a tale told by an idiot, full of sound and fury, signifying nothing',0

.code
main proc frame
     push rbp
.pushreg  rbp
     sub  rsp, 010h
.allocstack 010h
     mov  rbp, rsp
.setframe rbp, 0
.endprolog
; modify the stack pointer outside of the prologue
     sub  rsp, 060h
;***********************
    xor   r9d, r9d
    lea   r8,  caption
    lea   rdx, text
    xor   rcx, rcx
    call  MessageBoxA
;***********************
add rsp, 060h
add rsp, 010h
pop rbp
ret
main endp
;***********************
end :smiley:

Quote from: ognil on September 26, 2024, 01:09:40 PMBecause it frames and keeps the stack aligned.

Yes by using prologue and epilogue macros.

As for your test program isn't that just an invoke-less copy of one of hutch's examples? Even the variable names are the same.

Hi, ognil

QuoteLife is a tale told by an idiot, full of sound and fury, signifying nothing.

Sounds fairly the philosophical words.
this showed you acknowledge it. you'r not a master of life, rather than a slave of life.
Chairman Mao said "

QuoteWherever there is oppression, there is counterattack.

"
"

QuoteFighting the sky, the earth, and people,that brings you to an endless enjoyment.

"

Hi sinsi,

QuoteAs for your test program isn't that just an invoke-less copy of one of hutch's examples? Even the variable names are the same.

The example text is copy-paste-correct from "Examples" without the more important part:
WndProc                proc   
; Save 4 registers here or in global variables                     
                        mov    [rbp+16], rcx                      ; rbp+8=Return address
                        mov    [rbp+24], rdx                       
                        mov    [rbp+32], r8
                        mov    [rbp+40], r9
...
...
@Ret: 
                        lea    rsp,[rbp+8]                        ; rsp=Return address
                        lea    rax,DefWindowProc
; Restore 4 registers from here or from global variables                         
                        mov    r9, [rsp+32]
                        mov    r8, [rsp+24]
                        mov    rdx,[rsp+16]
                        mov    rcx,[rsp+8]
                        jmp    qword ptr [rax]
:smiley:

Is call a macro or an assembler directive? Hmm.. I'm too sleepy to find out.

What sinsi said, below this post.  :toothy:

I'm using hutch's and vasily's macros, ognil Professor.

Quote from: ognil on October 07, 2024, 05:46:58 AMGreat idea, but pls, stop using the macros in MASM64

Mate, you are using macros, hutch made invoke, prologue and epilogue macros, which rely on a shitload of other macros. If you are using masm64rt.inc then you are using macros :rolleyes:

Hi, sinsi

The creation of this site by Hutch as well as all programs and tools in it must agree the requirements and rules of  the owner - MS.
When the owner(MS) changes software requirements and rules are communicated to users.

In our case with a note in parentheses (32-bit MASM only).

It is not fair to use Hutch's authority and name now that he is no longer with us.
It can be seen that when he created the site with his tools and examples he followed all the rules and requirements of the MS.

The problem is that after him there is no one to update some of his tools (including macros) according to the changed MS rules, in other words to use rules, macros, directives, etc.
without the note (for 32-bit MASM only). :undecided:

Quote:by  zedd151:  quote from ognil

It is from MS not from ognil. :thumbsup:

Quote from: ognil on October 07, 2024, 03:20:57 PMthis site [...] must agree the requirements and rules of  the owner - MS.

WTF are you talking about? Microsoft doesn't own this site.

True, the 64-bit SDK available here needs to play by Microsoft's rules (at least those governing assembly language programming), but that's not a concern: it does conform to those rules. Has to, really, by definition, since it uses Microsoft tools to assemble and link programs. As everyone knows, macros happen to be an integral part of the assembler (hence the name). So far as documentation on how to use those macros, that's easily found in the Microsoft Learn document repository.

So none of us here know what you're going on about in this thread. It's one thing to avoid using macros (I do), as that's a personal decision. But to impose that restriction on those who want to learn 64-bit MASM programming? No way, Jose.

And why do you keep sticking "32-bit MASM only" in big red letters in your posts? This thread is about 64-bit programming.

Remove the line include \masm64\include64\masm64rt.inc and let us know how you fare with no macros.

Quote from: ognil on September 25, 2024, 01:13:56 PMMACROS is a deprecated method for expanding text during assembly

Not really. Where you found that fallacy?

I moved these posts here to this New Topic, thinking that perhaps further useful & creative discussion might occur on the Topic but sadly, it seems Not,..

I have attempted to tidy it up and will leave it open, in the hope that further reasonable and civil discussion can occur  :smiley: