by Michael S. Kaplan, published on 2005/03/22 09:41 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/22/400399.aspx
I have hinted around about this problem before, but now Raymond Chen explains how the technology works with a lot more detail in his post Why does the debugger show me the wrong function?
Note that the default behavior with DELAYLOAD when the DLL or the function cannot be loaded is to throw an exception. This was not the solution that MSLU uses for the problem (as I said bfore, we do not use the default DELAYLOAD, so we are not locked into its default behavior!).
In the MSLU case, it has failure stubs that it uses rather than throwing exceptions -- for every single API that is wrapped, there is a defined stub that will set up the failure path so that if the function cannot be called for some reason, it will fail gracefully. If someone up higher on the callstack fails, it is not MSLU's fault!
(This is why MFC crashes if you link it with MSLU yet do not include the DLL -- because although MSLU is so braced to handle failure when it needs to that some would say it has an end-of-the-world complex, MFC's paranoid sense of denial does not let it contemplate the failure of base APIs like GetSystemDirectory. I guess all big libraries need one sort of therapy or another!)
But if you think about what most failure stubs are, they are simple functions -- how many ways are there to say "take three parameters, set last error to ERROR_CALL_NOT_IMPLEMENTED, return NULL", when all is said and done? Really just one. So all of that folding together of identical code happens on almost every compile/link in MSLU. Even with over 500 failure stubs included, one for each API that the Microsoft Layer for Unicode wraps.