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
Cool, I can post, this is my first post here! (sorry for the above)
What you say is all nice and dandy, but you are missing the point and going to the opposite extreme of the situation, let me explain graphically:
all source - A - B - C -D - all static
A: Compiling all from individual source: you get a tarball and compile, if it has dependences,./configure will fail. This is the standard for any opensource program, but it's _too_ hard for the regular joe user. For the experienced user, installing a few of these by is fine, but compiling the whole OS is for the hardcore. Also there is the issues of libraries/compilers getting ugraded in distros, which can make compiling even harder.
B: Get a binary package: Mandrake, debian, etc all use packages. This works fine, and it's amazing to simply do apt-get install. But when some program (or the latest version) is not aviable, you have to fall back to compiling from source. Debian proovides all development packages you need, and gentoo by default installs headers and stuff for libraries, but this is _still_ out of the scope of joe user.
C: Proovide a binary with the dynamic libraries included: This is what windows and MacOSx do! It's by far the easier for the developer and the user! you just proovide an installer. The installer _comes_ with the libraries you need also compiled, then the installer checks the versions of the libraries already installed and, if not found old ones are found, will just install the new version. Most _important_ libraries in linux are already stable and support this just fine. From the user perspective, they just download a program, run the installer and everything works. They will usually delete the installer or backup it, so this wont take up space. Also, if it wasnt for the reason that unixes dont have "." added to the path by default (is it the same in osx?) you could also do local installs. This is also very easy for the developer: besides the source, he just puts up a binary, and throws in the needed libraries for each release.
D: Proovide static libraries. This is hell because of what the parent post says, and also because your install will be huge!
Have you guys ever talked to new linux users, their biggest complain on the OS is not drivers, the existence of multiple dekstops, etc. It's just that installing programs is _hell_ for them. Even when i know using debian is dead easy, not everything is there, and as developer, not all my programs find a package mantainer.
So, maybe someone more experienced than I am can tell me why doing things the windows-mac-beos way isnt possible? I personally think it's simply because of lack of organization, but i may be wrong!
Slashdot Mirror
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
Cool, I can post, this is my first post here! (sorry for the above)
./configure will fail. This is the standard for any opensource program, but it's _too_ hard for the regular joe user. For the experienced user, installing a few of these by is fine, but compiling the whole OS is for the hardcore. Also there is the issues of libraries/compilers getting ugraded in distros, which can make compiling even harder.
.
What you say is all nice and dandy, but you are missing the point and going to the opposite extreme of the situation, let me explain graphically:
all source - A - B - C -D - all static
A: Compiling all from individual source: you get a tarball and compile, if it has dependences,
B: Get a binary package: Mandrake, debian, etc all use packages. This works fine, and it's amazing to simply do apt-get install
But when some program (or the latest version)
is not aviable, you have to fall back to compiling
from source. Debian proovides all development packages you need, and gentoo by default installs
headers and stuff for libraries, but this is _still_ out of the scope of joe user.
C: Proovide a binary with the dynamic libraries included: This is what windows and MacOSx do!
It's by far the easier for the developer and the user! you just proovide an installer. The installer _comes_ with the libraries you need also compiled, then the installer checks the versions of the libraries already installed and, if not found old ones are found, will just install the new version. Most _important_ libraries in linux
are already stable and support this just fine.
From the user perspective, they just download a program, run the installer and everything works.
They will usually delete the installer or backup it, so this wont take up space. Also, if it wasnt for the reason that unixes dont have "." added to the path by default (is it the same in osx?) you could also do local installs. This is also very
easy for the developer: besides the source, he just puts up a binary, and throws in the needed libraries for each release.
D: Proovide static libraries. This is hell because of what the parent post says, and also because your install will be huge!
Have you guys ever talked to new linux users, their biggest complain on the OS is not drivers,
the existence of multiple dekstops, etc. It's just
that installing programs is _hell_ for them. Even when i know using debian is dead easy, not everything is there, and as developer, not all my programs find a package mantainer.
So, maybe someone more experienced than I am can
tell me why doing things the windows-mac-beos way
isnt possible? I personally think it's simply because of lack of organization, but i may be wrong!
reduz
I bet i cant post, why is this?