3 ms·

My Windows system currently has 21 copies of zlib1.dll on it, each shipped by a different program. While I have no doubt that Windows programmers have heard of

by yrro 10y ago

My Windows system currently has 21 copies of zlib1.dll on it, each shipped by a different program. While I have no doubt that Windows programmers have heard of DLLs, they clearly haven't grasped the idea of shared libraries.

72deluxe 10y ago
The problem in that case is developers not putting their DLLs in a system directory! Windows will use WinSXS to avoid problems with different versions (DLL hell). Once loaded into memory, DLLs save loading the same code twice. See http://www.ksyash.com/2011/01/dll-internals/ http://www.ksyash.com/2011/01/dll-internals/
- yrro 10y ago
  But no one uses them like that any more. Because we remember back when people dropped all kinds of shit into system directories, and the result was awful.
- JdeBP 10y ago
  This hasn't seen an airing in a while, because it became accepted wisdom years ago. You're encouraging a bad design that the world has learned better than to employ. * http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-directory.html http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-direc...
  - Annatar 10y ago
    This way, the DLL will be somewhere (usually a "Bin" subdirectory) within the application's own subtree rooted at "\Program Files\company\product\". This plainly shows just how poorly thought-out Windows is, to paraphrase: we didn't design a directory tree like UNIX, and we don't have a proper runtime linker like UNIX, so we are going to swipe using the bin/ directory like on UNIX because we don't know where else to put stuff, and while we're at it, we will rename bin/ to Bin/ because we don't know any better, and also while we're at it, we'll dump all the dynamically linked libraries which the application needs into that mis-named Bin/ directory. Because Windows doesn't have a proper operating system structure, nor does it have a clean structure (case in point C:\Program Files (x86)\, even if your Windows is 64-bit), nor does it have a runtime linker with the functionality equivalent to ld.so.1 (the only way to get anything close to -Wl,-R/opt/local/lib/64 out of LINK.EXE is to use an XML manifest(!!!), and $ORIGIN keyword's functionality of ld(1) is science fiction for LINK.EXE). How amateurishly bad can one get? Wintendo is a gift that just keeps on giving...

by yrro 10y ago

72deluxe 10y ago

The problem in that case is developers not putting their DLLs in a system directory! Windows will use WinSXS to avoid problems with different versions (DLL hell). Once loaded into memory, DLLs save loading the same code twice. See http://www.ksyash.com/2011/01/dll-internals/ http://www.ksyash.com/2011/01/dll-internals/

yrro 10y ago
But no one uses them like that any more. Because we remember back when people dropped all kinds of shit into system directories, and the result was awful.
JdeBP 10y ago
This hasn't seen an airing in a while, because it became accepted wisdom years ago. You're encouraging a bad design that the world has learned better than to employ. * http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-directory.html http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-direc...
- Annatar 10y ago
  This way, the DLL will be somewhere (usually a "Bin" subdirectory) within the application's own subtree rooted at "\Program Files\company\product\". This plainly shows just how poorly thought-out Windows is, to paraphrase: we didn't design a directory tree like UNIX, and we don't have a proper runtime linker like UNIX, so we are going to swipe using the bin/ directory like on UNIX because we don't know where else to put stuff, and while we're at it, we will rename bin/ to Bin/ because we don't know any better, and also while we're at it, we'll dump all the dynamically linked libraries which the application needs into that mis-named Bin/ directory. Because Windows doesn't have a proper operating system structure, nor does it have a clean structure (case in point C:\Program Files (x86)\, even if your Windows is 64-bit), nor does it have a runtime linker with the functionality equivalent to ld.so.1 (the only way to get anything close to -Wl,-R/opt/local/lib/64 out of LINK.EXE is to use an XML manifest(!!!), and $ORIGIN keyword's functionality of ld(1) is science fiction for LINK.EXE). How amateurishly bad can one get? Wintendo is a gift that just keeps on giving...