MASM64 problem with if macro

[hutch--]

 

Or a high efficiency variation.

; «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»

switchtst proc num1:QWORD

    cmp num1, 0
    jne @F
    rcall MessageBox,0,str$(num1),"Zero",MB_OK
    ret
  @@:
    cmp num1, 1
    jne @F
    rcall MessageBox,0,str$(num1),"One",MB_OK
    ret
  @@:
    cmp num1, 2
    jne @F
    rcall MessageBox,0,str$(num1),"One",MB_OK
    ret
  @@:
    ret

switchtst endp

; «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»

[C3]

Hi,

The solution to the problem is what I tought. The 64-bit wParam uses only high word and low word (low 32bits) for the messages. So I changed that "C syntax" code wParam+4 to wParam+2. So it uses high word to do logic if its for Menu or for the Accelerator.
Code might not be elegant still, I have to check what I can optimize for reducing instructions or improve use of the registers.

Code Select Expand

  .case WM_COMMAND
    .if ((wParam+2)==0)
      .switch wParam
        .case ID_FILE_EXIT
          rcall SendMessage,hWnd,WM_CLOSE,0,0
        .case ID_HELP_ABOUT
          invoke DialogBoxParam,hInstance,IDD_DIALOG1,hWnd,ADDR HelpAboutDialog,NULL
      .endsw
    .elseif ((wParam+2)==1)
      mov dx,WORD PTR wParam
      .if dx==ID_FILE_EXIT
        rcall SendMessage,hWnd,WM_CLOSE,0,0
      .elseif  dx==ID_HELP_ABOUT
        rcall SendMessage,hWnd,WM_COMMAND,ID_HELP_ABOUT,0
      .endif
    .else
      nop
  .endif


Petter

[jj2007]

Petter, please read the doc carefully. There is wParam, and there is lParam.
wParam+4 Is lParam in 32-bit code. It Is meaningless in 64-bit code.
What you really want Is
Word ptr wParam
Word ptr wParam+2

[C3]

I have moved from 32-bit MASM mainly to 64-bit MASM. As I have read manuals CPU is byte addressed, so if I can address wParam as I did previously, it works.

EDIT: JJ, you might have a point ;)

[TimoVJL]

Something to read
What happens to WPARAM, LPARAM, and LRESULT when they travel between 32-bit and 64-bit windows?

[C3]

Well this is last post today. Thats how I modified WM_COMMAND to use wParam to choose is the message for Menu, Accelerator or Control-item.

Code Select Expand

.case WM_COMMAND
    .if ((WORD PTR wParam+2)==0)
        .switch wParam
            .case ID_FILE_OPEN
                mov ofn.Flags,OFN_FILEMUSTEXIST or OFN_PATHMUSTEXIST or OFN_LONGNAMES or OFN_EXPLORER or OFN_HIDEREADONLY
                mov ofn.lpstrTitle,ptr$(FileExplorerTitleOpen)
                invoke GetOpenFileName,ADDR ofn
            .case ID_FILE_SAVE
                mov ofn.Flags,OFN_PATHMUSTEXIST or OFN_LONGNAMES or OFN_EXPLORER
                mov ofn.lpstrTitle,ptr$(FileExplorerTitleSave)
                invoke GetSaveFileName,ADDR ofn
            .case ID_FILE_EXIT
                rcall SendMessage,hWnd,WM_CLOSE,0,0
            .case ID_HELP_ABOUT
                invoke DialogBoxParam,hInstance,IDD_DIALOG1,hWnd,ADDR HelpAboutDialog,NULL
        .endsw
    .elseif ((WORD PTR wParam+2)==1)
            mov dx,word ptr wParam
            .if dx==ID_FILE_OPEN
                rcall SendMessage,hWnd,WM_COMMAND,ID_FILE_OPEN,0
            .elseif dx==ID_FILE_SAVE
                rcall SendMessage,hWnd,WM_COMMAND,ID_FILE_SAVE,0
            .elseif dx==ID_FILE_EXIT
                rcall SendMessage,hWnd,WM_CLOSE,0,0
            .elseif dx==ID_HELP_ABOUT
                rcall SendMessage,hWnd,WM_COMMAND,ID_HELP_ABOUT,0
            .endif
    .else
            .if ((WORD PTR wParam+2)==BN_CLICKED)
                mov rax,wParam
                .if (ax==WORD PTR IDC_CUSTOM_BUTTON)
                    invoke MessageBox,hWnd,"TEST","TEST",MB_OK
                .endif
            .endif
    .endif


