.dll .so -- loading in windows & Linux enviroment

Question

My question is related to dynamic library loading ('abc.dll' or 'abc.so') on both Windows & Linux enviroments.

I have a dll or shared memory. And i am having two applications which have to use this dll (abc.dll or abc.so). Now i have placed a copy of this dll (abc.dll or abc.so) in their respective folder of executable :

/folder-one/app1.exe
/folder-one/abc.dll (resp. abc.so)
/folder-two/app2.exe
/folder-two/abc.dll (resp. abc.so)

Now when i run app1.exe it loads the abc-library (abc.dll or abc.so) from its folder-one & runs.
Now when i run app2.exe it loads the abc-library (abc.dll or abc.so) from its folder-two & runs.

Q-1 Now my question is that when both the application run, will there be be two copies of the dll loaded ?

Loader loads the shared library (abc.dll or abc.so) in the memory in both linux & windows enviroment. http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Q-2 Is there a disadvantage to have the shared libraries (abc.dll or abc.so) as individual copies in the respective folders ?

Q-3 If i want to load a single dll from both applications, then what should be the common location (so both applications can find it)?

Answer 1

Q-1 Now my question is that when both the application runs then there will be two copy of the dll loaded ?

Yes, libraries will be loaded twice because they live in different locations (and name itself is not enough to make it unique).

Q-2 Does there disadvantage to have (abc.dll or abc.so) as an indivisual copy in respective folders ?

Primary memory consumption because code will be duplicated (of course each copy will have its own data). This is a simplification because it's not mandatory to share code (and it's different between Linux and Windows). In general a read-only section is shared and a read/write section is private (then duplicated).

Moreover loading time is higher because of basic overhead that occurs during loading (memory allocation, relocation of addresses, resolution of dependencies and so on).

Do not forget that this will apply to each dependency too (if they are deployed in the same folder of library you're using).

Finally you should consider deploying and updates. This can be a pro or a con but don't forget that a shared library can be updated just once and it'll upgrade all dependent applications; it's a pro if it's done carefully but it's a con if an update can break existing code. This issue can be managed, for example, including a version number in the name (when you change version then compatibility isn't granted).

Q-3 If i loads the dll from two application then that should be at common location ?

Yes. A library is uniquely identified by its name and its location. In that case it won't be loaded in memory twice.

Answer 2

On Windows, if a dll is loaded already and you load a dll with the same module name, it will return the loaded one and not bother searching.

Before the system searches for a DLL, it checks the following:

If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.

as described in this very long MSDN page (which appears at first glance to be solely concerning Windows tore apps, but it does talk about desktop mode that I guess hasn't changed from Win7 at least)

However, I think this depends on a lot of things nowadays: are you running a windows store app, or a .net dll, or a win32 dll. I know .net uses a system of probing' to locate a dll. And then you also have to determine whether your dll is held as a side-by-side component.

The old days of memory, then current directory, then path was easy to understand. I think Linux uses this approach.