''Perhaps someone who knows lots more about MicrosoftWindows than I do can describe how Windows DLLs differ from shared libraries in Unix.  (Besides, of course, DllHell)''

* How are .so files immune from DllHell? -- MikeSmith

Unix has long allowed multiple versions of the same shared library to coexist.  A symlink, libfoo.so, would point to the most recent version of the library, ie libfoo.1.2.so.  If an application needed a more specific version; it could reference it.

Dlls, at least a while back, didn't allow this.  Only one version could be installed; if a newer version broke an older program, you were stuck.  (To make things worse, the occasional unfriendly application would '''downgrade''' a DLL, replacing a newer version with an older version).

Of course, Windows DLLs have a few other features/attributes that Unix .so files don't have.  Shared segments, for one (which would cause lots of problems with different versions).  The guarantee that the DLL resides at the same location in the address space in each process that runs it, for another.  

DllHell seems to be one reason that MS distributes lots of libraries as ComObjects, which have much better versioning than Dlls.  (''Or so I'm told...''')

-- Scott Johnson

----

A couple differences between shared libraries on typical Unix systems, and DLLs on Windows (my knowledge may be out of date).

* Unix .so files typically contain PositionIndependentCode, which can be loaded at any address.  All jumps/branches within the .so are PC-relative; data accesses within the .so are done through a "library register" dedicated for that purpose.  A .so may be loaded at different virtual addresses in different processes; however only one copy is present in physical memory or on backing store.
* Windows DLLs, OTOH, are always loaded at the same virtual address in all processes that use them (they may be loaded at different addresses at different times; but a DLL is loaded it stays put until the last program that uses it exits).  Thus PositionIndependentCode is not necessary.  Which is a good thing, as the register-starved x86 architecture is in no position to dedicate one of its precious registers to support relocatable code.
* Symbols within DLLs are (or can be) referenced by ordinal number as well as by name.  Makes dynamic linking faster; also can be a source of DllHell if the numbers get out of sync.


----

CategoryLinker