[NoCforMe]

I think they're talking about Win64 programming, not the OS.

Um 64 bit programs require a 64 bit OS to run.    No sense in writing for 64 bit unless you can also run and test it. 

I was simply pointing out that even if you use a 64-bit OS, you can still program in 32-bit, which is what I do (Win7/64 here). (And it won't cause any of the problems that the OP is experiencing, which have nothing at all to do with the OS and everything to do with misunderstanding 64-bit programming.) I've never used 64-bit MASM, probably never will; to me, it's total overkill for any of the applications I've seen here on this board, apart from a few performance-critical ones.

I'd be interested to know why folks here do use MASM 64. If the answer is "because it's cool" or "because I'm curious about it", that's a plenty good enough reason. But I doubt if many of us actually need to use it ...

[jj2007]

I'd be interested to know why folks here do use MASM 64.

Because "it's the future"

If I were 20 years old, I would jump on the 64-bit train. But I'm 66

Going from 16 to 32 bits was a huge step, with lots of advantages.
Going from 32 to 64 bits allows to address more than 3GB, and that's the one and only advantage. If I ever see a need to address more than 3GB, I might look into 64-bit programming.

[NoCforMe]

Going from 32 to 64 bits allows to address more than 3GB, and that's the one and only advantage.

This bears repeating and remembering.

[jj2007]

But I admit I had some fun when I wrote the jinvoke macro

the traditional "invoke" notation in 32 bit MASM had arg count checking which helped a lot of people catch errors in their code. Traditionally, assemblers never needed such things (real men[tm] etc ....)

Real Men^[tm] know how to write macros that are understood even by ML64:

Code Select Expand

mov hEdit, rv(CreateWindowEx, 0, Chr$("RichEdit20A"), NULL, reStyle, 0, 0, 1, 1, hWnd, ID_EDIT, wcx.hInstance) ; one less
mov hEdit, rv(CreateWindowEx, 0, Chr$("RichEdit20A"), NULL, reStyle, 0, 0, 1, 1, hWnd, ID_EDIT, wcx.hInstance, NULL)
mov hEdit, rv(CreateWindowEx, 0, Chr$("RichEdit20A"), NULL, reStyle, 0, 0, 1, 1, hWnd, ID_EDIT, wcx.hInstance, NULL, 123) ; one more


Code Select Expand

*** Assemble using ml64  ***
Assembling: tmp_file.asm
** 64-bit assembly **
## line 32: not enough arguments for CreateWindowExA ##
## line 34: too many arguments for CreateWindowExA ##

[hutch--]

Why migrate to 64 bit MASM ?

Twice as many registers, massive memory, 64 bit operations, later faster stack design etc etc etc ....

The arguments to stay with 32 bit are the same that was used to stay with 16 bit and before that the arguments to stay with MS-DOS.

32 bit works fine but its not going anywhere but the 16 bit worked fine and it has not gone anywhere for a very long time and as for MS-DOS, are you old enough to remember ? 

[C3]

Go to the 64-bit, there are no reasons not to go. I know, I have started with Commodore 64, then Amiga and then IBM compatibles.

I know its nice to do stuff with DOS and maybe Windows 95. But 64-bit is today and its still tomorrow. It's no such a giant leap for mankind, but its best what you can do today.

[jj2007]

Going from 16 to 32 bits made your code a factor 5-10 faster
Going from 32 to 64 bits makes your code bloated and a bit slower

[hutch--]

> Going from 32 to 64 bits makes your code bloated and a bit slower

Nah, just write it correctly. 

[HSE]

Going from 32 to 64 bits makes your code bloated and a bit slower

Perhaps Wow64 optimize your 32 bit code!