In any of the sample programs in the win32asm package, try replacing these two instructions: invoke DefWindowProc,hWin,uMsg,wParam,lParam ret with these two: pop ebp jmp DefWindowProc Voila! No need to push the message structure that is already on the stack!
Posted on 2001-05-24 14:50:00 by Larry Hammick
Larry, this is a very good observation ! this is very interesting ... but this trick is sure ? (i intend it work always?, on all 95,98,NT ?)
Posted on 2001-05-24 16:54:00 by angelo
Of course it works on all versions. The calling convention is standardized. Your window proc will always receive those arguments on the stack, in order, and DefWindowProc will always require its arguments be placed on the stack, in order. If this weren't the case, you couldn't write programs in C that always operate on all the Windows versions.
Posted on 2001-05-25 00:09:00 by tank
I don't see how it could fail on any version. This sort of manoeuvre is what I like about asm: it frees us from "good programming practice" such as block-structuring. The same principle comes up in DOS and BIOS programming: a near call should never be followed immediately by a near return. But during development it might be better to use call/ret so that the code is easier to trace with a debugger. Angelo, that is a pretty quotation "obsequium..." Is it your own, or from one of the ancients?
Posted on 2001-05-25 03:51:00 by Larry Hammick
The same move seems to be applicable to the other default message handlers: DefDlgProc DefFrameProc DefHookProc DefMDIChildProc DefScreenSaverProc
Posted on 2001-05-26 07:52:00 by Larry Hammick
Just be careful with what you do with callback functions in the return value, DefWindowProc() is among other things an interface for processing things like WM_NC#### messages. 4 pushes and a call are no big deal in code terms but you risk losing the capacity to control things like return values from messages with non standard callback functions.

    invoke DefWindowProc,hWin,uMsg,wParam,lParam

WM_CTRLCOLOR#### messages must return the color so make sure all of these things work correctly or you will pick up 10 or 12 bytes size savings for unreliable peformance. Regards,
Posted on 2001-05-26 08:44:00 by hutch--
True, hutch, but in fairly simple cases this move should save a lot of mips, e.g. in the common case of an unprocessed wm_mousemove. Whether these mips actually count (in a polling situation such as a message loop) I am uncertain. Betov thinks not.
Posted on 2001-05-28 14:06:00 by Larry Hammick
The optimization will add zip to slower processors, especially in cases where there is a cascade of messages. Example of cascading messages: the messages generated by CreateWindowEx. As everyone upgrades to faster processors, the added zip gets less and less.
Posted on 2001-05-29 20:44:00 by tank