#8 - They now cannot do away with DLL hell unless they dump an entire legacy of compatibility. So they have no choice but to break compatibility or keep different kludges for "it's not a bug it's a feature" programs.
The majority of security and bug fixes are with the implementation, not the public interface. This really isn't an issue to begin with, and it certainly isn't a new issue with the patching system I'm talking about.
They can't store different versions of DLLs (as XP is capable of doing)
Huh? XP is capable of keeping backups of older versions, but only one version be run at a time. Unless you're talking about .NET and the GAC, but that has nothing to do with XP.
By obfuscating their APIs in the first place they have created an environment where applications depend on specific DLL behaviour, and if this is changed it breaks compatibility.
How have they obfuscated their APIs? Can you give a specific example?
What type of encryption? If there is encryption built into the updating system, what good will this do when hackers can just compare the normal unencrypted file to the finished product after the patch is applied?
I don't know the exact kind of encryption. It does a lot of good because instead of being able to see each set of bytes along with their associated meta data, the only thing they can see is the final result. The greater the number of patches applied to the DLL, the harder it is for bad guys to figure out what's going on.
|