7 ms·

Actually, as the article itself points out, there's a very easy way to avoid DLL hell - don't share DLLs with other apps. All of the programs we produce here i

Actually, as the article itself points out, there's a very easy way to avoid DLL hell - don't share DLLs with other apps. All of the programs we produce here include all of their DLLs in their own folder. There's nothing shared, so no other program can cause a problem for them.

mapleoin 16y ago
Doesn't that defeat the purpose of using DDLs in the first place?
- cstuder 16y ago
  Two main arguments for using DLLs were saving disk space and saving RAM. When was the last time you ran out of disk space because of too many DLLs? And nowadays, our RAM is bigger than the disks back then, so that shouldn't be a problem either.
  - wzdd 16y ago
    The other main argument is so that bug fixes can be deployed to all affected applications by replacing a shared DLL. The importance of this aspect is also going away now that pretty much everything automatically updates itself via the Internet.
    - ciupicri 16y ago
      Why should I waste bandwidth because DLLs aren't shared anymore?
      - roel_v 16y ago
        It's a trade off between using bandwidth (+ the extra hassles for the auto update infrastructure etc., but that is carried by the vendor) and reducing the risk of deployment issues that may not be caught by QA because they are machine-specific. Plus, application dll's are in the magnitude of 100's of kilobytes - I 'waste' more bandwidth with the POP3 polling that my phone does each week than that. I would say that in this context the amount 'wasted' is so small that it can hardly be called a true 'waste'. (I rinse my cup before pouring in new coffee. Is that 'wasted' water? Technically yes, since it goes into the dishwasher at the end of the day anyway and reusing the cup during one day doesn't pose a health risk. That 'waste' won't prevent me from doing so though).
        ciupicri 16y ago
        Of course it's a trade off, I didn't deny that. I see it just like (micro) optimizations: in some cases it's worth doing it, in others it's not. Regarding the size of DLLs, some of them are indeed small, but others have a couple of megabytes, e.g. XUL (from Mozilla Firefox), Qt, GTK+. Multiply this with the number of applications and it can be come an issue if you have a slow Internet connection.
      - tomjen3 16y ago
        Because bandwidth is cheap. Programmers and system administers are not. And neither is your time when you have to fix the broken system.
    - viraptor 16y ago
      > pretty much everything automatically updates itself via the Internet But will the vendor care about every update from the system the program is running on? What happens if someone discovers a bug, your system is updated, but vendor a) doesn't care (or doesn't exist anymore) b) linked statically to some library? You're left with no protection against a known vulnerability, even though the patches are available and published.
  - wazoox 16y ago
    This may not seem a problem on the desktop, but RAM still is a major limitation on servers, and don't even talk of virtual machines.
    - JoachimSchipper 16y ago
      Libraries are still shared among multiple instances of the same process, and just how big are libraries anyway? Most servers run only a handful of (very busy) processes...
    - djacobs 16y ago
      That may be true, but RAM is not so limited (even on VMs/servers) that DLLs are worth the extreme hassle. Case in point: Linux (for me) runs much better on a minimal VM than any version of Windows.
      - wazoox 16y ago
        Does not compute. Linux too uses dynamic shared libraries, and you can also link programs to a specific version of a .so, or bind it with your binary distribution (see Firefox, Chrome), such binding posing problems to distributions : Debian just dropped chromium from Squeeze exactly because of that.
  - rubyrescue 16y ago
    also from the article: It is worth noting that DLLs no longer save disk space. In fact, the opposite is the case. If you have a look into the side-by-side repository (found in Windows' WinSXS directory), you will find, that its 5 GB on Windows 7 and even 7 GB on Windows Server 2008, containing 40.000 files with numerous versions of roughly all Microsoft Libraries. That's about 50% of the disk space used by Windows in total. We were needing a solution, but we created a monster
    - roel_v 16y ago
      I think this argument is wrong. Those 5GB are of separate versions of each DLL. If program A needs version 1 of a library and programs B and C need version 2, you only have to have 2 files - those of 1 and 2. B and C can share their copy. So they do save space. Now I don't know if it saves as much as the 5GB that the different versions take. This 5 GB is because there are so many versions. You could argue that they shouldn't be all installed, and that applications should install them on-demand, but that would require major deployment issues at vendors (especially those so small that they don't have specialized deployment engineers). I think the trade off they (=Microsoft) made here is quite reasonable (i.e. use more disk space to prevent deployment issues).
      - malkia 16y ago
        That 5gb is 20gb on my vista 64 bit machine. I have tons of different 64bit, debug and release dlls. Could be from the fact that I have 3 different versions of studio installed? Anyway...it does not serve it's purpose, and only wastes user money - 20gb cost a lot on a latest SSD drive
        contextfree 16y ago
        It's probably not really 20GB. Most of what's in WinSxS is links to files in other directories, often multiple links to the same file, and the Windows shell "Properties" dialog will include every "copy" when calculating total size.
        16y ago
- xentronium 16y ago
  You don't always have access to DLL source code. Actually, most of the time you don't.
- AndrewDucker 16y ago
  We can still use a DLL with multiple applications - they're just shared between the different apps, and live with them. So if I have two apps Foo and Bar that both use PrettyTreeView.DLL, then I just put a copy of it in both projects, and save it in the same repository. Means I can keep the functionality nicely carved off in one place, but I don't have to worry about updating one app and breaking the other. Also, the DLL is only loaded in as needed - which saves on memory.
- billpg 16y ago
  Keeping things in their own DLLs are handy to update modules without having to update the entire app.
elblanco 16y ago
Considering how cheap storage is today (~$65/TB) is there really a reason to use shared DLLs in this day and age on the desktop?
- qjz 16y ago
  Ideally, when a bugfix or security update is applied to the shared DLL, your application immediately benefits and you won't have to roll out your own update. I would imagine that some 3rd party enhancements (plugins, for example) also rely on shared DLLs.
  - jpr 16y ago
    Aren't dynamic loading (for plugins etc.) and dynamic linking two different things?
    - roel_v 16y ago
      Depends on the exact definitions. 'dynamic loading' (whic I would define as with ::LoadLibrary() ), is a subset of 'dynamic linking' because dynamic linking can be done explicitly (with ::LoadLibrary()) or implicitly by the application's startup code, which is generated/inserted into the executable by the linker. Then again I wouldn't have a problem with someone defining the terms differently so that they are the same or overlap in a different way. I wouldn't say though that they are very different - they are related no matter how you slice it.
- roel_v 16y ago
  Yes, so that one component can be upgraded and be used by other programs. Recall the zlib bug of a few years ago. Everybody who linked zlib statically had to provide a new build (or include the fix in their next release). There have to be thousands of applications out there who weren't upgraded (old version, vendor out of business, whatever) and who are vulnerable to a years-old security flaw. That said, I ship my own software with all required dll's in one directory, too.
  - 16y ago
jimbobimbo 16y ago
Unfortunately, it's a problem which is surprisingly hard to solve for code that uses CRT, MFC or ATL. And it is especially hard, if you link to the code which in turn links to some other version of these libs.
- malkia 16y ago
  Also if for some reason you would like to deploy debug version along with release. Normally you don't have to, but sometimes to inspect a problem on coworker's machine (say he's an artist, and the dll is some plugin for some editor) and then you end up with installing studio on his machine :(

mapleoin 16y ago

Doesn't that defeat the purpose of using DDLs in the first place?

cstuder 16y ago
Two main arguments for using DLLs were saving disk space and saving RAM. When was the last time you ran out of disk space because of too many DLLs? And nowadays, our RAM is bigger than the disks back then, so that shouldn't be a problem either.
- wzdd 16y ago
  The other main argument is so that bug fixes can be deployed to all affected applications by replacing a shared DLL. The importance of this aspect is also going away now that pretty much everything automatically updates itself via the Internet.
  - ciupicri 16y ago
    Why should I waste bandwidth because DLLs aren't shared anymore?
    - roel_v 16y ago
      It's a trade off between using bandwidth (+ the extra hassles for the auto update infrastructure etc., but that is carried by the vendor) and reducing the risk of deployment issues that may not be caught by QA because they are machine-specific. Plus, application dll's are in the magnitude of 100's of kilobytes - I 'waste' more bandwidth with the POP3 polling that my phone does each week than that. I would say that in this context the amount 'wasted' is so small that it can hardly be called a true 'waste'. (I rinse my cup before pouring in new coffee. Is that 'wasted' water? Technically yes, since it goes into the dishwasher at the end of the day anyway and reusing the cup during one day doesn't pose a health risk. That 'waste' won't prevent me from doing so though).
      - ciupicri 16y ago
        Of course it's a trade off, I didn't deny that. I see it just like (micro) optimizations: in some cases it's worth doing it, in others it's not. Regarding the size of DLLs, some of them are indeed small, but others have a couple of megabytes, e.g. XUL (from Mozilla Firefox), Qt, GTK+. Multiply this with the number of applications and it can be come an issue if you have a slow Internet connection.
    - tomjen3 16y ago
      Because bandwidth is cheap. Programmers and system administers are not. And neither is your time when you have to fix the broken system.
  - viraptor 16y ago
    > pretty much everything automatically updates itself via the Internet But will the vendor care about every update from the system the program is running on? What happens if someone discovers a bug, your system is updated, but vendor a) doesn't care (or doesn't exist anymore) b) linked statically to some library? You're left with no protection against a known vulnerability, even though the patches are available and published.
