Why not use weak linking to solve the retargetable library problem?

In response to the problem of creating a retargetable library, there was disbelief that the Windows linker doesn’t support weak symbols. (I’m assuming they meant “loader”, not “linker”.)

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 Load­Library and Get­Proc­Address.

Okay, but now we’ve come full circle, because Load­Library and Get­Proc­Address 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 Initialize­Critical­Section function. Now it needs to reverse-engineer the code to verify that the program never calls Initialize­Critical­Section. This eventually turns into the Halting Program, which is unsolvable.

Furthermore, the issue isn’t that the Initialize­Critical­Section 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 Initialize­Critical­Section 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 Load­Library and Get­Proc­Address. Second, weak symbols don’t actually solve the problem, because it leads to making low-level components enforce a high-level policy.