Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

run/load-time libraries

netphilou31
New Contributor II
426 Views

Hi,

I am building dlls that can be loaded in different ways: by several applications we are developing but also by activeX objects we have also developed and that can be used into Excel, Matlab, etc. Up to now I was using static linking to avoid the need to install run-time (or load-time) libraries. I am planning to to switch to dynamic linking but I was wondering how to manage this correctly. The documentation says that the system is using "Dynamic-Link Library Search Order" to load dynamlic link libraries, stating that :

A system can contain multiple versions of the same dynamic-link library (DLL). Applications can control the location from which a DLL is loaded by specifying a full path or using another mechanism such as a manifest. If these methods are not used, the system searches for the DLL at load time as described in this topic.

The text mentions the use of manifest mechanism to locate the dlls. I did not find (I probably did not searched efficiently) any information about this. Is it possible to generate a manifest file that contains information about libraries dependencies in such a way that the dlls can be located in any places (the dlls I am building as well as the load-time libraries)?

N.B: the dlls I am building are 32 and 64 bits dlls located into the "Common files" subfolder of the "Program Files" and "Program Files (x86)" folders and I don't want to (or can't) use the PATH environement variable to manage this.

Best regards,

Phil.

0 Kudos
6 Replies
Steven_L_Intel1
Employee
426 Views

With a manifest file you can specify that your DLLs are in a "side-by-side assembly" that is installed into a special folder in Windows. This is how the MSVC run-time DLLs are located. As best as I can tell, they don't allow you to specify arbitrary locations for the DLL.

There are Windows APIs to add directories to the DLL search path for an already running application, but I doubt this would be useful to you.

0 Kudos
netphilou31
New Contributor II
426 Views

Thanks Steve,

But How does this works ? Do you mention

a special folder in Windows

Is it a location that you cannot define in the manifest file? Do you have any example of such manifest file or how to configure the project properties to setup this ?

I was attempting to move away from static linking because I wanted to be able share logical units between dlls but if its too complex to setup I will probably have to use another way to do the job.

Best regards,

Phil.

0 Kudos
Steven_L_Intel1
Employee
426 Views

You can't specify the location - what you can specify is the DLL name, version and platform (32-bit or 64-bit).  You could start with http://www.samlogic.net/articles/manifest.htm and https://msdn.microsoft.com/en-us/library/windows/desktop/ff951639(v=vs.85).aspx if you wanted to learn more, but I don't think this will help you. The idea of side-by-side assemblies is to allow different programs to use different versions of a DLL rather than always using what it finds first on PATH, but you don't have control over how the search is done.

0 Kudos
netphilou31
New Contributor II
426 Views

Thanks for the advice. My primary goal was, unfortunately, to ensure that I be sure of the version of the run-time libraries used. But if any other software can override the dlls by installing its own on the same "special folder", that's not very good in terms of compatibility and consistency. I will probably stay with the static linking and will try to find a way to replace the sharing of logical units by another process.

Best regards,

Phil.

0 Kudos
Steven_L_Intel1
Employee
426 Views

If that's what you want, then shared assemblies are the ticket. But that helps only for DLLs that are dependents of your "main DLL".

0 Kudos
netphilou31
New Contributor II
426 Views

I will probably have to dig into the question. however as far as I have seen, assemblies seems to be very complex things even if they have been developped with efficiency as primary goal.

Thanks again,

Phil.

0 Kudos
Reply