Header image

Sane Handling Of DLL's

Windows allows the use of DLLs (Dynamic Link Libraries) to modularize applications and reuse code. The idea is that, when an application is starting up, it locates the DLL and calls functions inside it. This has several theoretical advantages. The application does not need to contain the code itself, other applications can reuse the same code, and different people (even different companies) can provide components that other people can link to and use.

The problem with this in Windows is that there is no version control on DLLs. When you install application1, it installs version 1 of "frog.dll". Then you install app2, which uses version 2 of "frog.dll". The new version overwrites the old version. The next time you start app1, it opens "frog.dll" and finds something other than version 1, leading to unpredictable results. It might work fine (if you're lucky). It might immediately crash. It might look like it's working but really be slowly corrupting your data.

Even worse, the operating system uses the same DLLs, and can be subject to the same problems. Many Windows users have installed an application (even one written by Microsoft) and had it break other programs that were working fine, or even render the machine unbootable, requiring a full reinstall of Windows.

There are third-party applications that help to deal with this problem, but they don't allow you to run applications that require conflicting DLLs at the same time.

Linux (among other operating systems) does not have this problem. Linux uses DLLs, too (in Unix terms they are called "shared objects"), but the OS keeps track of the versions. When you run app1, Linux notes that it needs version 1 of "frog.so", and automatically links it in. When you run app2, Linux automatically links version 2 of "frog.so". This happens even if app1 and app2 are running at the same time.


[Prev]   [Up]   [Next]