Message Cracker Macros for MASM

[gwapo]

Hi all,

I assume that most of you in this forum know already what a Message Cracker is, so I don't want to bore you with lengthly explanation about what is a Message Cracker. Specially, if you're a Win32 GUI programmer using Visual C++, you probably used WindowsX.h header file in your GUI application, which is the VC++'s Message Cracker implementation.

Attached is my implementation for MASM using macros.

I'm also aware that there are debates about the pros and cons of Message Crackers, but most of Win32 programmers I know are in favor of using Message Crackers, and so am I.

Since I can't find a Message Cracker implementation in MASM, I decided to create one, and here's the result. I hope you may find it useful. The attached ZIP file has the MsgCrack.inc include file, and a test project for WinAsm Studio, it's a GUI program testing commonly used window messages.

I included instruction on how to use the include file for your program, and comment for each WM_<name> for what are the expected parameters your message handler procedure will be needing in declaration. I'm currently working on a wizard program for this include file to make ease in using Message Cracker for MASM.

Note: Not all are tested, so if you found something wrong, please post it here. I don't claim to be an expert in window messages, so if you have question about specific window message, please don't ask me. This implementation are created mostly by converting Visual C++'s WindowsX.h header file, so I can't guarantee that every handling of WM are accurate.

Thanks,

-chris

[attachment deleted by admin]

[six_L]

 :U
wonderful

[hutch--]

Compliments Chris,

You have done a lot of work here.

For your information, if you look in the masm32 example code, you will find a very high speed message dispatcher in the subdirectory "type2" that uses a preloaded jump table done at startup that branches to each message handling procedure with a very low instruction count. A conventional WndProc has a lower overhead when using a jump table of this type and this is shown in "type1" of the example code but for programmers who want to use seperate procedure for processing each message, the "type2" example is hard to beat for speed.

[lingo]

"..you will find a very high speed message dispatcher.."

If someone is "Win32 GUI programmer using Visual C++",
probably he can't see the difference  :lol

Why?
Because he is able and will try to implement his C++ "knowledge" in assembly
For example: Message Cracker
As a result every modern C/C++ compiler will generate better code

What to do?
Every programmer MUST read modern books
For instance: "Software Optimization Guide for AMD64 Processors"

Regards,
Lingo

[Mark Jones]

Hmm, I thought finally I had found the cleanest WndProc code with this. Close, anyways. Back to the drawing board. :)

Code Select Expand


DlgProc proc hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
    mov eax,uMsg
   
    .if eax==WM_INITDIALOG
       
    .elseif eax==WM_COMMAND
        mov eax,wParam                              ; wParam = (condition:control id)
        mov ecx,eax                                 ; ax = control id
        shl ecx,16                                  ; cx = condition
        .if ax==1003 && cx==BN_CLICKED              ; find button AND clicked?
            call DoSearch
        .elseif ax==1009 && cx==BN_CLICKED          ; edit button?
            call EditFile
        .elseif ax==10002                           ; launch options dialog as child
            invoke DialogBoxParam,hInstance,1100,hWnd,addr OptionsDlgProc,0
        .elseif ax==10003                           ; exit menu
            invoke SendMessage,hWnd,WM_CLOSE,0,0
        .elseif ax==10005                           ; about menu
            invoke ShellAbout,hWnd,addr szTitle,addr szAboutMsg,0
        .endif
       
    .elseif eax==WM_CLOSE
        invoke EndDialog,hWnd,0
    .elseif eax==WM_DESTROY
        invoke PostQuitMessage,0
       
    .else
        mov eax,0                                   ; message not handled flag,
        ret                                         ; pass to default msg handler
    .endif
    mov eax,1                                       ; messsage handled flag, do
    ret                                             ; not pass to default msg hdlr
DlgProc endp


[Vortex]

Very nice work :U

[lingo]

If we use "pure" assembly  :lol
WndProc probably will look like this:

