I was doing a lot of extensive tests on the win32 API, I'm not sure but I found one API that's useless:CallWindowProc I found out that instead of pushing parameters and call CallWindowProc you can just use this macro:


_CallWindowProc MACRO oldProc:REQ
pop ebp
mov eax, oldProc
jmp eax
ENDM

or better yet

_CallWindowProc MACRO oldProc:REQ
pop ebp
jmp oldProc
ENDM
oldProc parameter is the value returned when you call SetWindowLong - This might be helpful especially if you have a lot of subclass/superclass window controls. :)


I know some of you might already know this:


pop ebp
jmp DefWindowProc
Posted on 2002-06-07 01:43:23 by stryker
Yes it seems redundant to asm coders.
Still, lots of Windows developers out there don't use asm and therefore they can't just write "jmp" to jmp.
Posted on 2002-06-07 06:44:35 by C.Z.
Yes, and on XP CreateThread is just a function that re-pushes the parameters and calls CreateRemoteThread. Such a waste :)
Posted on 2002-06-07 08:16:19 by Qweerdy



I know some of you might already know this:


pop ebp
jmp DefWindowProc



This works? Nice, must try it at home :)
Posted on 2002-06-07 08:36:41 by bazik
It's better to do things the way MS tells you to do them else suffer the consequences should they ever decide to fiddle with their APIs in a manner that you aren't expecting.

It sucks I know but better to be safe than sorry.
Posted on 2002-06-07 10:04:32 by iblis
By the way, those macros above only works with frame-base procedures.
Posted on 2002-06-07 14:09:58 by stryker

By the way, those macros above only works with frame-base procedures.
:) Without the frame, just jump! :)
Posted on 2002-06-07 14:23:57 by bitRAKE

It's better to do things the way MS tells you to do them else suffer the consequences should they ever decide to fiddle with their APIs in a manner that you aren't expecting.

It sucks I know but better to be safe than sorry.


How come? What stryker wrote is just another implementation of CallWindowProc, functioning exactly the same. Nothing against "the way MS tells you to do".
Posted on 2002-06-07 23:12:42 by C.Z.
Originally posted by bomb01How come? What stryker wrote is just another implementation of CallWindowProc, functioning exactly the same. Nothing against "the way MS tells you to do".


I realize this. It does function exactly the same for now, but what about future versions of Windows?

Also, if you take a look at the SDK you'll see a few interesting things:

"Windows NT/2000/XP: The CallWindowProc function handles Unicode-to-ANSI conversion. You cannot take advantage of this conversion if you call the window procedure directly."

and

"The subclass window procedure must use the CallWindowProc function to call the original window procedure."


I believe there's also an MSDN article about this topic but I don't remember where it is.

Anyways... personally I don't see anything wrong with little shortcuts and work-arounds like this, but you never know what MS will do in the future. If that's a gamble you want to take then that's your prerogative, but if you ever write any commercial software it's not going to be very fair to your faithful users if they upgrade their OS one day and your program doesn't work. You need to ask yourself if that's worth the insignificant few clock cycles you gain by implementing such hacks.

I'm not telling anybody how they should program. I'm merely saying what I think needs to be said.
Posted on 2002-06-08 07:40:25 by iblis
I should have thought of this earlier. Thanks for the correction.:)
Posted on 2002-06-08 08:29:19 by C.Z.
Iblis, I got your point :alright:

::::
I've come to a conclusion that any function on the windows API that repushes the same parameter passed on that procedure is redundant, as of the current state. Well, that's it for now, gotta find more. :grin:
Posted on 2002-06-08 09:42:35 by stryker