Comment Re: It's not the answer, its the extreme opposite. (Score 1) 359
I think you are quite misinformed. Windows DLL hell happens because windows dynamic library
layout is simplistic and unorganized.
In windows, say, you have dlls like MYDLL.DLL Microsoft usually keeps backwards compatibilty in DLLS between windows/upgrades/service pack versions, so new DLLs should work with older programs. Now, the problem is when you install a program that comes with an OLDER version of MYDLL.DLL, then programs that use the newer version will not work properly. To get around this, since win2000, microsoft includes a dir with a backup of every DLL, so if one gets replaced, it will throw back the "latest" version. The VBrun example wasnt very good, since that one has an implicit versioning scheme (something most other windows DLLs dont). You have to also remember that, very often, microsoft, instead of upgrading an api, they create a new one from scratch with another name but same functionality. And you have to _also_ remember, that the COM approach they use keeps them safe from incompatibility during api upgrades.
Oh, and you should __also__ remember, that many installers (including many ones by microsoft) simply check file date instead of version, remember the usual windows popup about conflicting dates which happen most of the time for libraries? "The file being copied is older than the one on the system, do you want to keep the old one?"
In unixes you simply have libmylib.so.majorversion for different versions, with a symlink to the minor versions, so having multiple , major versions of a library (usually when api changes happen) is possible, and it's also possible to have very specific minor versions of a library for a program. Also with this method, you can identify a library version 100% correctly, no symbols or messy stuff needed
So, all in all, using the "windows approach" of distributing the binary with the shared libs needed all together, and also checking library version by filename, does not mean falling into the "DLL hell".
And no, my views of opposite in the graph were about userfriendlyness vs messyness, not about static being the opposite of dynamic, so forgive me if i was unclear.
reduz
In windows, say, you have dlls like MYDLL.DLL Microsoft usually keeps backwards compatibilty in DLLS between windows/upgrades/service pack versions, so new DLLs should work with older programs. Now, the problem is when you install a program that comes with an OLDER version of MYDLL.DLL, then programs that use the newer version will not work properly. To get around this, since win2000, microsoft includes a dir with a backup of every DLL, so if one gets replaced, it will throw back the "latest" version. The VBrun example wasnt very good, since that one has an implicit versioning scheme (something most other windows DLLs dont). You have to also remember that, very often, microsoft, instead of upgrading an api, they create a new one from scratch with another name but same functionality. And you have to _also_ remember, that the COM approach they use keeps them safe from incompatibility during api upgrades.
Oh, and you should __also__ remember, that many installers (including many ones by microsoft) simply check file date instead of version, remember the usual windows popup about conflicting dates which happen most of the time for libraries? "The file being copied is older than the one on the system, do you want to keep the old one?"
In unixes you simply have libmylib.so.majorversion for different versions, with a symlink to the minor versions, so having multiple , major versions of a library (usually when api changes happen) is possible, and it's also possible to have very specific minor versions of a library for a program. Also with this method, you can identify a library version 100% correctly, no symbols or messy stuff needed
So, all in all, using the "windows approach" of distributing the binary with the shared libs needed all together, and also checking library version by filename, does not mean falling into the "DLL hell".
And no, my views of opposite in the graph were about userfriendlyness vs messyness, not about static being the opposite of dynamic, so forgive me if i was unclear.
reduz
