{"id":104125,"date":"2020-08-26T07:00:00","date_gmt":"2020-08-26T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=104125"},"modified":"2020-09-09T06:10:32","modified_gmt":"2020-09-09T13:10:32","slug":"20200826-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20200826-00\/?p=104125","title":{"rendered":"Why are some system functions exported as stubs instead as forwarders?"},"content":{"rendered":"

If you do a little digging around inside some Windows system functions, you’ll see that, for example, the Create\u00adProcessW<\/code> function looks like this:<\/p>\n

kernel32!CreateProcessW:\r\n6b819ef0 mov     edi,edi\r\n6b819ef2 push    ebp\r\n6b819ef3 mov     ebp,esp\r\n6b819ef5 pop     ebp\r\n6b819ef6 jmp     dword ptr [kernel32!kernelbase_CreateProcessW]\r\n<\/pre>\n
The first four instructions have no net effect, so basically this is just an indirect jump to the kernelbase!CreateProcessW<\/code> function. In other words, it’s a stub that forwards to the real implementation over in kernelbase<\/code>.<\/p>\n
Why is it done this way? Why isn’t the Create\u00adProcessW<\/code> function just a forwarder to kernelbase<\/code>? That would avoid having to travel through kernel32<\/code> just to reach kernelbase<\/code>.<\/p>\n
Yes, this would normally be a forwarder, but it’s not. For backward compatibility.<\/p>\n
Wait, why is there a compatibility constraint that the Create\u00adProcessW<\/code> function cannot be a forwarder?<\/p>\n
Set the time machine to 2001.  The Microsoft Layer for Unicode (MSLU)<\/a> was just released, also affectionately known as “Unicows”, after the DLL component of MSLU: unicows.dll<\/code>.<\/p>\n
MSLU was a combination of a static library and a DLL. You wrote a Unicode application and linked it with the MSLU static library. This library contained its own definitions for a large number of functions, including Create\u00adProcessW<\/code>. When your Unicode application called the alternate version of Create\u00adProcessW<\/code>, the library checked whether it was running on a version of Windows that was ANSI-only (the Windows 95 series) or a version that supported Unicode (the Windows NT series).<\/p>\n
If it was running on an ANSI-only system, then the stub loaded the unicows.dll<\/code> library and forwarded the call to a helper function in that library which did the work of thunking the Unicode parameters to ANSI, and then calling the Create\u00adProcessA<\/code> function, and then converting the results back to Unicode, and returning that to the caller. If it was running on a Unicode system, then it forwarded the call to the operating system’s Create\u00adProcessW<\/code> function.<\/p>\n
In other words, the static library contained a stub that decided whether to allow the Unicode call to go straight to the Unicode version of the underlying function, or whether it should convert the call to ANSI and call the ANSI version of the underlying function.<\/p>\n
Okay, great, so where do DLL forwarders come into the story?<\/p>\n
After the MSLU static library decides which code path it should use, it goes back and patches the the caller’s import table to point directly to the destination function. That way, the second and subsequent calls are direct and don’t go through the evaluation step again. (This is the same sort of trick that the delay-load stubs use.)<\/p>\n
In the case where the MSLU static library decided to pass the function straight to the Unicode version of the underlying function, it needs to get the address of that Unicode version of the underlying function. For reasons not entirely clear to me, it doesn’t use the Get\u00adProc\u00adAddress<\/code> function.\u00b9 Instead it has a custom implementation of Get\u00adProc\u00adAddress<\/code> which parses the DLL export table manually to find the function to forward to.<\/p>\n
That custom implementation of Get\u00adProc\u00adAddress<\/code> doesn’t support forwarders. There’s even a comment acknowledging as much:<\/p>\n
   \/\/ This is a forwarder - Ignore for now.\r\n<\/pre>\n
Therefore, any function supported by MSLU may not take the form of a DLL forwarder. It must be a stub. Just in case somebody runs a program from the early 2000s written with MSLU.<\/p>\n
Bonus chatter<\/b>: This requirement that the function be a stub and not be a forwarder applies only to the x86-32 version of Windows, since that’s the only architecture supported by the Windows 95 series, and therefore the only one supported by MSLU. However, the functions are stubs on all architectures, presumably for simplicity of implementation.<\/p>\n
\u00b9 My suspicion was that it does this to avoid certain reentrancy issues in the loader, but I’m not sure.<\/p>\n","protected":false},"excerpt":{"rendered":"
Compatibility, of course, at least for some of them.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-104125","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Compatibility, of course, at least for some of them.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104125","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=104125"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104125\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=104125"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=104125"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=104125"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}