How to set relative path for static dll loading?

Question

I have a DLL created in Delphi 7 / Windows XP that I want to statically load into a host application in Windows (also in Delphi). I use this line of code:

procedure Prepare_HTML_Email(var MailMessage : TIdMessage; const FileAddress, aDetail, aAlarmType : String); stdcall; external DLL_ADDRESS; 

where DLL_ADDRESS should be the location of the DLL. But at the moment I have a problem. The host application is a service, so it works in C:\WINDOWS\System32 , but I want to put the DLL in a different directory, and not in C:\WINDOWS\System32 . An “external” keyword does not allow it to be followed by a function; it allows only a constant expression. So, how can I get the path to the DLL?

Answer 1

First, you are not “statically loading” anything. D in DLL - dynamic; all DLL files are linked dynamically, no matter what. Static communication is how DCU and OBJ files are included in your program. You cannot link statically with a DLL.

You are talking about dynamic load-time linking, when the OS loads the DLL for you implicitly due to the functions listed in the program import table, as opposed to the dynamic link-time linking, where you call LoadLibrary using whatever you want. When you use the external directive to define your function, you create an entry in the import table, and as far as I know, relative paths are pointless there. The OS searches for DLLs at boot time (and runtime) using a specific documented search order . In general, this is the application’s own directory, the current directory, the system directory, the Windows directory, and then everything else in the PATH environment variable.

In your case, the current directory and the system directory are the same place, and in any case, you have no control over them. Do not put your DLLs in the Windows directory; which already has enough material that does not belong there.

It is best to place your DLL files in the same directory as your EXE service. If you do not want this, then you can put enough to load your program into one DLL in this directory, and then load everything else later using LoadLibrary , using any separate DLL directory that you want.

You can put your DLLs somewhere else, and then add this directory to your PATH environment variable. However, this variable is a shared resource, so think twice before changing it.

Answer 2

• Check out the pending dynamic link libraries available since Delphi 2010. AFAIK, you cannot load the DLL from a very specific path, but you can change the environment path variable in the very first line of your host program to include the path where the dll is located before using exported features.
• Changing the code to load the DLL is clearly not complicated, and you can specify the full path to the LoadLibrary API call. You will find an example of implicit and explicit dll loading in the same article .

Answer 3

If you put the path to the DLL in your system path, it doesn't matter where you put it. Just keep in mind that you will have to reboot if you make changes to the service before it can take effect.

To change the path variable, go to the "Advanced" tab for the system properties (right-click "My Computer") and click the "Environment Variables ..." button. Change the system variable "Path" to include the directory in which you want to save your DLL.

When resolving a DLL, the system first checks the current directory in which the process is running, and then the path variable from left to right and will use the DLL found in the first directory in which it runs ... that's why it works when you put it in C: \ Windows \ System32.

Answer 4

See how Windows loads the DLL here:

http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

SetDllDirectory () may help you, but it is not available until XP SP1.

Answer 5

Also worth reading (related to the main page of the MSDN documentation):

Dynamic link library redirection

This allows you to redefine even the hardcoded DLL code in the LoadLibrary. If it works for services, this may solve the problem in question.