The MASM Forum

Hi,

With MASM64 the elseif macro contents (that MessageBox call) doesn't get executed it skips to the next Window Message.

.case WM_COMMAND
.if ((wParam+4)==0)
.switch wParam
          .case ID_FILE_OPEN
.case ID_FILE_SAVE
.case ID_FILE_EXIT
rcall SendMessage,hWnd,WM_CLOSE,0,0
.case ID_EDIT_CUT
.case ID_EDIT_COPY
.case ID_EDIT_PASTE
.case ID_HELP_ABOUT
invoke DialogBoxParam,hInstance,IDD_DIALOG1,hWnd,ADDR HelpAboutDialog,NULL
.endsw
.elseif ((wParam+4)==1)
invoke MessageBox,hWnd,"TEST","TEST",MB_OK
.else
nop
.endif


Petter

Hate to ask you this, but did you confirm what the value of [wParam+4] actually was at that point?

If so, then sorry, can't help you here.

Any good reason why you call it (wParam+4) instead of lParam?

  mov eax, lParam
  mov ebx, wParam+4
  mov ecx, wParam[4]
  mov edx, [wParam+4]

Disassembly:
  mov eax, [ebp+14]
  mov ebx, [ebp+14]
  mov ecx, [ebp+14]
  mov edx, [ebp+14]

You also don't need brackets all over the place. This is Assembly, not C/C++

.if ((wParam+4)==0)

.if lParam==0   ; make it readable

Hi Petter,

I tried to test what you have posted but I don't have all of the constants in the .if block.

Declutter the code as JJ mentioned and also remove redundant code,

         .case ID_EDIT_CUT
         .case ID_EDIT_COPY
         .case ID_EDIT_PASTE
         .case ID_HELP_ABOUT

that is not being used.

There does not seem to be any reason for the"wParam+4". Win64 does not work like Win32, stack variables are aligned at 8 bytes, not 4 and by using the names of variables in the 1st 4 args, you are using "shadow space".

For testing purposes, try using the normal "wParam" and "lParam" and you will get the correct arguments to test for a WndProc.

Attached is a simple test piece for testing the ".if" block notation.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm64\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    LOCAL num1  :QWORD
    LOCAL num2  :QWORD
    LOCAL num3  :QWORD
    LOCAL num4  :QWORD

    mov num1, 1
    mov num2, 2
    mov num3, 3
    mov num4, 4

    invoke test_num,num4
    invoke test_num,num3
    invoke test_num,num2
    invoke test_num,num1

    invoke MessageBox,0,"Thats all folks","Arrrrgh",MB_OK

    .exit

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

test_num proc arg:QWORD

    .if arg == 1
      invoke MessageBox,0,str$(arg),"Option 1",MB_OK

    .elseif arg == 2
      invoke MessageBox,0,str$(arg),"Option 2",MB_OK

    .elseif arg == 3
      invoke MessageBox,0,str$(arg),"Option 3",MB_OK

    .elseif arg == 4
      invoke MessageBox,0,str$(arg),"Option 4",MB_OK

    .else
      invoke MessageBox,0,"Number out of range","Whoops",MB_OK

    .endif

    ret

test_num endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end

Quote from: hutch-- on October 22, 2022, 09:45:12 AMThere does not seem to be any reason for the"wParam+4". Win64 does not work like Win32, stack variables are aligned at 8 bytes, not 4

Of course... I had not thought of that, thanks Hutch. So with wParam+4 Petter gets the high DWORD of wParam, instead of the low DWORD of lParam that he presumably wants to know.

Unless what they want is the high DWORD of wParam. We still don't know.

 :biggrin:

Depending on your sense of humour, the high DWORD of wParam in 64 bit Windows is always empty as the 64 bit value passed is only ever in DWORD range. Win64 is still a hybrid that uses a lot of 32 bit code. If you have to load a variable in both low DWORD and high DWORD, it has to be done via a 64 bit register. Its a quirk of Win64.

I just found a strange quirk that I had never seen before. With the .switch macro, if you don't have at least 1 local in the proc, it fails to recognise a single argument. You can also load num1 into a register before the switch block,

mov r11, num1


Or you can use 4 or more stack arguments. Win64 tends to have a few surprises.


; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

switchtst proc num1:QWORD

    LOCAL empty :QWORD

    .switch num1
      .case 0
        invoke MessageBox,0,str$(num1),"0",MB_OK

      .case 1
        invoke MessageBox,0,str$(num1),"1",MB_OK

      .case 2
        invoke MessageBox,0,str$(num1),"2",MB_OK

    .endsw

    ret

