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)?
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.
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.
Related
I'm registering capicom.dll through my installer and unregistering it while uninstallation of my product. There is another third party software "ABC", also registers and uses this DLL.
But the problem is, when I uninstall my own product, I unregister capicom.dll. Because of this the another third party software "ABC" is not working properly.
So how I can check if this DLL is used by another product/application while unregistering it?
There is no great 100% answer to this problem. There are various conventions, depending on the underlying technology in play, that try to address a related problem. These include:
The SharedDLLs registry key, which tracks reference counts
Windows Installer component counts (if multiple .msi packages install the identical component, such as from a merge module)
Other package-level reference schemes
Never uninstalling from the System folder
However these only work when there's a single location for a given file. In your case, reading between the lines, I suspect there are multiple file locations for capicom.dll, but only a single registry location for its COM registration. Thus when you install your copy, you may be overwriting existing COM registration. While your copy is in place, all is well. But when you remove your copy, and/or unregister it, the COM registration does not revert to the previous copy.
Assuming you cannot ensure there's only a single file copy of capicom.dll, the best option I can think of is to use a registration-free COM manifest on your executables that references a private copy of capicom.dll, and skip registering your private copy of capicom.dll. InstallShield can help you create an external manifest, or you can instead create and embed the manifest in your executables yourself. Take additional care to verify that the activation context works if you are exposing inproc COM servers yourself that need to load capicom.
This is a more general and noob question. I am developing a small application in Linux (Ubuntu, to be more precise) and at this point I have an executable, a shared library (.so), a configuration file (.conf) with some settings to be read by the application at the beginning, a data folder with images and other resources to be used during the application life-time (resources that can be also modified, deleted) and of course, I would need some file for logs and messages (right now I am using syslog).
So, my question is, where should each one of these be stored when the application is installed on a client's computer? What is the standard way of organizing all the application's files in Linux? On Windows everything would be found usually in the C:\Program Files\(App Folder) but it looks like on Linux things are more (or less) organized. Can you give me some advices on this matter?
Program data were historically stored in dot-prefixed folders in user's home directory. Modern Linux distributions tends to use ~/.config/program_name folder.
For all files that will not be modified after distibution follow Linux standard:
Ex: project dir: ABC
sub directories:
logs - keep log files
conf - keep configuration files here
bin - executable binaries here
traps - any trap mesg
then depend on what application we develop
Along with you can set level for starting your application from boot level if required.
I'm Fairly new to Linux , And Software Development I was suggested that the shared library should be placed separately from the executable location in Linux , But in Windows I could see all the Files including the dll's and the exe are available in the same folder .What kind of problem's it might cause in linux if the exe and the shared library are in the same folder
When executable and library in same folder you can't say library is shared, right? And you'll probably have dozens of same libraries in system - what a waste of space. In Windows there's no organized way of storing libraries in system line /usr/bin or /lib/bin. It's not ok to put them in system32, and there's no other directories in PATH - no choice to make.
Let say i have a cross-platform runnable application
This application create then read/write some data and preference in external files
Bundle hierarchy is as follow:
ApplicationFolder/application.jar
ApplicationFolder/database.odb
ApplicationFolder/config.xml
Whether it's on a Mac, Windows or Linux, the application knows that everything is next to her (ie: /database.odb or /config.xml)
Now comes the Self Contained Application feature provided by JavaFx 2
The application is embedded in .exe on Windows, .app on Mac and don't know yet about Linux...
As a Mac user i've tested it on Mac and saw that database.odb and config.xml are now created at the user root path
I thus agree that i should think of a cross-platform mechanism to save/read my application preferences regarding the operating system
But i'm not quite sure of what to do and how to do it (can't find any googling help either..)
On windows, the .exe is installed in a folder, so i guess i can keep the same behavior
On Mac, the .app is a folder and i should keep everything inside (how to get the .app path ?!)
Isn't there a built-in mechanism in Java/JavaFx ?
Thanks a lot for any comment, advice, documentation or else that you could give me
Badisi
There are many ways to do this. I have listed some of them here in no particular order. The recommended approach depends on the type of data being stored.
Java provides a couple of mechanisms (e.g. the properties API and the preferences API) for maintaining application preferences.
If your application is sophisticated enough to benefit from an database, then you might want to use Java EE or Spring, both of which have their own configuration mechanisms.
For read-only configuration, you can bundle the relevant files inside your application jar.
To store customized application configuration files or client application wide databases in relative to the application jar, write the required files at runtime. See How do I get the directory that the currently executing jar file is in?.
For user specific configuration, use System.getProperty("user.home") to retrieve the user's home directory, then create a subdirectory for your preference storage (for example "{$user.dir}/.myapp") with hidden file attributes so that it doesn't show up on a standard file directory list.
If your app relies on internet connectivity, then you can store some of this information server side rather than the client and make use of it from the client using internet protocols. An advantage of this approach is that user configuration and data is automatically ported across client machines.
Our product includes several DLLs built from open source into files with default names as delivered by the open source developers. We're careful to install the files in our own directories and we carefully manage the search path (only for our processes) to keep the loader happy.
Another developer -- a towering intellect -- decided it would be easier to install their own build of some of the same open source into C:\WINDOWS under the same default DLL filenames. Consequently, when we launch a process which depends on these open source DLLs, the system searches C:\WINDOWS before our directories and finds the DLLs installed by the other developer. And they are, of course, incompatible.
Ideas which have occurred to me so far:
rename all our DLLs to avoid the default names, which would only make
it less likely we would encounter collisions
load all our DLLs by full path so the loader captures their names into
RAM and doesn't search anywhere else the next time they are requested
For various reasons, neither of these options is palatable at the moment.
What else can we do to defend ourselves against the towering intellects of the world?
You've got only two options: deploy the DLL in the same directory as the EXE (that's where Windows looks first) or using manifests and deploy the DLL to the Windows side-by-side cache. I don't think the latter option is common in the Open Source world but it is the only real fix if you want to share DLLs between different apps.
To add to the already excellent answers, you have a couple more choices:
The preferred solution(s) to this problem, supported since Windows XP, is to turn your dll's into a win32 assembly (They don't have to be .NET but the documentation on creating win32 assemblies with strong names is appallingly light so its easy to get confused and think this is a .NET only technology).
An assembly is noting more complicated than a folder (With the name of the assembly) containing the dlls and a .manifest (With the name of the assembly) that contains an assemblyIdentiy element, and a number of file nodes for each dll in the assembly.
Assembly based searching works even when dlls are statically linked!
The easiest option is to create unversioned assemblies and store them in the same folder as your .exe files (Assuming all your exe's are in a single folder).
If the exe's are in different folders, then there are two ways to access shared assemblies:
You can store your assemblies in a private alternate location if you expect your application to be used on Windows 7 and higher. Create a app.exe.config file for each of your exe's, and point a probing privatePath element to a common folder where you are storing the assemblies.
If you are ok with requiring administrative access to perform installs, (via MSI's) then you can deal with the appallingly bad documentation (well, absent documentation) that deals with giving your assemblies a strong name, and then store the assembly in WinSxS.
If you can't, or do not want to bundle your dlls as assemblies then this page covers dll search order
Using functions like SetDllDirectory are only going to help for dlls loaded dynamically at runtime (via LoadLibrary).
Dll search order used to be:
Directory containing the process exe
Current directory
various windows folders
PATH
Which you could have used to your advantage - launch each exe, setting the "current" directory to the folder containing the OSS dlls.
With the advent of SafeDllSearchMode the search order now is:
Directory containing the process exe
various windows folders
Current directory
PATH
Meaning theres now less control than ever :( - It goes even faster to the "untrusted" c:\windows & System32 folders.
Again, if the initial dll is being loaded via LoadLibrary, and its the dependent dll's that are the problem, LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag will cause the following search order (Assuming you pass a full path to LoadLibraryEx) :-
Directory part of the Dll path passed to LoadLibraryEx
various windows folders
Current directory
PATH
The directory from which the application loaded is normally the first directory searched when you load a DLL. You can, however, use SetDllDirectory to get the "alternate search order". In this case, the directory you specify to SetDllDirectory gets searched first.
There is also a SafeDllSearchMode that affects this to a degree. Turning it on excludes the current directory from the search.
Maybe just compile them to a static library?
Why not?
Also, the current directory, where the exe is activated from is searched before c:\windows.