I'm trying to set up SDL2 in C++ Visual Studio but when I run the code(just some starter code I copied) it pops up with an error box box that talks about "SDL2.dll cannot be found" I tried switching to x64 but that was no help. I can see that the dll is right next to the lib files but it just won't work.
Your problem is the lib folder is not a place that your OS will search for dependent dlls by default. To fix this you would have to help your OS find the dll. There are several methods you can use to tell your OS where to look. One is adding an entry to your PATH environment variable that contains the full path to the folder containing the dll.
This site can help with setting the PATH: https://www.computerhope.com/issues/ch000549.htm
As second method is to put the dll in the same folder as the executable.
By default your OS probably is using the safe search option described here:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.***
Related
I am working with Visual Studio and I am trying to get into dlls. I'm wondering how the linker knows where to find a DLL just from the lib file alone.
I specify the lib file and its location in the project settings but where isthe location of the associated dll file specified?
Or maybe i don't understand the topic correctly.
The Standard Search Order for Desktop Applications from the Microsoft Dll Search Order documentation:
If SafeDllSearchMode is enabled, the search order is as follows:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
If SafeDllSearchMode is disabled, the search order is as follows:
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
I'm having trouble creating a texture which is in my DLL project's directory.
I'm doing
D3DXCreateTextureFromFile(Device, "Sprites/ExpandBlack.png", &BlackTexture);
but that doesn't seem to work. However if I do the whole path like:
D3DXCreateTextureFromFile(Device, "C:\\Users\\Home\\Documents\Visual Studio 2017\\Projects\\NO\\NO\\Sprites\\ExpandBlack.png", &BlackTexture);
it does work.
I also tried doing ../Sprites/ExpandBlack.png, ..\\Sprites\\ExpandBlack.png etc.
Any kind of help is appreciated.
This is where Sprites is located and it has to be "compiled" with the dll.
../Sprites/ExpandBlack.png, ..\\Sprites\\ExpandBlack.png and Sprites/ExpandBlack.png all refer to the same relative path.
Relative paths append to the process's working directory. DLLs use the same working directory.
To get a DLLs path see Get DLL path at runtime
Relative paths are relative to the current directory of the process. If it works when using a full path but doesn't work when using a relative path then obviously your relative path is not leading to where it should be leading. Most likely because the current directory of the process that's supposed to access that file is not what it should be.
Since we're talking about a DLL here, I suppose the problem is that when running the program that's actually using the DLL, that program is launched from a different location than the one the DLL project file is in. Most likely, because the project is located in a different directory than the DLL project. Visual Studio will by default use the directory in which the project file is located as the working directory for the process. You can change the working directory that Visual Studio will use in the project properties under "Debugging". Most likely, you will want your sprites located relative to the application that's using them rather than some DLL that the application is using. If these sprites are actually tied to the library and required by the library to function, on the other hand, then you may want to consider embedding the files into the library, e.g., as resources, or at least place these files relative to the library and access them based on the location of the DLL and not the current directory of the process that's using the DLL. To get the path of your DLL, see the answer linked in user2176127's answer…
I have four different .exes in differend subdirs of one specific directory. All of the programs need the exact same .dlls (Qt5Core, Qt5Gui and Qt5Widgets). Is there a way of having theese three .dlls just in the root directory insted of having to copy them into each subdirectory?
Here you find the order in which DLL paths are searched on Windows:
Since Safe DLL search mode is enabled by default, the order is
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
So the easiest thing to do is to ensure that you run your app from the working directory where you put the DLLs (5.). That could be done by writing a starter .bat file that navigates there first and then runs the application relative to the DLL direcory.
The other way would be to add the DLL directory to PATH in a starter .bat file (6.).
In both cases you need a wrapper script for each .exe that you want to run.
You could avoid that if you can make sure that links to the application set the working directory properly. This would work if you have an installer creating the shortcuts for the user and you know the user will not create one himself by just right-clicking the .exe.
There might also be a way using hardlinks or junctions but I don't know if you can copy and deploy those like symbolic links on Linux or if you need to create them on the target system.
Yes, you are using Windows and you can add your root directory as a path in Environment Varibles from
Computer-> Properties->Advanced System Settings -> Environment Variables
I'm trying to use CreateProcess to execute an external process from a c++ application.
The launched application fails when looking for dll's that exist in it's directory.
Inspecting the executwd process with Process Explorer (from sysinternals) shows that the process working directory is c:\windows, and not the parents working directory.
Using lpCurrentDirectory to hard code the working directory also doesn't help.
The process does execute properly qhen using the system command.
EDIT
The problematic directory isn't the module directory, but the current working directory.
The modules directory is searched as expected, but doesn't contain the dll
(Copying the sll to the module directory works -but it,s a workaround)
When you use CreateProcess function, the first directory searched is the directory containing the image file used to create the calling process.This allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable. If Dll files are not found, system searches these files in system folders, such as system32 or %windir%.
The search path can be altered using the SetDllDirectory function. This solution is recommended instead of using SetCurrentDirectory or hard-coding the full path to the DLL.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682600%28v=vs.85%29.aspx
In a Project of mine, I use a Delphi Application which dynamically loads a wrapper DLL (exporting C-Style functions) which in turn is statically link against a bunch of 3rd party DLLs.
It works fine on my test machines, but on my customers computer it failed to initialize with an error Message like "Couldn't find entrypoint _somefunction#4AKKZ in TMYlibrary.dll".
After some investigation with sysinternal's process monitor, I realized that Windows would look fror DLLs in windows/sytem32 first, so if a DLL named similar to my DLL was present in system32, windows would pick that one and try to find my function entry points in it - which would fail.
Do you know of a possiblity to change windows' DLL the searching behaviour?
Additional Information
[Update] The .exe file is located on the top level of the application's folder tree.
The Wrapper and the 3rd-party-DLLs ar e both located in the Subfolder /bin of my apps Folder
Dev platform is windows XP/7, using VS2008 for the dlll and Delphi 2010 for the application
I found another solution myself:
SetDllDirectory adds an additional search path to the list of locations to look at.
From http://msdn.microsoft.com/en-us/library/ms686203%28v=VS.85%29.aspx
After calling SetDllDirectory, the DLL search path is:
The directory from which the application loaded.
The directory specified by the lpPathName parameter.
The system directory. Use the GetSystemDirectory function to get the
path of this directory. The name of
this directory is System32.
The 16-bit system directory. There is no function that obtains the
path of this directory, but it is
searched. The name of this directory
is System.
The Windows directory. Use the GetWindowsDirectory function to get
the path of this directory.
The directories that are listed in the PATH environment variable.
(maybe i should do my googling before I post on SO ;)
Ship the DLL in your program's folder. (same as the exe file).
Then Windows should try your version first.