64-bit assembly starter kit

[jj2007]

Seven downloads, no feedback? Does that mean it works fine for everybody???

[jj2007]

Here is a dual 64/32-bit assembly example that does indeed require one line of conditional assembly:

Code: [Select]

if @64
mov opEdit, rv(SetWindowLongPtrW, rbx, GWL_WNDPROC, SubEdit)
else
mov opEdit, rv(SetWindowLongW, rbx, GWL_WNDPROC, SubEdit)
endif
Source attached, builds as 64- or 32-bit code with ML64/ML, HJWasm and AsmC. Requires the standard Masm32 package and current MasmBasic, no further libraries needed.

P.S.: Here is the subclass proc - it looks a bit messy because ML64 has no native switch command:

Code: [Select]

SubEdit proc <cb> hwnd:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
  cmp uMsg, WM_KEYDOWN
  jne @F
  cmp wParam, VK_ESCAPE ; close the app if user hits Escape
  jne @Endswitch
  jinvoke SendMessage, rv(GetParent, hwnd), WM_CLOSE, 0, 0
  jmp @Endswitch
@@:
  cmp uMsg, WM_CHAR
  jne @Endswitch
  cmp wParam, "e"
  jne @Endswitch
  mov wParam, "E"
@Endswitch:
  jinvoke CallWindowProcW, opEdit, hwnd, uMsg, wParam, lParam
  ret
SubEdit endp

[hutch--]

This is the advantage of a non configured assembler like ML64, as its a MACRO assembler, use a "switch" macro. 

    .switch uMsg
      .case WM_INITDIALOG
      ; ------------------------------------------------------
      ; lParam is the icon handle passed from DialogBoxParam()
      ; ------------------------------------------------------
        invoke SendMessage,hWin,WM_SETICON,1,lParam     ; set the icon for the dialog
        invoke SendMessage,rv(GetDlgItem,hWin,102), \   ; set the icon in the client area
               STM_SETIMAGE,IMAGE_ICON,lParam
        invoke SetWindowText,hWin,"Create Base Dialog Template"
        .return TRUE

      .case WM_COMMAND
        .switch wParam
          .case 101
            jmp exit_dialog             ; The OK button

          .case 102
            invoke MessageBox,hWin,"Create Project","dlgmake",MB_OK

          .case 103
            invoke MessageBox,hWin,"Build Project","dlgmake",MB_OK

          .case 104
            invoke MessageBox,hWin,"Test Project","dlgmake",MB_OK

          .case 105
            invoke MessageBox,hWin,"Get target","dlgmake",MB_OK

        .endsw

      .case WM_CLOSE
        exit_dialog:
        invoke EndDialog,hWin,0         ; exit from system menu
    .endsw

Pure, clean simple MASM code.  :P

[jj2007]

This is the advantage of a non configured assembler like ML64, as its a MACRO assembler, use a "switch" macro. 

We've discussed that already in the CrippleWare thread. You won't convince me to write .if eax {= ecx :(

[hutch--]

 

The problem is that your view on ML64 is crippled, however you may wish to misrepresent it, its up and going, has full libraries and includes, is backed by Microsoft who need it themselves and its not trying to be a backdoor C compiler. No weird syntax, no C typedefed data types, hex in MASM notation and just clean fast 64 bit assembler. All of the joys of a true MACRO assembler without the C yukkies.  :P

[rrr314159]

Plus it's got no bugs, but plenty of cool features I don't understand! Doesn't get any better than that.

You're right about one thing: it's not trying to be C or C++. Assemblers should be proud to be assemblers.

Bumper Sticker ideas: "ML64 coders push and pop all night long" "Invoke this, HJWasm coders!"

[nidud]

deleted

[hutch--]

 

> Plus it's got no bugs, but plenty of cool features I don't understand! Doesn't get any better than that.

Of course it has no bugs and very advanced error reporting, the only weakness is the (ab)user so it has highly advanced error reporting (multiple screens of chyte) to ensure that the (ab)user fully understands that there is an error in the code. They then have to master decrypting the multiple screens of chyte without anyone holding their hot little hand.

Now translate this into what its purpose is, a boiler room industrial tool for crunching mnemonics that the (ab)user is supposed to know how to use that will bite them on the hand if they get it wrong. Now the macro engine is something else, a dinosaur from the 1990 version of ML.EXE that has survived from 16 to 32 and now 64 bit, bugz 'n all (whoops I mean features) so if you could write macros in 1990, you still know how to use the ML64 macro engine.

I am personally a fan of "suicide" coding in that it very quickly teaches you to get it right the first time or it will explode in your face. SEH and the like are for the limp of wrist, the idea is write error free code in the first place and with practice, become efficient at it.

[rrr314159]

SEH and the like are for the limp of wrist, the idea is write error free code in the first place ...

Sure.

[hutch--]

rrr,

You don't sound altogether convinced.  ::)

[jj2007]

SEH and the like are for the limp of wrist, the idea is write error free code in the first place

I've implemented SEH in my package (as Try/Catch/Finally), but I rarely use it. When official Microsoft software confronts the end user with "error 0x8000c0005", it's usually a clear indication that the only thing that they still control and understand in their pile of shyte is the exception handler :P

[hutch--]

> I've implemented SEH in my package (as Try/Catch/Finally)

My condolences.  :P

[rrr314159]

SEH and the like are for the limp of wrist, the idea is write error free code in the first place ...

Sure.

rrr, You don't sound altogether convinced.  ::)

If my response was lukewarm, it was only because the statement's so obviously true. "Suicide code" is the right idea. If it's going to blow up I want it to do it now, so I can fix it. Not hide the error during development so later on it can explode in the user's face with some completely useless error code. What good is that?

[jj2007]

I am a great fan of "suicide code". Problem is that with growing complexity of a project (teams of ten developers, millions of lines, ...), and exposure to the Dumbest Imaginable User, the likeliness of totally exceptional exceptions is growing exponentially. It is thus understandable that the C/C++ fraction likes installing SEH by default. Still, I don't think it's a good strategy, since the root cause is that they lost control over a complex project, and therefore the handler may not really "handle" correctly the situation.

In my own tiny projects (RichMasm: 18k lines) I don't use SEH. But I do take care that no files are ever open for more than a second, and that backup text is being saved to disk if a) doc is dirty and b) the editor is idle for more than x seconds. With these precautions, suicide code is fine. No damage possible.

[hutch--]

There are approaches that beat the sloppy code of late, true tested modular coding where each component is bashed to death until there is nothing wrong with it and it performs correctly to its specification. This of course must be backed up by documentation so its specification is known. Objects are made of components and if the components are proven and reliable, then the object is reliable if its constructed properly.

Abstraction as a matter of style is the enemy here, objects that are poorly understood and often poorly written fail without a direct solution to fix them. The real problem is the quality of idiot is so high that nothing can be made idiot proof and thus, the approach of suicide code, if it fails at the modular level, it never reaches the object level and cannot be messed up by a hick. At the module level it can be fixed and here I am a fan of post mortem debugging where you know exactly where something crashed and why.

My main use of a source code debugger is the disassembly, ArkDasm was indispensable while researching Win64 and what capacity ML64 had.