6 ms·

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.

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.