Why do member functions need to be “static” to be used as a callback?

Date:January 9, 2004 / year-entry #11
Tags:history
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20040109-00/?p=41133
Comments:    17
Summary:As we learned yesterday, nonstatic member functions take a secret "this" parameter, which makes them incompatible with the function signature required by Win32 callbacks. Fortunately, nearly all callbacks provide some way of providing context. You can shove the "this" pointer into the context so you can reconstruct the source object. Here's an example: class SomeClass...

As we learned yesterday, nonstatic member functions take a secret "this" parameter, which makes them incompatible with the function signature required by Win32 callbacks. Fortunately, nearly all callbacks provide some way of providing context. You can shove the "this" pointer into the context so you can reconstruct the source object. Here's an example:

class SomeClass {
 ...
 static DWORD CALLBACK s_ThreadProc(LPVOID lpParameter)
 {
  return ((SomeClass*)lpParameter)->ThreadProc();
 }
 DWORD ThreadProc()
 {
  ... fun stuff ...
 }
};

Some callback function signatures place the context parameter (also known as "reference data") as the first parameter. How convenient, for the secret "this" parameter is also the first parameter. Looking at the various calling conventions available to us, it sure looks like the __stdcall calling convention for member functions matches our desired stack layout rather well. Let's take WAITORTIMERCALLBACK for example:

__stdcall callback __stdcall method call thiscall method call
.. rest of stack .. .. rest of stack .. .. rest of stack ..
TimerOrWaitFired TimerOrWaitFired TimerOrWaitFired <- ESP
lpParameter <- ESP this <- ESP

Well, "thiscall" doesn't match, but the two "__stdcall"s do. Fortunately the compiler is smart enough to recognize this and can optimize the s_ThreadProc static method to nothing if you just give it enough of a nudge:

class SomeClass {
 ...
 static DWORD CALLBACK s_ThreadProc(LPVOID lpParameter)
 {
  return ((SomeClass*)lpParameter)->ThreadProc();
 }
 DWORD __stdcall ThreadProc()
 {
  ... fun stuff ...
 }
};

If you look at the code generation for the s_ThreadProc function, you'll see that has been reduced to nothing but a jump instruction, since the compiler has realized that the two calling conventions coincide here so there is no actual translation to do. 

?s_ThreadProc@SomeClass@@SGKPAX@Z PROC NEAR
  jmp     ?ThreadProc@SomeClass@@QAGKXZ
?s_ThreadProc@SomeClass@@SGKPAX@Z ENDP

Now some people would take this one step further and just cast the second parameter to CreateThread to LPTHREAD_START_ROUTINE and get rid of the helper s_ThreadProc function entirely. I strongly advise against this. I have seen too many people cause trouble by miscasting function pointers; more on this in a future entry.

Although we took advantage above of a coincidence between the two __stdcall calling conventions, we did not rely on it. If the coincidence in calling conventions fails to occur, the code is still correct. This is important when it comes time to port this code to another architecture, one where the coincidence may longer be true!

Comments (17)
  1. Doug says:
    January 9, 2004 at 9:23 am

    I would smack any fool around that tried to depend on how the assembly works. Just BEGGING for trouble.

    The good thing is, there are now very, very few programmers who understand assembly to this level, and they are all old enough to know better. Or one would hope.

    Grin.

    Now, passing a non-static member function in for a callback, I’ve seen fools try that. But it never makes it out of programmer testing, because nothing works…..

    (Duh, why am I getting a visit from the Doctor?)

    Course, passing objects in WM_ type stuff can cause other problems with deleted objects. Those can get amusing to prevent.

    What if there is already a message in the queue with that object reference as an LPARAM when you clean things up in the destructor? Can you say trap on shutdown?

    You really need to have some form of validation for the "this" pointer.

  2. Willaim H. Gates says:
    January 9, 2004 at 11:35 am

    Hello Raymon,

    You shouldn’t disregard our precious software in public.

    Bill.

  3. Steve Sheppard says:
    January 9, 2004 at 12:38 pm

    Stupid and illiterate too!

    Bill,

    You seem to have a real problem with names, both RaymonDs and your own -> Willaim != William.

    Thanks for playing,

    Steve

  4. asdf says:
    January 9, 2004 at 3:53 pm

    Woah, wtf? A new BOOLEAN type? What happened to BOOL?

  5. Andreas Magnusson says:
    January 9, 2004 at 3:55 pm

    Most of the callbacks seems to allow user-data, but not the Service-API, which is too bad because when you put several services in one exe, it would be nice to have a class for each.

    Do you know why the Service-API lacks this (no pun intended), is there a good reason or was it just "missed"?

  6. Raymond Chen says:
    January 9, 2004 at 4:01 pm

    BOOLEAN, like UNICODE_STRING, dates back to the days when Windows NT was called "OS/2 3.0 NT".

    Andreas: I don’t know what the deal is with the service APIs. You can always fake it be instancing your callbacks. There are some other callbacks which frustratingly fail to pass reference data, like AbortProc, all the Windows hooks…

  7. Mike says:
    January 9, 2004 at 6:16 pm

    Andreas: Service callbacks take user-data. Put your this pointer in the lpContext.

    DWORD WINAPI HandlerEx(

    DWORD dwControl,

    DWORD dwEventType,

    LPVOID lpEventData,

    LPVOID lpContext

    );

  8. Florian says:
    January 10, 2004 at 3:36 am

    What if SomeClass was derived from SomeParentClass and ThreadProc was a virtual member function? Would the compiler still do the stack optimization?

  9. Raymond Chen says:
    January 10, 2004 at 7:53 am

    Try it and see! (and see if you can explain the codegen)

  10. Henk Devos says:
    January 10, 2004 at 8:16 am

    I’m wondering what’s happened to this in Win64.

    Have all user data parameters been widened to 64 bit?

  11. Raymond Chen says:
    January 10, 2004 at 8:24 am

    I mentioned this briefly in my old blog

    http://blogs.gotdotnet.com/raymondc/permalink.aspx/d29da767-5c07-48ec-9b9c-5f514b7d1f6b

    There’s more information on Win64 data types on MSDN, like here for example.

    http://msdn.microsoft.com/library/en-us/dnnetserv/html/ws03-64-bitwindevover.asp

  12. Ebbe Kristensen says:
    January 12, 2004 at 2:56 am

    return ((SomeClass*)lpParameter)->ThreadProc();

    really should be:

    return reinterpret_cast<SomeClass*>(lpParameter)->ThreadProc();

    Using new-style casts makes the code safer. Also it is easier to find casts in the source using a simple search.

    See also B. Stroustrup, The C++ Programming Language 3rd edition, pg 819. No, C-style casts are not deprecated – yet…

  13. Simply Patrick says:
    January 13, 2004 at 1:19 pm

    ??????,??????????? ?????????? calling convention: The history of calling conventions, part 1 The history of calling conventions, part 2 The history of calling conventions, part 3 The history of calling conventions, part 4: ia64 Why do member functions need to be…

  14. Alex says:
    January 19, 2004 at 6:00 pm

    Isn’t this passed in ebx?

  15. Raymond Chen says:
    January 19, 2004 at 6:06 pm

    Try it and see. My remarks applied to the Microsoft Visual C++ compiler – other compilers will probably do things differently.

  16. The Old New Thing says:
    July 19, 2004 at 10:02 am

    Thereby ensuring that you match the calling convention.

  17. Raymond Chen says:
    August 10, 2004 at 9:38 am

    Commenting closes after two weeks.

    http://weblogs.asp.net/oldnewthing/archive/2004/02/21/77681.aspx

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index