Why not use weak linking to solve the retargetable library problem?
Back in the days of 16-bit Windows, the loader used weak linking. If you imported a function and it didn’t exist, you got a null pointer. You were then on the hook not to call the function unless you first checked that it was there. And it was a disaster. Programs crashed left and right because they didn’t check whether the function actually existed before calling it. The designers of Win32 decided that if you wanted weak linking, you had to do it explicitly via
Okay, but now we’ve come full circle, because
GetProcAddress of system DLLs is not permitted in universal Windows apps. Why not let universal Windows apps link to nonexistent functions, and put the burden on them to check the pointer before calling it?
Well, first of all, that’s sort of taking a step backward. “Hey, here’s a new programming platform. It’s harder to use than the old one.”
Second, how would you enforce this policy? The Windows App Certification Kit acceptance test would see that there is an attempt to import the
InitializeCriticalSection function. Now it needs to reverse-engineer the code to verify that the program never calls
InitializeCriticalSection. This eventually turns into the Halting Program, which is unsolvable.
Furthermore, the issue isn’t that the
InitializeCriticalSection function doesn’t exist. The function exists just fine. It’s just that universal Windows apps in the Windows Store are not allowed to call it. This means that you have to come up with a way for the operating system to decide at run time whether the import table entry for
InitializeCriticalSection should be null or not. This means that the loader must now be aware of Windows Store policies, and whenever the Windows Store changes its policy, a system update needs to be delivered in order to implement that policy.
And even if you somehow got the loader to enforce Windows Store policies, you have to tell the loader, “Oh wait, this program didn’t get installed via the Windows Store.” If a program gets installed by means other than the Windows Store, then Windows Store policies don’t apply. The loader would have to check somehow whether Windows Store policies are in effect for the app.
Therefore, the answer to the original question is twofold. First of all, no, we don’t have weak symbols, on purpose; if you want weak symbols, you can do it yourself with
GetProcAddress. Second, weak symbols don’t actually solve the problem, because it leads to making low-level components enforce a high-level policy.