It is interesting to see how Microsoft put a lot of effort in isolating DLLs to solve the long-hated problem of “DLL hell” (wherein a program depends on an exact version of a DLL, no newer, no older.) This, however, also brings a problem: security updates may not be propogated to older DLLs.

Take the Visual C Runtime DLL, msvcr80.dll , as an example. Its internal structures haven’t changed with every build. The problem here is that side-by-side lookups in XP and Vista check the versions to the build number, and ignore the DLL if its version numbers are different, even a build number. So there is a possibility that security updates with newer builds (e.g., 8.0.50767.163 from 8.0.50767.42) will not be propagated to the older versions.

Worse, if the application has no manifest (e.g., legacy apps) or the version numbers indicated in the manifest and the DLL’s numbers do not match, the result will  be an initialization failure at start-up (because the CRT DLL will fail the initialization routines upon detecting either of the two conditions mentioned.)

Like I’ve mentioned in a previous entry, having two different CRTs in the same application will most likely catch the end-user by surprise, through such messages as fatal CRT memory corruption. I’m still developing the “proxy” CRT (this one is NOT the actual CRT; the actual CRT is Windows’ system CRT, msvcrt.dll .) Note that I do not use manifests in the “proxy” CRT DLL; let all applications, older or newer, get the security update.

Leave a Reply