switchtst endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

Quote from: hutch-- on October 22, 2022, 12:49:47 PMWin64 tends to have a few surprises.

Hence, my reluctance to .switch (pun intended  :tongue: ) from Windows 7 32 bit to 64 full time.   :biggrin:

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

Quote from: NoCforMe on October 22, 2022, 05:03:09 PM
I think they're talking about Win64 programming, not the OS.

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

Quote from: hutch-- on October 22, 2022, 12:49:47 PMWin64 tends to have a few surprises.

Win64 or Vassily?

Hello,

The problem is with the Keyboard Accelerators. I have done the resources and LoadAccelerators and put TranslateAccelerator to message loop.
I re-wrote the WM_COMMAND to do logic with the wParam, not lParam. The first .if checks is the message for Menu and .ifelse is the message for Accelerator, .else would be Control-defined notification code, as Windows API Documents the WM_COMMAND.

I was lazy at night when I posted the code. I have tried use the register and shift the register to get Accelerator Key to work. Messages for the Menu pass on, but messages for Accelerators execute only to the .ifelse, not to the what I expect it do for after compare.

Have to do some testing.

EDIT: I have maybe tought WM_COMMAND wrong, as the API Docs say there is wParam high word and wParam low word. I was using wParam as 64bit but docs point to use that as 32bit.

Petter

Quote from: hutch-- on October 22, 2022, 12:49:47 PMWith the .switch macro, if you don't have at least 1 local in the proc, it fails to recognise a single argument.

I recommend .switching the macro :cool:

include \Masm32\MasmBasic\Res\JBasic.inc ; ## console demo, builds in 32- or 64-bit mode with UAsm, ML, AsmC ##
.code
switchtst proc num1:QWORD
; LOCAL empty :QWORD ; works fine, with and without a local
    Switch_ num1
      Case_ 100
        jinvoke MessageBox, 0, Str$("Result=%i", num1), Chr$("Expected: 100"), MB_OK
      Case_ 101
        jinvoke MessageBox, 0, Str$("Result=%i", num1), Chr$("Expected: 101"), MB_OK
      Case_ 102
        jinvoke MessageBox, 0, Str$("Result=%i", num1), Chr$("Expected: 102"), MB_OK
    Endsw_
    ret
switchtst endp
Init ; OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
  PrintLine Chr$("This program was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format.")
  jinvoke switchtst, 100
  jinvoke switchtst, 101
  jinvoke switchtst, 102
EndOfCode

Output:
This program was assembled with ml64 in 64-bit format.
(plus three correct MessageBoxes)

Its tuff when you build at 1.5k.  :biggrin:

The .switch macro is usually only used in higher level code that uses LOCAL variables but there are a number of options.

1. LOCAL anyvar :QWORD
2. mov r15, r15  :Any reg will do
3. switchtst proc num1:QWORD,dummy1:QWORD,dummy2:QWORD,dummy3:QWORD
4. Put it after any code.
        mov rax, 16
      lbl:
        sub rax, 1
        jnz lbl

I may track it down one day but in most contexts it does not matter. It may be that the macro should not be the first code run in a standard stack frame procedure. Anywhere else and it works correctly.

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

    include \masm64\include64\masm64rt.inc

    .code

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

entry_point proc

    rcall switchtst,0
    rcall switchtst,1
    rcall switchtst,2

    .exit

entry_point endp

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

switchtst proc num1:QWORD           ; ,dummy1:QWORD,dummy2:QWORD,dummy3:QWORD

    ; LOCAL dummy :QWORD

    ; mov r15, r15

    mov rax, 16
  lbl:
    sub rax, 1
    jnz lbl

    .switch num1
      .case 0
        rcall MessageBox,0,str$(num1),"Zero",MB_OK

      .case 1
        rcall MessageBox,0,str$(num1),"One",MB_OK

      .case 2
        rcall MessageBox,0,str$(num1),"Two",MB_OK

    .endsw

    ret

switchtst endp

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

    end

 :biggrin:

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

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

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.

  .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

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

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 ;)