- wazoox 16y ago
  This may not seem a problem on the desktop, but RAM still is a major limitation on servers, and don't even talk of virtual machines.
  - JoachimSchipper 16y ago
    Libraries are still shared among multiple instances of the same process, and just how big are libraries anyway? Most servers run only a handful of (very busy) processes...
  - djacobs 16y ago
    That may be true, but RAM is not so limited (even on VMs/servers) that DLLs are worth the extreme hassle. Case in point: Linux (for me) runs much better on a minimal VM than any version of Windows.
    - wazoox 16y ago
      Does not compute. Linux too uses dynamic shared libraries, and you can also link programs to a specific version of a .so, or bind it with your binary distribution (see Firefox, Chrome), such binding posing problems to distributions : Debian just dropped chromium from Squeeze exactly because of that.
- rubyrescue 16y ago
  also from the article: It is worth noting that DLLs no longer save disk space. In fact, the opposite is the case. If you have a look into the side-by-side repository (found in Windows' WinSXS directory), you will find, that its 5 GB on Windows 7 and even 7 GB on Windows Server 2008, containing 40.000 files with numerous versions of roughly all Microsoft Libraries. That's about 50% of the disk space used by Windows in total. We were needing a solution, but we created a monster
  - roel_v 16y ago
    I think this argument is wrong. Those 5GB are of separate versions of each DLL. If program A needs version 1 of a library and programs B and C need version 2, you only have to have 2 files - those of 1 and 2. B and C can share their copy. So they do save space. Now I don't know if it saves as much as the 5GB that the different versions take. This 5 GB is because there are so many versions. You could argue that they shouldn't be all installed, and that applications should install them on-demand, but that would require major deployment issues at vendors (especially those so small that they don't have specialized deployment engineers). I think the trade off they (=Microsoft) made here is quite reasonable (i.e. use more disk space to prevent deployment issues).
    - malkia 16y ago
      That 5gb is 20gb on my vista 64 bit machine. I have tons of different 64bit, debug and release dlls. Could be from the fact that I have 3 different versions of studio installed? Anyway...it does not serve it's purpose, and only wastes user money - 20gb cost a lot on a latest SSD drive
      - contextfree 16y ago
        It's probably not really 20GB. Most of what's in WinSxS is links to files in other directories, often multiple links to the same file, and the Windows shell "Properties" dialog will include every "copy" when calculating total size.
        16y ago
xentronium 16y ago
You don't always have access to DLL source code. Actually, most of the time you don't.
AndrewDucker 16y ago
We can still use a DLL with multiple applications - they're just shared between the different apps, and live with them. So if I have two apps Foo and Bar that both use PrettyTreeView.DLL, then I just put a copy of it in both projects, and save it in the same repository. Means I can keep the functionality nicely carved off in one place, but I don't have to worry about updating one app and breaking the other. Also, the DLL is only loaded in as needed - which saves on memory.
billpg 16y ago
Keeping things in their own DLLs are handy to update modules without having to update the entire app.

elblanco 16y ago

Considering how cheap storage is today (~$65/TB) is there really a reason to use shared DLLs in this day and age on the desktop?

qjz 16y ago
Ideally, when a bugfix or security update is applied to the shared DLL, your application immediately benefits and you won't have to roll out your own update. I would imagine that some 3rd party enhancements (plugins, for example) also rely on shared DLLs.
- jpr 16y ago
  Aren't dynamic loading (for plugins etc.) and dynamic linking two different things?
  - roel_v 16y ago
    Depends on the exact definitions. 'dynamic loading' (whic I would define as with ::LoadLibrary() ), is a subset of 'dynamic linking' because dynamic linking can be done explicitly (with ::LoadLibrary()) or implicitly by the application's startup code, which is generated/inserted into the executable by the linker. Then again I wouldn't have a problem with someone defining the terms differently so that they are the same or overlap in a different way. I wouldn't say though that they are very different - they are related no matter how you slice it.
roel_v 16y ago
Yes, so that one component can be upgraded and be used by other programs. Recall the zlib bug of a few years ago. Everybody who linked zlib statically had to provide a new build (or include the fix in their next release). There have to be thousands of applications out there who weren't upgraded (old version, vendor out of business, whatever) and who are vulnerable to a years-old security flaw. That said, I ship my own software with all required dll's in one directory, too.
- 16y ago

jimbobimbo 16y ago

Unfortunately, it's a problem which is surprisingly hard to solve for code that uses CRT, MFC or ATL. And it is especially hard, if you link to the code which in turn links to some other version of these libs.

malkia 16y ago
Also if for some reason you would like to deploy debug version along with release. Normally you don't have to, but sometimes to inspect a problem on coworker's machine (say he's an artist, and the dll is some plugin for some editor) and then you end up with installing studio on his machine :(