DLL compilation in another designated folder?

Question

First of all, please forgive me for not knowing the correct terminology, I’m sure that there is a very common technical name for which I could just help Google, but I can’t find help if I don’t know the term to begin with.

I am building a modular system in Delphi 7. There are several applications and many DLLs. All applications share these DLLs, and some of the DLLs use other DLLs. The DLL is currently stored in the same place as the application. Instead, I would like to put all these DLLs in a subfolder (elsewhere from the EXE), but of course Delphi will not know how to find them.

Is there a way I can direct my Delphi applications to search in a specific directory for a DLL? It cannot use Contantants, because it will be possible to specify where the DLL is stored.

These DLLs are just a simple set of StdCall functions in each, nothing special.

EDIT:

To explain the reason why I want to save the DLL in my own folder: this system that I create considers these DLLs as add-ons. By default, the system may not even have any add-ons. On the other hand, it will also allow different vendors to create another DLL and include them as add-ons. Then, each application requiring these add-ons will be directed to a folder where they can be found. The application will have its own DLL, which will be in the same directory as the application. But I would like to leave Vendors DLL separately.

As mentioned in the answers below, the best option would be to implement the DLL import method, since A) I can specify the path for each DLL that it imports, B) I can better control the use of each DLL (should I load it or not?) And C) Each DLL can be technically located in separate folders by itself (vendors may want to create their own folder structure). This system is still very mature, but I plan to make it more flexible.

Answer 1

You can do this with PATH, but I do not recommend you to do this. This is a cruel and inflexible approach. And, of course, you need to change the system PATH so that it has any effect on boot time.

You can load your DLLs explicitly with LoadLibrary and GetProcAddress . It is not fun if there is a lot of import, but it can be a good option otherwise. And remember that if you go down this route, each individual DLL should switch to an explicit connection.

There is something called the Redirection DLL , but MS does not recommend using it. They recommend using side-by-side components. Having said that, the Visual Studio team moved away from the side-by-side components with the MSVC runtime in VS2010 due to the pain that it caused side-by-side in the previous release.

So, despite all the options, I really think that the best solution is to place all the DLLs in the same directory as the executable. If you can iterate over a folder that looks untidy, it will make life a lot easier. This is a trivial solution to the problem.

Update

Updating your question provides additional information that these DLLs are optional add-ons. In this case, you simply have no alternative but to use an explicit connection with LoadLibrary and GetProcAddress .

Answer 2

If you dynamically load DLLs into your code, you can store them anywhere, since in any case you have to go the full path to LoadLibrary/Ex() . If you are statically referencing DLLs, you can use SetDllDirectory() to assign an additional path to be included in the DLL search path.

Answer 3

I highly recommend leaving the DLL in the same folder as the applications.

If you really want to go the way of placing the DLL in a separate folder, you need to know if the DLL can be loaded using the LoadLibrary API, which also allows you to specify the path. However, if the DLL is statically loaded, then it is Windows that performs the search. First, a search in Windows looks in the application folder, then a search in Windows PATH is performed. Also, since Delphi 7 only creates 32-bit applications, it can become messy under Windows 64-bit.

Answer 4

On Windows, there is a " DLL search order ". One of these search paths is The directory from which the application loaded , so it works to have them in the same folder as the EXE.

If you are statically linked to a DLL, they should load when the EXE loads into memory. This is before your first line of code is executed. Thus, you rely on DLLs that are in one of the search paths. In this case, you are stuck in setting up the path, and you must install it before downloading the program.

If you are dynamically linking to a DLL, you can use LoadLibrary / LoadLibraryEx to load the DLL at runtime. Using these functions, you must specify the path to the DLL, so DLLs can be anywhere. In this case, I believe that it is indeed the case to put the DLLs in a separate folder in order to maintain order. Until you put the DLLs in a shared folder, such as the Windows System32 folder, you will avoid a lot of headaches.

Answer 5

Temporary solution:

You can set your DLL path in your application shortcut (in the "Start" field).