Code Select Expand

WndProc:
mov eax, [esp+2*4] ; eax=uMsg param
cmp eax, bigMess ; bigMess = message with
sbb ecx, ecx ; the biggest number +1
and eax, ecx ; The dword ptr [400000h] is a
jmp dword ptr [400000h+eax*4]; pointer to DefWindowProc
; or If uMsg >= bigMess then   DefWindowProc
; 400000h == is 1st address of program offsets table
Regards,
Lingo   

[gwapo]

Thanks for the replies :)

For your information, if you look in the masm32 example code, you will find a very high speed message dispatcher in the subdirectory "type2" that uses a preloaded jump table done at startup that branches to each message handling procedure with a very low instruction count. A conventional WndProc has a lower overhead when using a jump table of this type and this is shown in "type1" of the example code but for programmers who want to use seperate procedure for processing each message, the "type2" example is hard to beat for speed.

My search-engine missed "Type2" message dispatcher, probably because I haven't actually looked at the examples yet  :P

Back in my TASM days, I was using a message dispatcher similar to "Type2" in which I find it convinient both in readability and speed. Then, I moved to C++ as a game developer, leaving all my experiences in TASM behind. About speed, if we look at machines production of today, speed-gain is no longer a big issue, companies (especially in game dev industry) favor more on readability and maintainability of codes rather than hunting for nanoseconds while only "few" programmer would understand those high-speed codes.  I remember, countless times I proposed high-speed codes in the company I am working, but countless times it was denied; from this countless denials, I realized that making code as easy to maintain by other programmers is better that trying to grab all the speed the machines can offer.

Anyway, back to the topic, I was looking at how to implement "Type2" style in Message Crackers, but still, there's a need to extract the parameters needed so I can pass it to the handler procedure without it worrying about extracting wParam/lParam. I find .if/.elseif/.endif block as a good choice, because there will be a chance that you may want to continue processing a message after the call to message handler:

Code Select Expand


  .if eax == WM_INITDIALOG
        push lParam
        push wParam
        call OnInitializeDialog
        .if eax != INIT_SUCCESSFUL
             invoke PostQuitMessage, hWnd
        .endif
  .elseif eax == WM_CLOSE
        invoke PostQuitMessage, hWnd
  .endif


The code above can be implemented with a Message Cracker easily, but with a jump table, executing additional code after the branching to handler routine would be difficult.

If someone is "Win32 GUI programmer using Visual C++",
probably he can't see the difference

Actually, I started in TASM, but get used to the VC++ ways since it is my job. I don't know what took me so long to return to assembly programming. Well probably because I consider assembly programming more as a challenging-hobby than a career :)



Cheers,

-chris

[PBrennick]

Actually,
For me, assembly was a career and over a span of 2 decades I literally made millions of dollars and even though I am retiired, now, my company is still out there and only programs in assembly (low level) for use in high risk areas that I can't go into but where code maintainability by anyone outside the company is absolutely NOT an option and would problably kill the business.

Paul

[BogdanOntanu]

Paul,

Maybe I should apply for a job at your company... I would really love an full time ASM job...
Do not tell them but I guess I would work for less just to be allowed to do it in ASM ;)

Honestly I also have a job that involves ASM now -- in security area --
I do not code in ASM but I do have to read/ use ASM all day long...

So may ASM knowledge was a key factor in securing this job.

[zcoder]

securing a job with asm???

No way, I once wrote a small program to scan
a print out of keyboard key tests and flag any.
that failed the test.

We used it for a month and production was higher
and the waste was way less, but when the top
found out we was using it they told us to remove
the program cuz it was not part of the procedure.

Then production fell down again.

instead they want the person to do the tests
print it out and in their head look at 101 listings
to see if the high level or low level fell below 5%
for each key.

do that all day long in your head, and you will fail
at times.

companys are just to big and stupid.


Zcoder....