4 ms·

"there is one more advantage: updating a library (which is trivial because almost all these systems are online all the time now) will automatically cause all ne

"there is one more advantage: updating a library (which is trivial because almost all these systems are online all the time now) will automatically cause all new instances of the rest of the software on the system to use the new library without having to re-link all the binaries." In Windows this is called "DLL hell". Too often the new version will have some subtle incompatibilities breaking a lot of stuff. I am a fan of static linking or putting DLLs into a dedicated folder so these shared libraries are actually not shared.

jacquesm 9y ago
Hm. DLL Hell to me was on Windows to have to upgrade a DLL for which some other dependency had to be downgraded which was the original reason for starting the upgrade in the first place. But I've seen your trick used in lots of places, in a way that trick is a predecessor to containers, you isolate a functional unit and all dependencies somehow from the rest of the system.
- TimJYoung 9y ago
  This is essentially what MS did with .NET and assemblies: they made it pretty difficult to install assemblies in the global assembly cache (GAC), and encouraged application developers to simply distribute/load application-specific assemblies in application-specific directories (\Program Files tree). This was all done with the prior experience gained from the system-wide DLL versioning issues that were finally resolved in (I believe) XP/2003.
  - jacquesm 9y ago
    Fortunately by then I'd left the Windows eco system behind.
    - maxxxxx 9y ago
      Lucky you!
kazinator 9y ago
Windows does a good job of versioning the actual system DLL's like user32.dll, kernel32.dll, and so on. The run-time libraries on top of this aren't part of the system. Each application brings its own and so of course hell will break loose if you mix and match. Windows has no malloc or printf (not for public use anyway). In the POSIX world, the user-space C run-time support is part of the platform so it is carefully versioned, just like kernel32.dll on Windows. User space compiler run-time support isn't part of the platform on Windows; it is not that carefully versioned. Everyone is supposed to provide their own. If you have a compiler from Acme, Inc, you use the Acme C library with Acme malloc and Acme printf. > putting DLLs into a dedicated folder Which actually works on Windows, that's the thing. Searching for shared libs in the same directory as the executable is very nice: like me.c finding its #include "me.h" next to it. The Unix people didn't pay attention to their own programming language when they designed shared libs.
- marshray 9y ago
  Most compilers used by app developers don't use this, but... link /dump /exports c:\windows\system32\msvcrt.dll Dump of file c:\windows\system32\msvcrt.dll Section contains the following exports for msvcrt.dll 00000000 characteristics 57898F96 time date stamp Fri Jul 15 18:36:22 2016 0.00 version 1 ordinal base 1317 number of functions 1317 number of names ordinal hint RVA name .... 1160 487 00019DE0 malloc .... 1183 49E 00048940 printf
  - kazinator 9y ago
    Most compilers used by app developers don't use that for good reason: Microsoft says that it is an unsupported, undocumented library which is off limits to application developers. Programs that are part of Windows itself use it. https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...

jacquesm 9y ago

Hm. DLL Hell to me was on Windows to have to upgrade a DLL for which some other dependency had to be downgraded which was the original reason for starting the upgrade in the first place. But I've seen your trick used in lots of places, in a way that trick is a predecessor to containers, you isolate a functional unit and all dependencies somehow from the rest of the system.

TimJYoung 9y ago
This is essentially what MS did with .NET and assemblies: they made it pretty difficult to install assemblies in the global assembly cache (GAC), and encouraged application developers to simply distribute/load application-specific assemblies in application-specific directories (\Program Files tree). This was all done with the prior experience gained from the system-wide DLL versioning issues that were finally resolved in (I believe) XP/2003.
- jacquesm 9y ago
  Fortunately by then I'd left the Windows eco system behind.
  - maxxxxx 9y ago
    Lucky you!

kazinator 9y ago

Windows does a good job of versioning the actual system DLL's like user32.dll, kernel32.dll, and so on. The run-time libraries on top of this aren't part of the system. Each application brings its own and so of course hell will break loose if you mix and match. Windows has no malloc or printf (not for public use anyway). In the POSIX world, the user-space C run-time support is part of the platform so it is carefully versioned, just like kernel32.dll on Windows. User space compiler run-time support isn't part of the platform on Windows; it is not that carefully versioned. Everyone is supposed to provide their own. If you have a compiler from Acme, Inc, you use the Acme C library with Acme malloc and Acme printf. > putting DLLs into a dedicated folder Which actually works on Windows, that's the thing. Searching for shared libs in the same directory as the executable is very nice: like me.c finding its #include "me.h" next to it. The Unix people didn't pay attention to their own programming language when they designed shared libs.

marshray 9y ago
Most compilers used by app developers don't use this, but... link /dump /exports c:\windows\system32\msvcrt.dll Dump of file c:\windows\system32\msvcrt.dll Section contains the following exports for msvcrt.dll 00000000 characteristics 57898F96 time date stamp Fri Jul 15 18:36:22 2016 0.00 version 1 ordinal base 1317 number of functions 1317 number of names ordinal hint RVA name .... 1160 487 00019DE0 malloc .... 1183 49E 00048940 printf
- kazinator 9y ago
  Most compilers used by app developers don't use that for good reason: Microsoft says that it is an unsupported, undocumented library which is off limits to application developers. Programs that are part of Windows itself use it. https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...