Something to read
What happens to WPARAM, LPARAM, and LRESULT when they travel between 32-bit and 64-bit windows? (https://devblogs.microsoft.com/oldnewthing/20110629-00/?p=10303)

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.

.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


Quote from: zedd151 on October 22, 2022, 05:38:37 PM

Quote from: NoCforMe on October 22, 2022, 05:03:09 PM
I think they're talking about Win64 programming, not the OS.

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

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 ...

Quote from: NoCforMe on October 23, 2022, 07:32:50 AMI'd be interested to know why folks here do use MASM 64.

Because "it's the future" :cool:

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

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.

Quote from: jj2007 on October 23, 2022, 08:22:24 AM
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.

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

Quote from: jj2007 on September 12, 2022, 06:39:55 PM

Quote from: hutch-- on September 12, 2022, 11:50:59 AMthe 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 ##

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 ?  :tongue:

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.

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

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

Nah, just write it correctly.  :biggrin:

Quote from: jj2007 on October 24, 2022, 02:54:12 AM
Going from 32 to 64 bits makes your code bloated and a bit slower :sad:

:biggrin: Perhaps Wow64 optimize your 32 bit code!

There is yet another advantage in 64 bit architecture, with so many registers, the only time you need LOCAL values is if a function needs to have a memory address to put data into on its return. You save on the stack overhead by working directly with registers.

From long ago when I still wrote MS-DOS code, I could generally get faster algorithms than 16 bit Windows but you still had the same limitations in DOS, small memory, less instructions and the limitations of memory models.

Quote from: hutch-- on October 24, 2022, 08:31:06 AMI could generally get faster algorithms than 16 bit Windows but you still had the same limitations in DOS, small memory, less instructions and the limitations of memory models.

That's true: 32-bit code is about a factor 5-10 faster than 16-bit code; and it can address over 3,000 times more memory than 16-bit with its 640k limitation. Going from 16- to 32-bit code was really a good idea :thumbsup:

Quote from: HSE on October 24, 2022, 07:56:27 AM
:biggrin: Perhaps Wow64 optimize your 32 bit code!

I know you were somewhat joking, but let me be serious just for a few seconds here:  What 64-bit parts of the OS (functions) would it be beneficial for a 32-bit program to call? that would actually make a difference in execution speed? (I assume that's the only possible benefit here, not smaller code size or reduced complexity).

Quote from: NoCforMe on October 24, 2022, 10:51:19 AMWhat 64-bit parts of the OS (functions) would it be beneficial for a 32-bit program to call? that would actually make a difference in execution speed?

That's actually a good question. Theory (https://en.wikipedia.org/wiki/WoW64#Translation_libraries) says that Wow64 takes your 32-bit file handle, sign-extends it to a 64-bit handle and then asks The Real 64-bit Thing^TM to do the WriteFile for you, in 64-bit land.

In practice, I see that rarely happen in my debugger, and that is strange. But I know it does happen, because occasionally I've seen it.

Speed is not the reason (64-bit code is roughly as fast as 32-bit code. But it makes sense that Windows keeps running only one 64-bit kernel, instead of having two parallel systems.

Any gurus around who can explain that better than me?

Quote from: NoCforMe on October 24, 2022, 10:51:19 AM
I know you were somewhat joking,

Not exactly, but I don't remember article author.

Any code non optimal can be optimized. It's bitness independent. But Wow64 must modify your 32 bits
code, and nothing it's going to modify your 64 bit code.

Quote from: HSE on October 24, 2022, 11:12:15 AMWow64 must modify your 32 bits
code

It does not modify your code, it provides thunking interfaces.

QuoteOn the x64 processor, x86 instructions are executed natively by the processor. (https://learn.microsoft.com/en-us/windows/win32/winprog64/performance-and-memory-consumption)

Yes, that it's the explanation for users.

Quote from: jj2007 on October 24, 2022, 11:14:52 AM
On the x64 processor, x86 instructions are executed natively by the processor. (https://learn.microsoft.com/en-us/windows/win32/winprog64/performance-and-memory-consumption)

Yes, which is why I'm completely comfortable writing "only" 32-bit code, no matter how old-school or out-of-date it may seem to others. I really don't feel like I'm missing anything because of this.

Quote from: HSE on October 24, 2022, 11:52:59 AM
Yes, that it's the explanation for users.

So you mean I am too dumb to understand it? Please, my guru, explain to a mere mortal how exactly Wow64 does "modify your code". I will make a huge effort to understand it.

Quote from: jj2007 on October 24, 2022, 08:13:35 PM
So you mean I am too dumb to understand it?

:biggrin: I think the better definition is that"WoW64 is partially documented".

Details are complex, boring, and probably against forum rules
  :thumbsup:

Come on, don't be shy: we are all waiting for your expertise, Hector :thumbsup:

I am also sure that Hutch wants to know how Wow64 modifies his Masm32 SDK code. This is fascinating, Hector, but we are too dumb to understand it. Pleaaaaaaaaze explain it to us :thup: :thup: :thup:

 :biggrin: You are the "search" expert. I'm pretty sure sure you will find the way.

And you can learn more about HyperVisors, and explain a little. (Because look like a waste of time).

Quote from: HSE on October 24, 2022, 11:12:15 AMWow64 must modify your 32 bits code

What a pity, Hector, that you don't want to share your wisdom with us. I have always been fascinated by self-modifying code (it's so much fun to watch in the debugger), but now there is Wow64 that does the modification for you. Absolutely Wow :thumbsup:

 :biggrin:  :biggrin: :biggrin: No self modification. Debugger is useless. Just search and read.   :thumbsup:

Quote from: HSE on October 24, 2022, 11:12:15 AMWow64 must modify your 32 bits code

Quote from: HSE on October 24, 2022, 10:31:35 PM
:biggrin:  :biggrin: :biggrin: No self modification.

Thank you for clarifying :thumbsup:

 :biggrin:

> Debugger is useless. Just search and read

I have to agree with that comment, long ago there was CodeView in the MASM version 6.0 package and it was a joy to use if you wrote code like the debugger output but over time Microsoft have kept crippling the capacity to use debuggers, mainly for security reasons, and they have become harder to use and more or less toothless in their capacity.

The absolute "bees knees, walk on water" debugger was SoftIce and the crackers truly loved it so NuMega eventually pulled it and Microsoft kept adding more and more security measures to cripple high powered debuggers.

Now a disassembler is another matter, if you have the right toys, you can find you way around a compiled binary reasonably easily but Microsoft have an approach for that as well, the Microsoft Store where anything that you install on your computer gets buried so deep in the quagmire that you cant find it.

But ... you didn't mention Olly Debug. What do you think of that?

I have a few problems with it, the main one being the difficulty of examining local & stack variables, but overall I find it to be a pretty damn useful tool. (But then I've got nothing to compare it to.)

Quote from: NoCforMe on October 25, 2022, 09:16:32 AM
But ... you didn't mention Olly Debug. What do you think of that?

The alternatives are worse.
- WinDbg is a line-oriented debugger, you never know where you are. It's just plain horrible.
- x64Dbg: https://lifeinhex.com/x64dbg-2-years-later/ (it looks like an OllyDbg clone, but has many problems)

I use OllyDbg 2.0 (http://www.ollydbg.de/version2.html) a lot, but then, I use the deb macro (http://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1019) ten times more. Any debugger is a last resort when you really have tried all the other options.

Quote from: hutch-- on October 25, 2022, 08:57:03 AM
I have to agree with that comment, long ago there was ...

:thumbsup:  That is a piece of the problem, because to see what is executed from a 32 bit program you have to debug the WoW, and M$ don't like that. Other piece is that WoW can split the 32 bit program into multiple threads. And finally, look like WoW is very integrated with the system, then you have to see what OS is making to obtain the full picture  (debuggers run in OS, then can't see the OS)

A lot of complications to test if a limited program can be faster than a more complete program, I think  :biggrin:

Back in the XP days, you could set it up in DrWatson so that a crash would tell you exactly where it crashed down to a listing of instructions. I found it incredibly useful but it disappeared in later Windows versions so my current technique (apart from message Boxes) is a memory mapped file tool called Livedb that you send any data you like to and if the app crashes, LiveDB displays the last line before it crashed.

I don't like current debuggers. I have used Arkdasm and you can get it to step through code but its main use was as a disassembler. I find current debuggers slow and painful.

Quote from: hutch-- on October 25, 2022, 01:00:06 PM
Back in the XP days, you could set it up in DrWatson so that a crash would tell you exactly where it crashed down to a listing of instructions ... I find current debuggers slow and painful.

I've set Olly as JIT debugger for 32-bit code, and x64Dbg for 64 bits. That works just fine for the occasional crash.

First I write asm proc and use vc debugger to single-step if necessary to get it to work properly, don't know what it's called
To get the right Shuffle or unpack or pack or new right avx2 mnemonics
I tried one disasm once to retrieve my lost source code invain, found out it didn't support SSE

Quote from: daydreamer on October 25, 2022, 10:06:04 PM
I tried one disasm once to retrieve my lost source code invain, found out it didn't support SSE

Zydis follow time
https://github.com/zyantific/zydis

EDIT:
Online hex code disasm
https://zydis.re/

Quote from: daydreamer on October 25, 2022, 10:06:04 PMI tried one disasm once to retrieve my lost source code invain, found out it didn't support SSE

Olly supports at least SSE 4.2:
pcmpistri xmm2, [eax], 0C
pcmpistrm xmm3, xmm1, 58
pcmpeqb xmm0, [edx]
pmovmskb eax, xmm0