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,
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?
Windows App Certification Kit
acceptance test would see that
there is an attempt to import the
Now it needs to reverse-engineer the code
to verify that the program never calls
This eventually turns into the Halting Program,
which is unsolvable.
Furthermore, the issue isn't that the
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
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
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
Second, weak symbols don't actually solve the problem,
because it leads to making low-level components enforce
a high-level policy.